Pentesting web: cómo auditar la seguridad de una aplicación real con OWASP Top 10
¿Qué es el pentesting web y por qué importa más que nunca?
El pentesting web es hoy una de las prácticas más importantes para proteger aplicaciones en línea. La superficie de ataque crece de forma sostenida y cada año miles de sitios son comprometidos no por técnicas sofisticadas de intrusión, sino por configuraciones deficientes, componentes desactualizados o errores de diseño que pudieron haberse detectado antes de que un atacante los aprovechara.
El pentesting web —o prueba de penetración sobre aplicaciones web— es precisamente la disciplina que permite identificar esas debilidades de forma controlada, documentada y con propósito correctivo.
A diferencia de lo que el imaginario popular suele representar, un análisis de seguridad profesional no comienza rompiendo contraseñas ni ejecutando exploits. Comienza observando: recopilando información pública disponible, analizando la infraestructura que soporta el sistema y construyendo un mapa detallado del entorno antes de interactuar activamente con él.
Este artículo documenta ese proceso completo aplicado sobre una aplicación web real basada en WordPress, siguiendo la metodología OWASP Top 10 (2021) como marco de referencia.
Todo el análisis fue desarrollado con fines académicos en un entorno autorizado, cumpliendo con los principios del hacking ético.
Reconocimiento de red: la primera capa del pentesting web
En todo ejercicio de pentesting web, el reconocimiento de red es la fase inicial de cualquier auditoría de seguridad. Su objetivo no es atacar, sino entender: ¿qué hay ahí afuera? ¿Cómo está organizado? ¿Qué expone el sistema al mundo exterior?
Para el dominio analizado —www.smartzone.page.gd, alojado en InfinityFree sobre infraestructura de iFastNet— se aplicaron herramientas básicas disponibles en cualquier sistema operativo Windows: ping, tracert y nslookup.
Verificación ICMP y comportamiento del firewall
El primer paso fue ejecutar un ping al dominio. El resultado fue una pérdida de paquetes del 100 %, lo que en principio podría parecer que el servidor está caído. Sin embargo, la interpretación técnica es distinta: el host está activo, pero el proveedor de hosting bloquea deliberadamente las respuestas ICMP.
Esta política es estándar en entornos de hosting compartido, donde permitir respuestas ICMP facilitaría tareas de reconocimiento como la identificación de hosts activos o el análisis de latencia.
Este comportamiento ya revela información valiosa: el sistema no está aislado; está protegido. Y esa diferencia es importante para un analista de seguridad.
Trazado de ruta con Traceroute
La ejecución del comando tracert permitió reconstruir el camino que siguen los paquetes desde el equipo del analista hasta el servidor objetivo. Se identificaron nueve saltos visibles que atraviesan la red local del analista, la infraestructura del ISP (Claro Colombia), nodos de backbone internacional operados por Level3, y finalmente llegan a la red de iFastNet en Reino Unido. A partir del décimo salto, los nodos dejan de responder: otra práctica de seguridad deliberada para ocultar la topología interna de la red.
Con una sola herramienta pasiva fue posible inferir la ubicación geográfica del servidor, los proveedores de red involucrados y el carácter compartido de la infraestructura. Todo esto sin interactuar directamente con el servidor objetivo.
Resolución DNS y análisis de la IP pública
La consulta nslookup confirmó que el dominio resuelve a la dirección IP 185.27.134.115, perteneciente a iFastNet. La respuesta fue catalogada como “no autoritativa”, lo que indica que fue entregada desde la caché del ISP y no directamente desde los servidores DNS del dominio. Este detalle evidencia el funcionamiento distribuido y jerárquico del sistema DNS: las consultas no viajan directamente a la fuente, sino que pasan por intermediarios que almacenan respuestas en caché para optimizar los tiempos de resolución.
Escaneo de puertos en el pentesting web: identificando la superficie de exposición
Este paso es estandar en cualquier pentest web profesional. Con la IP identificada, el siguiente paso fue determinar qué servicios están expuestos públicamente. Para esto se utilizó Nmap, una de las herramientas de análisis de red más utilizadas en auditorías de seguridad.
El escaneo general reveló que de los más de 1.000 puertos analizados, 776 estaban filtrados y 221 cerrados. Solo tres permanecían abiertos: el puerto 80 (HTTP), el 443 (HTTPS) y el 2049 (NFS). Esta distribución refleja una superficie de exposición deliberadamente reducida, coherente con buenas prácticas de administración de servidores.
El escaneo de versiones identificó que los puertos 80 y 443 están gestionados por OpenResty, una plataforma basada en Nginx diseñada para manejar múltiples aplicaciones web con control avanzado de tráfico. El puerto 2049, por su parte, corresponde a NFS (Network File System), utilizado para la sincronización de archivos entre servidores. Su presencia pública representa un vector de ataque potencial si no está correctamente restringido a nivel de red.
Análisis DNS, WHOIS y certificados SSL/TLS en el pentesting web
El análisis de la capa de información pública —registros DNS, datos WHOIS y certificados digitales— permite comprender cómo está organizada la infraestructura y qué nivel de control tiene el propietario del sitio sobre ella.
Estructura DNS y dependencia del proveedor
Las consultas DNS revelaron que smartzone.page.gd no es un dominio independiente, sino un subdominio dentro de la zona administrada por el proveedor page.gd. Esto significa que el usuario del sitio no tiene control sobre sus propios servidores de nombres: toda la gestión DNS depende de ByetHost / InfinityFree. En consecuencia, no es posible configurar registros MX propios para gestionar correo electrónico, ni establecer políticas SPF o DKIM bajo este subdominio.
WHOIS y registro del dominio base
El análisis WHOIS sobre el dominio base page.gd confirmó que está registrado a través de Key Systems GmbH, un registrador internacional acreditado. El dominio se encuentra activo, con fechas de registro, actualización y expiración vigentes.
Evaluación del certificado SSL/TLS
El certificado del sitio fue emitido por ZeroSSL (Sectigo), utiliza cifrado EC de 256 bits con firma SHA384withECDSA y obtuvo una calificación general de A en Qualys SSL Labs, lo que indica una configuración criptográfica sólida.
Sin embargo, se identificó un problema relevante: el certificado fue emitido para el dominio base page.gd y no específicamente para el subdominio smartzone.page.gd. Esto genera un Name Mismatch que, si bien no compromete el cifrado en tránsito, sí debilita la autenticación de la identidad del sitio. Este hallazgo ilustra un principio fundamental: la presencia del candado HTTPS en el navegador no equivale a seguridad total.
Pentesting web con OWASP Top 10 (2021): auditoría de vulnerabilidades en WordPress
Con el mapa de infraestructura construido, el análisis se enfocó en la aplicación web: un sitio WordPress con WooCommerce. El marco metodológico utilizado fue el OWASP Top 10 (2021), el estándar internacional de referencia para la clasificación de riesgos en aplicaciones web. Es necesario tener presente que el pentesting web sobre WordPress requiere un enfoque metodológico.
A01 – Control de acceso deficiente: primer hallazgo del pentesting web
La vulnerabilidad más crítica encontrada fue la exposición pública de la lista completa de usuarios registrados a través de la API REST de WordPress. Accediendo al endpoint /wp-json/wp/v2/users sin ninguna credencial, el servidor respondió con nombres de usuario, IDs, slugs de inicio de sesión y el atributo is_super_admin: true para ambas cuentas. Este es uno de los hallazgos más criticos en este pentest web.
El impacto de esta exposición es crítico: un atacante puede utilizar los nombres de usuario obtenidos para lanzar ataques de fuerza bruta contra el panel de administración, reduciendo el problema a encontrar únicamente la contraseña correcta.
Mitigación recomendada: Deshabilitar la enumeración de usuarios en la API REST mediante código en functions.php o mediante plugins como Wordfence o iThemes Security. Implementar autenticación obligatoria para el acceso a endpoints sensibles.
A02 – Fallos criptográficos: HTTPS funcional pero con observaciones
El análisis del certificado SSL/TLS, documentado en la sección anterior, arrojó una calificación positiva. No obstante, se identificaron tres aspectos de mejora: el certificado es de tipo DV (Domain Validation), el nivel más básico; la extensión OCSP Must-Staple no está habilitada; y el certificado vencía el 22 de junio de 2026, con renovación automática no confirmada.
Mitigación recomendada: Verificar que la renovación automática esté configurada, habilitar OCSP Stapling y activar HSTS para forzar el uso de HTTPS a nivel de cabecera HTTP.
A03 – Inyección: vectores de XSS identificados
Se realizó una prueba de Cross-Site Scripting (XSS) inyectando el payload <script>alert('XSS')</script> en el buscador del sitio. El núcleo de WordPress escapó correctamente el script, impidiendo su ejecución. Sin embargo, el contenido ingresado sí se reflejó en el título de resultados y en la URL, confirmando la existencia del vector XSS reflejado.
Adicionalmente, se identificó que la sección de comentarios del blog estaba activa y sin moderación obligatoria, lo que constituye un vector clásico de XSS almacenado: un atacante podría inyectar código JavaScript en un comentario que quedaría persistido en la base de datos y se ejecutaría en el navegador de cualquier visitante.
Mitigación recomendada: Activar moderación obligatoria de comentarios, instalar el plugin Really Simple SSL para resolver el contenido mixto detectado, y eliminar el post “¡Hola mundo!” predeterminado que revela el estado de configuración inicial del sitio.
A04 – Diseño inseguro: el panel de administración, expuesto sin protección adicional
El panel de administración de WordPress (/wp-login.php) es accesible públicamente desde cualquier navegador, sin ninguna capa de protección previa: sin restricción por IP, sin autenticación HTTP adicional y sin limitación de intentos fallidos. Combinado con la exposición de usuarios documentada en A01, esto configura un escenario de riesgo compuesto: el atacante ya conoce los nombres de usuario válidos y tiene acceso irrestricto al formulario de autenticación. En terminos de pentesting web, esto configura un riesgo compuesto sobre la infraestructura del sitio web.
Mitigación recomendada: Cambiar la URL del inicio de sesión mediante plugins como WPS Hide Login, implementar limitación de intentos con Limit Login Attempts Reloaded y agregar CAPTCHA al formulario de acceso.
A05 – Configuración de seguridad incorrecta: el stack tecnológico al descubierto
La inspección del código fuente HTML de la página principal reveló etiquetas <meta name="generator"> que exponen públicamente las versiones exactas de todo el stack tecnológico instalado: WordPress 6.9.4, WooCommerce 10.6.2, Everest Forms 3.4.4, Contact Form 7 6.1.5 y GlotPress 4.0.3.
Esta información permite a cualquier atacante cruzar las versiones identificadas con bases de datos públicas de vulnerabilidades como el National Vulnerability Database (NVD) o el repositorio de WPScan, obteniendo una lista de exploits aplicables directamente a la instalación sin necesidad de acceso privilegiado.
Mitigación recomendada: Eliminar las etiquetas <meta name="generator"> mediante código en functions.php o con plugins de hardening como Wordfence, y remover los parámetros de versión ?ver= de los recursos estáticos.
A06 – Componentes vulnerables y obsoletos: historial crítico en plugins instalados
El plugin Everest Forms (versión instalada: 3.4.4) presenta un historial de vulnerabilidades críticas en versiones anteriores, incluyendo subida arbitraria de archivos sin autenticación (CVSS 9.8) e inyección de objetos PHP (CVSS 8.1). La versión instalada es posterior a todas las correcciones, pero la exposición pública de las versiones exactas mantiene el riesgo latente: cualquier vulnerabilidad de día cero aún no publicada haría al sitio inmediatamente identificable como objetivo.
Mitigación recomendada: Suscribir alertas de seguridad de WPScan, habilitar actualizaciones automáticas de plugins desde el panel de WordPress y eliminar todos los complementos inactivos que amplían la superficie de ataque sin aportar funcionalidad.
A07 – Fallos de identificación y autenticación: enumeración por mensajes de error
Se identificó una segunda vía de enumeración de usuarios a través de los mensajes de error del formulario de login. Al introducir un usuario existente con contraseña incorrecta, el sistema responde: “la contraseña que has introducido para el nombre de usuario admin no es correcta”. Al intentar con un usuario inexistente, responde: “El nombre de usuario no está registrado en este sitio”.
Esta diferencia en los mensajes permite a un atacante construir una lista de usuarios válidos mediante ensayo y error, sin autenticación exitosa. Además, el formulario no implementa ningún bloqueo temporal tras intentos fallidos ni autenticación multifactor.
Mitigación recomendada: Estandarizar los mensajes de error de autenticación con un texto genérico, implementar bloqueo por IP tras intentos fallidos y habilitar autenticación de dos factores (2FA) para cuentas con rol de administrador.
A08 – Fallos en la integridad del software y los datos: wp-cron con 71 acciones vencidas
Se identificó un hallazgo positivo: todos los plugins instalados provienen del repositorio oficial de WordPress.org, que aplica revisión de código y firma criptográfica de paquetes antes de su publicación. Sin embargo, el sistema reportó la advertencia de 71 acciones vencidas en el Action Scheduler, el sistema de tareas en cola utilizado por WooCommerce. Esto indica que el sistema wp-cron de WordPress no está funcionando correctamente, posiblemente por una restricción de red del hosting que impide las solicitudes de loopback.
Mitigación recomendada: Investigar la causa raíz del fallo en wp-cron con el proveedor de hosting y configurar un cron real del sistema operativo como alternativa si InfinityFree lo permite.
A09 – Fallos en el registro y la monitorización de seguridad: sin visibilidad ante ataques
La aplicación no tiene instalado ningún plugin de seguridad con capacidades de registro y monitoreo. Esto significa que no existe ningún mecanismo que genere una alerta ante un ataque de diccionario automatizado contra /wp-login.php, ante la creación de un nuevo administrador o ante cambios en archivos del sistema.
La herramienta de diagnóstico integrada de WordPress identificó de forma autónoma 7 mejoras pendientes, incluyendo dos alertas de seguridad directa: eliminar complementos inactivos y eliminar temas inactivos. Ambos representan código ejecutable en el servidor que amplía la superficie de ataque sin aportar funcionalidad activa.
Mitigación recomendada: Instalar Wordfence Security, que incluye firewall de aplicaciones web, escáner de malware y registro de intentos de autenticación. Complementar con WP Activity Log para auditar todas las acciones realizadas en el panel de administración.
A10 – SSRF: la API REST como superficie de reconocimiento y vector potencial
Accediendo al endpoint /wp-json/wp/v2/ sin autenticación, se obtuvo el mapa completo de rutas disponibles en la API REST de WordPress, incluyendo endpoints para gestión de entradas, páginas, medios, revisiones y elementos de menú. Esta visibilidad total de la arquitectura interna facilita el reconocimiento previo a cualquier exploit.
Dentro de ese mapa se identificó el endpoint POST /wp/v2/media/{id}/edit, que acepta un parámetro src con formato URI. Si no valida correctamente el origen de la URL proporcionada, podría ser utilizado para forzar al servidor a realizar solicitudes hacia recursos internos de la infraestructura. Adicionalmente, la Biblioteca de Medios permite cargar imágenes mediante URL externas, lo que instruye al servidor a ejecutar una solicitud HTTP GET hacia el destino indicado.
Conclusiones del pentesting web: resumen de hallazgos y mitigaciones
El análisis completo de pentesting web, que combina técnicas de reconocimiento pasivo con una auditoría estructurada bajo OWASP Top 10 (2021), permitió construir una imagen detallada del estado de seguridad de la aplicación. De las diez categorías evaluadas, cuatro presentan vulnerabilidades críticas o altas confirmadas (A01, A04, A07, A09), cuatro tienen riesgos medios o parcialmente mitigados (A02, A03, A05, A06), una muestra controles positivos con observaciones (A08) y una expone una superficie de riesgo condicionada a otros vectores (A10).
Lo más relevante de este ejercicio no está en la lista de hallazgos individuales, sino en la relación entre ellos. La exposición de usuarios por API (A01) alimenta directamente la viabilidad de ataques de fuerza bruta (A04 y A07). La exposición de versiones de software (A05) habilita la búsqueda de exploits aplicables a los componentes instalados (A06). La ausencia de monitoreo (A09) hace que todos los vectores anteriores sean silenciosos: un ataque exitoso podría estar ocurriendo en este momento sin que el administrador lo sepa.
Este es el valor del pentesting web: no encontrar el error más espectacular, sino entender cómo los errores se conectan entre sí para construir escenarios de riesgo que ninguno de ellos, por separado, haría evidente. Y más importante aún, proponer medidas de mitigación concretas que puedan implementarse antes de que lo haga alguien con intenciones distintas a las de un análisis ético.
La diferencia entre un atacante y un profesional de seguridad no radica en las herramientas que usan —suelen ser las mismas—, sino en la intención, el marco metodológico y la responsabilidad con la que se ejecuta el análisis.
Este análisis fue desarrollado en el marco de la asignatura de Hacking Ético de la Universidad Central (Bogotá, Colombia), sobre un entorno autorizado por los propios estudiantes. Todas las pruebas se realizaron con propósito exclusivamente académico.
Créditos:
Autores: Andrés Camilo Corchuelo Poveda, Maria Paula Gómez Vanegas, Sergio Vergara Vega
Editor: Carlos Iván Pinzón Romero
Código: UCHEG1-1
Universidad: Universidad Central
Fuentes
Fundación OWASP. (2021). OWASP Top 10 : 2021 – Los diez riesgos de seguridad más críticos para aplicaciones web . Proyecto Abierto Mundial de Seguridad de Aplicaciones. https://owasp.org/Top10/2021/
Fundación OWASP. (24 de septiembre de 2021). Introducción – OWASP Top 10 :2021 . Proyecto Abierto Mundial de Seguridad de Aplicaciones. https://owasp.org/Top10/2021/A00_2021_Introduction/
Fundación OWASP. (sf). Acerca de la Fundación OWASP . Proyecto Abierto Mundial de Seguridad de Aplicaciones. https://owasp.org/about/
Fundación OWASP. (2020). Guía de pruebas de seguridad web de OWASP v4.2 . Proyecto Abierto Mundial de Seguridad de Aplicaciones. https://owasp.org/www-project-web-security-testing-guide/v42/
Fundación OWASP. (sf). Los diez principales riesgos de seguridad de las aplicaciones web según OWASP . Proyecto Abierto Mundial de Seguridad de Aplicaciones. https://owasp.org/www-project-top-ten/
WPScan. (sf). Base de datos de vulnerabilidades de WordPress . WPScan SAS. https://wpscan.com/
