Auditoría de seguridad WordPress: pentesting y vulnerabilidades
Una auditoría de seguridad WordPress es el primer paso para identificar vulnerabilidades antes de que un atacante pueda explotarlas. Cuando diseñamos y lanzamos una tienda virtual en WordPress, lo último en lo que pensamos es en cómo podría ser vulnerada.
Sin embargo, precisamente esa omisión es el punto de partida de la mayoría de los incidentes de seguridad que afectan a sitios web en Colombia y el resto de Latinoamérica cada año. Con el objetivo de cerrar esa brecha y documentar hallazgos concretos, realizamos una auditoría completa sobre una tienda virtual propia, desplegada en Hostinger con WooCommerce, aplicando metodologías como OWASP Top 10, análisis DNS/WHOIS/SSL y reconocimiento OSINT.
Este artículo documenta paso a paso lo que encontramos: desde la infraestructura de red hasta vulnerabilidades reales que podrían comprometer datos de clientes, permitir ataques de fuerza bruta o exponer el código fuente del sitio.
Por Qué Necesitas un Contrato Antes de Hackear tu Propio Sitio
El término “hacking ético” no es un eufemismo; es una categoría jurídica con implicaciones legales muy concretas. En Colombia, la Ley 1273 de 2009 tipifica como delito el acceso no autorizado a sistemas informáticos, la intercepción de datos, el daño informático y el uso de software malicioso, con penas que van desde 48 meses hasta 8 años de prisión. La única diferencia entre un pentester legal y un ciberataque ilegal es, en palabras simples, un papel firmado: el contrato de autorización.
Marcos de referencia como el PTES (Penetration Testing Execution Standard), el NIST SP 800-115 y la OWASP Testing Guide son unánimes al respecto: antes de ejecutar cualquier
prueba, incluso sobre sistemas propios, es obligatorio documentar formalmente el alcance, las restricciones de tiempo, las herramientas autorizadas, las responsabilidades de cada parte y los procedimientos de escalamiento ante incidentes. Omitir este paso no solo infringe las buenas prácticas del sector, sino que puede anular la validez legal de cualquier hallazgo y exponer al auditor a responsabilidades civiles y penales.
Para esta auditoría, todas las pruebas se ejecutaron sobre un sitio web creado y administrado íntegramente por el equipo auditor, bajo un contrato de autorización firmado antes de iniciar cualquier actividad técnica. Ningún sistema de terceros fue vulnerado, ningún dato fue modificado ni eliminado, y todos los hallazgos se documentaron con el único propósito de aprender a identificarlos y corregirlos.
Cómo realizar una auditoría de seguridad WordPress paso a paso
El entorno auditado fue configurado como una tienda virtual funcional que replica fielmente el stack tecnológico que encontraría cualquier auditor al evaluar un e-commerce colombiano de mediana escala.
Esta combinación es la misma que encontraría cualquier analista al revisar miles de sitios activos en la región: un CMS popular, hosting compartido de bajo costo, CDN configurado automáticamente y un conjunto de plugins instalados sin revisión sistemática de seguridad. Lo que aquí documentamos aplica, con mínimas variaciones, a la gran mayoría de instalaciones WordPress en producción hoy.
Fase 1 — Reconocimiento de Red en una auditoría de seguridad WordPress
El reconocimiento es la primera y más determinante fase de cualquier proceso de auditoría de seguridad WordPress o de cualquier sistema web. Su objetivo no es vulnerar nada: es comprender. Un auditor que no conoce la topología de red de su objetivo, los servicios que expone y los posibles vectores de entrada está actuando a ciegas, lo que reduce dramáticamente la efectividad de las pruebas posteriores. Existen dos modalidades complementarias:
1.1 Prueba de Conectividad con Ping: La Primera Huella Digital del Servidor
El comando ping utiliza el protocolo ICMP (Internet Control Message Protocol,
RFC 792, capa 3 del modelo OSI) para enviar mensajes Echo Request (tipo 8) y
recibir Echo Reply (tipo 0) del servidor destino. En un contexto de pentesting,
el ping cumple tres funciones simultáneas: confirma si el host está activo, mide la latencia
de ida y vuelta (RTT) en milisegundos, y —crucialmente— revela la dirección IP que
resuelve el dominio, que puede ser la del CDN y no la del servidor físico real.
Se ejecutaron tres pings sucesivos en momentos distintos sobre el dominio objetivo
palevioletred-wildcat-394676.hostingersite.com. Cada ejecución resolvió a
una IP diferente, confirmando el balanceo de carga activo en la infraestructura.
Primer Ping
En el primer ping, el dominio resolvió a 191.101.104.36
(alias free.cdn.hstgr.net), con tiempos de respuesta entre 84 ms y 210 ms.
El pico atípico en el tercer paquete (210 ms) es completamente normal en redes CDN,
donde la ruta puede variar ligeramente entre paquetes dependiendo del nodo que sirva
la respuesta.
Auditoría de seguridad WordPress – segundo y tercer ping evidenciando rotación de IP por CDN Hostinger
El segundo ping resolvió a 212.1.212.250 con tiempos
similares pero un pico en el quinto paquete (269 ms), y el tercer ping
entregó una tercera IP diferente: 195.35.60.114. Este comportamiento de
rotación de IPs entre ejecuciones es la confirmación más directa de que el sitio opera
detrás de un sistema de balanceo de carga activo. Desde la perspectiva de seguridad,
esto significa que no existe un único nodo que “derribar” para afectar la disponibilidad
del sitio, lo que representa una ventaja defensiva importante frente a ataques DDoS.
La verificación adicional con curl ipinfo.io/[IP] confirmó que todas las
IPs pertenecen a AS47583 Hostinger International Limited, datacenter
de Asheville, North Carolina. Aunque el sitio es administrado desde Colombia, sus
servidores físicos residen en territorio estadounidense, con implicaciones tanto de
rendimiento (latencia transatlántica promedio ~85 ms desde Bogotá) como de jurisdicción
legal en caso de incidentes de seguridad.
1.2 Traceroute: El Mapa de Red que la Infraestructura No Quiere que Veas
La herramienta traceroute (Linux) o tracert (Windows) mapea
la ruta de los paquetes IP desde el equipo del auditor hasta el servidor destino, enviando
paquetes con valores TTL (Time To Live) crecientes. Cuando el TTL expira en un router
intermedio, ese dispositivo descarta el paquete y responde con un mensaje ICMP
Time Exceeded, revelando su dirección IP y la latencia hasta ese punto. Salto a
salto, se construye el mapa completo de la red entre origen y destino.
Auditoría de seguridad WordPress – traceroute con todos los saltos ocultos mostrando infraestructura CDN protegida
El resultado fue contundente: a partir del segundo salto, todos los routers intermedios
respondieron con * * *, lo que indica que están configurados para ignorar
las sondas ICMP/UDP usadas por traceroute. El único salto visible fue el primero,
correspondiente al gateway de la máquina virtual (10.0.2.2). Esta respuesta
no es un error; es exactamente el comportamiento esperado y deseado en infraestructuras
CDN corporativas modernas: impide que un atacante externo conozca la topología interna
de la red, el número de dispositivos intermedios o la ubicación física de los servidores.
Como alternativa, se intentó el traceroute con el flag -T -p 80 (TCP sobre
puerto HTTP), que en ocasiones logra traversar firewalls que bloquean UDP. Este método
reveló dos saltos: el gateway local y un nodo con IP pública 191.101.104.121
perteneciente al CDN de Hostinger. Sin embargo, la ruta completa hasta el servidor de
origen permaneció opaca, confirmando que la arquitectura de red del objetivo cuenta con
una protección perimetral robusta y bien configurada.
1.3 Escaneo de Puertos con Nmap: El Rayos X de la Infraestructura
Nmap (Network Mapper) es la herramienta de referencia mundial para el descubrimiento de hosts y servicios en red. Permite identificar puertos abiertos, detectar versiones exactas de software mediante service fingerprinting, inferir el sistema operativo del servidor y ejecutar scripts de detección de vulnerabilidades a través del motor NSE (Nmap Scripting Engine). Para esta auditoría de seguridad WordPress se ejecutaron tres variantes con profundidad creciente.
Escaneo Rápido — nmap -F
Auditoría de seguridad WordPress – nmap -F mostrando solo puertos 80 y 443 abiertos con 98 filtrados
El escaneo rápido con el flag -F analiza los 100 puertos TCP más comunes.
El resultado fue claro y positivo desde el punto de vista defensivo: 98 puertos
están filtrados (bloqueados por firewall, sin respuesta) y únicamente dos están
abiertos: el puerto 80/tcp (HTTP) y el puerto 443/tcp
(HTTPS). Esto significa que la superficie de ataque expuesta está reducida al
mínimo estrictamente necesario para operar un sitio web. No hay puertos de gestión
remota abiertos, como el 22 (SSH), 3306 (MySQL), 3389 (RDP) o 8080 (HTTP alternativo),
lo que representa una buena práctica de seguridad: el acceso administrativo al servidor
se realiza por canales seguros y no expuestos al internet público.
Detección de Versiones — nmap -sV
Auditoría de seguridad WordPress – nmap -sV revelando servidor nginx y CDN hcdn de Hostinger con service fingerprin
El escaneo de versiones con el flag -sV aplica técnicas de service
fingerprinting para determinar exactamente qué software corre detrás de cada puerto abierto.
El resultado identifica el servicio en ambos puertos como hcdn (el CDN
propietario de Hostinger), y dentro del bloque Service Fingerprint se puede leer
claramente la cadena <center>nginx</center>, confirmando que el
servidor web subyacente es nginx. Las versiones HTTP soportadas son
HTTP/1.0, HTTP/1.1 y HTTP/3.
Este hallazgo tiene implicaciones de seguridad directas. Exponer el nombre del software
del servidor en las cabeceras HTTP (Server: hcdn) y en las páginas de error
internas le entrega a cualquier atacante un vector de investigación: basta con buscar en
bases de datos de vulnerabilidades como el
NVD del NIST
los CVE asociados a la versión de nginx detectada para identificar exploits aplicables.
La recomendación inmediata es ocultar la cabecera Server mediante la directiva
server_tokens off; en la configuración de nginx.
Escaneo Agresivo — nmap -A
Auditoría de seguridad WordPress – nmap -A con scripts NSE revelando robots.txt redireccionamiento HTTP a HTTPS y múltiples IPs
El escaneo agresivo con el flag -A activa simultáneamente la detección de
versiones, el traceroute integrado y la ejecución de scripts NSE. Los hallazgos más
relevantes fueron tres: primero, la redirección automática de HTTP a HTTPS
mediante un código 302 Moved, que confirma que ningún contenido se sirve
en texto plano. Segundo, la detección de que el archivo robots.txt contiene
al menos una entrada disallowed; paradójicamente, este archivo actúa como un
mapa de directorios sensibles para cualquier auditor, ya que si algo aparece allí es porque
el administrador considera que no debe indexarse. Tercero, la confirmación de múltiples
direcciones IPv4 e IPv6 asociadas al dominio, que refuerza el modelo de balanceo de carga
identificado previamente.
Fase 2 — DNS, WHOIS y SSL en una auditoría de seguridad WordPress
Una de las fases más subestimadas de una auditoría de seguridad WordPress es el análisis de la información pública disponible sobre el dominio. Los registros DNS, las bases de datos WHOIS y los certificados SSL son fuentes abiertas que cualquier persona puede consultar sin generar un solo paquete de tráfico hacia el servidor objetivo. La cantidad de información estratégica que revelan sobre la infraestructura, las herramientas utilizadas y los posibles vectores de ingeniería social es, en muchos casos, sorprendente.
2.1 Registros DNS con nslookup: Tres Capas de Información Crítica
Registro A — La IP que Está Detrás del Dominio
Auditoría de seguridad WordPress – nslookup registro tipo A mostrando alias free.cdn.hstgr.net con IPs del CDN Hostinger
La consulta nslookup -type=A [dominio] devolvió una respuesta no autoritativa
que reveló el hallazgo más importante de esta fase: el dominio auditado no apunta
directamente al servidor de origen. En cambio, es un alias (CNAME) que redirige
el tráfico hacia free.cdn.hstgr.net, devolviendo simultáneamente dos
direcciones IP: 191.101.104.113 y 191.96.144.240. Esto confirma
que el sitio opera detrás de la CDN de Hostinger, lo que oculta la IP real del servidor
físico y distribuye la carga entre múltiples nodos.
Desde la perspectiva del pentester, este hallazgo es fundamental: cualquier escaneo o ataque dirigido a estas IPs impactará sobre los nodos del CDN, no sobre el servidor de origen real. Esta arquitectura es una de las defensas más efectivas contra ataques DDoS directos y dificulta significativamente el rastreo de la infraestructura física subyacente.
Registro MX — Qué Dice (y Qué Oculta) Sobre el Correo Corporativo
Auditoría de seguridad WordPress – nslookup registro MX mostrando SOA de Cloudflare sin servidores de correo expuestos
La consulta del Registro MX (nslookup -type=MX hostingersite.com) no devolvió
servidores de correo convencionales como Outlook o Google Workspace. En su lugar, la consola
arrojó los datos del registro de Autoridad Principal (SOA), revelando que la gestión completa
de DNS está delegada a la plataforma Cloudflare mediante los name servers
emily.ns.cloudflare.com y dns.cloudflare.com.
Este resultado tiene dos lecturas desde la perspectiva de seguridad. Por un lado, la ausencia de servidores de correo expuestos es positiva: impide que un atacante determine qué herramientas ofimáticas usan internamente los empleados (dato valioso para ataques de ingeniería social dirigida). Por otro lado, la delegación total a Cloudflare confirma que toda la seguridad DNS depende de la solidez de esa plataforma, lo que hace crítico mantener las credenciales de esa cuenta extremadamente protegidas.
Registro TXT — La Política de Correo que Elimina el Email Spoofing
Auditoría de seguridad WordPress – nslookup registro TXT mostrando política SPF v=spf1 -all configuración estricta
La consulta del Registro TXT (nslookup -type=TXT hostingersite.com) reveló
la cadena v=spf1 -all. Este es el estándar SPF (Sender Policy Framework),
un protocolo de autenticación de correo electrónico que define qué servidores están
autorizados a enviar correos a nombre de un dominio. El parámetro -all,
conocido como Hard Fail, indica que ninguna dirección IP está autorizada
a enviar correos usando @hostingersite.com. Cualquier mensaje que intente
hacerse pasar por ese dominio será rechazado directamente por los servidores de destino.
Esta configuración elimina prácticamente por completo el riesgo de email spoofing contra
este dominio, lo que representa una excelente práctica de higiene criptográfica.
2.2 WHOIS: Qué Sabe el Mundo sobre el Propietario de tu Dominio
Auditoría de seguridad WordPress – resultado WHOIS mostrando Hostinger operations UAB clientTransferProhibited y nameservers Cloudflare
La búsqueda WHOIS sobre hostingersite.com mediante la herramienta Sysinternals
Whois v1.21 reveló la siguiente información de interés para la auditoría:
El dato más relevante desde la perspectiva defensiva es el estado
clientTransferProhibited. Este mecanismo de seguridad bloquea el dominio
a nivel de registro, impidiendo que sea transferido a otro registrar sin autorización
explícita del propietario. Esto previene el Domain Hijacking, una técnica de
ataque en la que un actor malicioso intenta tomar el control del dominio mediante
ingeniería social dirigida al registrar o mediante el aprovechamiento de credenciales
comprometidas. Al tener este bloqueo activo, incluso si un atacante obtiene las credenciales
de la cuenta de Hostinger, no podría transferir el dominio sin un proceso de validación
adicional.
Por otro lado, el registro WHOIS no expone ningún dato personal del propietario real del
sitio web (nombre, teléfono, correo), lo que cumple con los estándares actuales de
privacidad en internet y dificulta las tareas de reconocimiento para ataques de ingeniería
social. El único punto de mejora identificado es la ausencia de DNSSEC activo
(unsigned), una capa adicional de autenticación DNS que protege contra
ataques de envenenamiento de caché.
2.3 Certificado SSL/TLS: Una Criptografía de Grado Bancario
Auditoría de seguridad WordPress – análisis openssl s_client mostrando TLS 1.3 certificado DigiCert RapidSSL cadena de confianza válida
El análisis del certificado SSL con el comando
openssl s_client -showcerts -connect [dominio]:443 arrojó los resultados más
positivos de toda la auditoría desde el punto de vista criptográfico. El handshake TLS fue
exitoso y reveló la siguiente cadena de confianza:
DigiCert Inc es una de las Autoridades Certificadoras comerciales de mayor reconocimiento
a nivel mundial, lo que garantiza que todos los navegadores modernos confíen en el
certificado sin mostrar advertencias de seguridad. La negociación bajo TLS 1.3 con el
cifrador TLS_AES_256_GCM_SHA384 significa que toda la comunicación entre
el navegador del cliente y el servidor está protegida con cifrado de 256 bits, el mismo
estándar que utilizan las instituciones financieras y los organismos gubernamentales para
proteger transacciones sensibles.
El certificado de tipo Wildcard (*.hostingersite.com) es práctico desde el
punto de vista operativo, ya que cubre automáticamente cualquier subdominio sin necesidad
de emitir certificados individuales. Sin embargo, conviene monitorear periódicamente los
registros de Transparencia de Certificados (CT Logs) de este dominio, ya que cualquier
certificado emitido para un subdominio de hostingersite.com aparecerá en esos
registros públicos y podría revelar subdominios internos no intencionados.
También se identificó, mediante el comando nslookup -type=NS hostingersite.com,
que los name servers autoritativos son emily.ns.cloudflare.com y
terin.ns.cloudflare.com, con soporte completo para IPv4 e IPv6, lo que confirma
la infraestructura dual-stack y la delegación total de la autoridad DNS a Cloudflare.
Video Recomendado: Introducción al Pentesting Web con OWASP
Para complementar los conceptos técnicos de esta auditoría, te recomendamos el siguiente recurso audiovisual oficial del proyecto OWASP, que explica de forma visual las categorías del Top 10 y cómo afectan a aplicaciones web reales como WordPress:
Video: OWASP Top 10 2021 — Explicación Completa para Desarrolladores Web (YouTube, OWASP Foundation)
Fase 3 — OWASP Top 10 en una auditoría de seguridad WordPress
El OWASP Top 10 es el estándar de referencia más utilizado en el mundo para evaluar la seguridad de aplicaciones web. Publicado y mantenido por la Open Web Application Security Project Foundation, clasifica las diez categorías de riesgo más críticas basándose en datos reales de miles de organizaciones a nivel global. A continuación documentamos los hallazgos para cada categoría aplicada durante esta auditoría de seguridad WordPress.
A01 — Control de Acceso Roto (Broken Access Control)
Esta categoría evalúa si un usuario puede acceder a páginas, archivos o funciones a las que no debería tener acceso. Las pruebas se realizaron sobre tres rutas críticas de WordPress:
Auditoría de seguridad WordPress – curl wp-admin mostrando HTTP 301 sin exposición de contenido con content-security-policy activo
/wp-admin (Panel de Administración): el acceso al panel de administración
mediante curl -I https://[dominio]/wp-admin devolvió un código
HTTP/2 301 que redirige correctamente hacia /wp-admin/ sin exponer
ningún contenido sin autenticación. Adicionalmente, la cabecera
content-security-policy: upgrade-insecure-requests confirma que hay una política
de seguridad de contenido activa. Resultado: sin vulnerabilidad en este vector.
Auditoría de seguridad WordPress – curl wp-config.php devolviendo HTTP 200 exponiendo PHP 8.3.30 vulnerabilidad crítica
/wp-config.php (Archivo de Configuración): aquí se identificó la primera
vulnerabilidad concreta de la auditoría. El acceso a /wp-config.php devolvió
un HTTP/2 200, lo que significa que el archivo es accesible públicamente
y que la cabecera x-powered-by: PHP/8.3.30 queda expuesta a cualquier
visitante. Si bien el contenido del archivo en sí no se sirve directamente gracias a la
configuración de PHP, la respuesta 200 confirma su existencia e indica la versión exacta
del intérprete, información que puede usarse para buscar CVE específicos de esa versión.
Resultado: vulnerabilidad media — exposición de información técnica.
Recomendación: añadir la siguiente regla en el archivo
.htaccess de la raíz del sitio para devolver un error 403 y ocultar la
cabecera x-powered-by:
<Files wp-config.php>
order allow,deny
deny from all
</Files>Auditoría de seguridad WordPress – curl wp-content devolviendo HTTP 301 sin vulnerabilidad de broken access control
/wp-content (Directorio de Contenido): la respuesta fue
HTTP/2 301 con redirección correcta y content-security-policy
activo, sin exposición de contenido sin autenticación. Resultado: sin vulnerabilidad.
A02 — Fallos Criptográficos (Cryptographic Failures SSL/TLS)
Auditoría de seguridad WordPress – nmap ssl-enum-ciphers mostrando TLS 1.2 y TLS 1.3 con todos los cifradores calificados grado A
El escaneo con el script NSE de Nmap --script ssl-enum-ciphers -p 443 enumeró
todas las suites criptográficas disponibles en el servidor. El análisis confirmó que solo
están habilitados cifradores calificados como grado A tanto en TLS 1.2
como en TLS 1.3:
No se detectaron cifradores obsoletos como RC4, DES, 3DES o EXPORT, lo que significa que el sitio no es vulnerable a ataques de downgrade criptográfico conocidos como POODLE, BEAST o DROWN. Resultado: sin vulnerabilidad significativa.
A03 — Inyección SQL (SQL Injection)
Auditoría de seguridad WordPress – formulario de login con payload OR 1=1 mostrando mensaje de error genérico sin exposición de base de datos
La inyección SQL ocurre cuando un atacante inserta código SQL malicioso en campos de
formularios web para manipular directamente la base de datos subyacente. La prueba clásica
OR '1'='1 fue ejecutada manualmente en el formulario de inicio de sesión.
El sistema respondió con un mensaje de error genérico que simplemente indica que el usuario
no existe, sin revelar información sobre el esquema de base de datos, la versión
de MySQL/MariaDB ni el contenido de ninguna tabla. Este comportamiento indica el
uso de consultas parametrizadas o prepared statements en el backend de WordPress.
Auditoría de seguridad WordPress – resultado de sqlmap bloqueado con HTTP 403 por WAF activo en el sitio
Adicionalmente, la herramienta automatizada sqlmap fue ejecutada contra el formulario de PQR del sitio. El servidor respondió con un HTTP 403 bloqueando el escaneo automático desde el primer intento, y la herramienta reportó que no encontró formularios en la URL objetivo porque el formulario utiliza renderizado JavaScript dinámico, lo que lo hace invisible para sqlmap sin una configuración avanzada con Selenium. Resultado: sin vulnerabilidad confirmada.
A04 — Diseño Inseguro (Insecure Design): La Vulnerabilidad que Nadie Ve hasta que Es Tarde
Las vulnerabilidades de diseño inseguro no son errores de código: son decisiones arquitectónicas tomadas desde el principio del desarrollo que crean brechas de seguridad estructurales. A diferencia de un bug que puede parchearse con una actualización, el diseño inseguro requiere cambios en la lógica funcional del sistema.
Auditoría de seguridad WordPress – formulario de login con más de 5 intentos fallidos sin bloqueo vulnerabilidad fuerza bruta
La prueba ejecutada fue directa: se realizaron más de cinco intentos de inicio de sesión
con credenciales incorrectas sobre el panel /wp-login.php, usando nombres de
usuario y contraseñas distintas en cada intento. El sistema nunca activó ningún mecanismo
de bloqueo temporal, no mostró ningún CAPTCHA adicional después del tercer intento,
no incrementó el tiempo de espera entre intentos y no bloqueó la dirección IP de origen.
Este comportamiento expone el sitio a ataques de fuerza bruta automatizados, en los que
herramientas como Hydra o Burp Suite Intruder pueden probar miles de combinaciones de
contraseñas por minuto sin interrupción.
⚠ Vulnerabilidad crítica — Riesgo alto. Esta es, sin duda, la vulnerabilidad más peligrosa identificada durante toda la auditoría, porque un atacante que obtenga acceso al panel de administración puede comprometer completamente el sitio, instalar backdoors, robar datos de clientes o redirigir el tráfico a sitios maliciosos.
Recomendación: instalar el plugin Limit Login Attempts Reloaded (gratuito, más de dos millones de instalaciones activas) y configurarlo para bloquear al usuario y la IP tras exactamente tres intentos fallidos, con un período de bloqueo progresivo. Adicionalmente, se recomienda implementar autenticación de dos factores (2FA) mediante plugins como WP 2FA o Google Authenticator for WordPress.
A05 — Mala Configuración de Seguridad (Security Misconfiguration)
Auditoría de seguridad WordPress – nikto escaneando el sitio mostrando múltiples cabeceras de seguridad faltantes PHP expuesto y vulnerabilidades
El análisis con nikto v2.5.0, la herramienta de escaneo de servidores web
de referencia en el sector, identificó cuatro vulnerabilidades activas relacionadas con
la configuración de cabeceras HTTP de seguridad. Esta es la categoría con más hallazgos
de toda la auditoría, y la más representativa de lo que ocurre en la mayoría de las
instalaciones WordPress en producción que no han pasado por una revisión de seguridad
especializada:
1. Vulnerable a Clickjacking:
la cabecera X-Frame-Options no está presente. Esta cabecera le indica al navegador si una página puede ser incrustada dentro de un <iframe> en otro sitio. Sin ella, un atacante podría crear una página maliciosa que incruste el checkout de la tienda dentro de un iframe invisible, solapado sobre un botón de clic inocente. Cuando el cliente hace clic en lo que cree que es un botón legítimo, en realidad está interactuando con el formulario de pago del sitio real debajo (técnica conocida como UI Redressing).
Auditoría de seguridad WordPress – nikto identificando ausencia de X-Frame-Options y X-Content-Type-Options vulnerabilidades clickjacking MIME sniffing
2. Vulnerable a MIME Sniffing:
la cabecera X-Content-Type-Options: nosniff no está configurada. Esto permite que los navegadores más antiguos o en modos específicos “adivinen” el tipo MIME de un archivo, lo que puede llevar a que un archivo aparentemente inofensivo (como un .txt subido por un usuario) sea interpretado y ejecutado como HTML o JavaScript por el navegador.
Auditoría de seguridad WordPress – nikto identificando ausencia HSTS y Content-Encoding deflate vulnerabilidad MIME Sniffing
3. Vulnerable a MITM (Man-in-the-Middle):
la cabecera Strict-Transport-Security (HSTS) no está definida. Sin HSTS, el navegador no tiene instrucciones explícitas de usar siempre HTTPS en visitas futuras al sitio. Esto deja abierta una ventana temporal de ataque: en el momento en que un usuario accede por primera vez a la URL HTTP antes del redireccionamiento automático a HTTPS, un atacante posicionado en la misma red (por ejemplo, en una red Wi-Fi pública) podría interceptar esa primera solicitud y realizar un ataque de degradación de protocolo.
Auditoría de seguridad WordPress – nikto identificando ausencia HSTS y Content-Encoding deflate vulnerabilidades MITM
4. Vulnerable a BREACH Attack:
La cabecera Content-Encoding: deflate indica que el servidor comprime las respuestas HTTP con el algoritmo DEFLATE. Cuando la compresión HTTP se combina con HTTPS y el contenido comprimido incluye secretos predecibles (como tokens CSRF), un atacante con capacidad de observar el tráfico cifrado puede inferir el valor del secreto mediante el ataque BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext), que explota la correlación entre la longitud del texto cifrado comprimido y el contenido del secreto.
Auditoría de seguridad WordPress – nikto identificando ausencia HSTS y Content-Encoding deflate vulnerabilidade BREACH Attack
Corrección para todas las vulnerabilidades de cabeceras: añadir las
siguientes directivas en el archivo .htaccess o en la configuración del
servidor web:
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"A06 — Componentes Vulnerables (Vulnerable and Outdated Components)
Auditoría de seguridad WordPress – WPScan identificando tema flash-pro con versión CSS 6.9.4 y enumeración de plugins en proceso
La herramienta WPScan
(WordPress Security Scanner, v3.8.25) fue ejecutada con el flag --enumerate p
para identificar los plugins activos y sus versiones. El escaneo confirmó que el tema activo
es Flash Pro, detectado mediante la URL del archivo CSS
(style.css?ver=6.9.4), aunque la versión exacta del tema no pudo determinarse
definitivamente por métodos pasivos.
El WAF bloqueó la enumeración agresiva de plugins tras 754 solicitudes procesadas, lo que
impidió obtener el listado completo de los 19 plugins activos. Este comportamiento del WAF
es, en sí mismo, un indicador positivo: el sistema está activamente monitoreando y limitando
el reconocimiento automatizado. Sin embargo, el hecho de que la versión del core de WordPress
(6.9.4) y del tema sean detectables mediante métodos pasivos sigue siendo un
vector de información que debe gestionarse.
Recomendación: mantener WordPress core, todos los temas y plugins
actualizados a la última versión estable mediante actualizaciones automáticas. Eliminar
temas y plugins inactivos que no se utilicen. Ocultar la versión de WordPress de los
metadatos del HTML y del archivo readme.html.
A07 — Fallos de Identificación y Autenticación (xmlrpc.php Expuesto)
Auditoría de seguridad WordPress – xmlrpc.php accesible mostrando XML-RPC server accepts POST requests only vector de ataque
La verificación de accesibilidad al archivo xmlrpc.php confirmó que el endpoint
está activo y responde con el mensaje “XML-RPC server accepts POST requests only”.
Este archivo, incluido en WordPress para permitir la publicación remota desde aplicaciones
móviles y clientes de terceros, es un vector de ataque conocido por tres razones principales:
Resultado: vector de ataque activo — riesgo medio.
Recomendación: si no se utilizan aplicaciones móviles ni integración con
herramientas externas que requieran XML-RPC, deshabilitar completamente el endpoint
mediante la siguiente regla en .htaccess:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>Auditoría de seguridad WordPress – curl .git/config devolviendo HTTP 403 confirmando protección de repositorio de código fuente
Esta vulnerabilidad ocurre cuando la infraestructura expone accidentalmente el directorio
.git al internet público, lo que permite a cualquier persona descargar el
historial completo del código fuente del sitio, incluyendo configuraciones sensibles,
credenciales hardcodeadas y la lógica de negocio interna. La prueba consistió en solicitar
el archivo /.git/config mediante curl -I -s.
El servidor respondió con HTTP/1.1 403 Forbidden, lo que confirma que la infraestructura protege proactivamente los directorios sensibles y que el sitio no es vulnerable a la exposición de repositorios de código. Resultado: sin vulnerabilidad.
A09 — Fallos de Registro y Monitoreo (WAF Activo Verificado)
Esta categoría evalúa si el sistema detecta y responde activamente ante ataques en curso. El análisis se apoya directamente en los resultados del punto A03: cuando sqlmap intentó escanear el sitio, el servidor respondió con un HTTP 403 automático desde el primer intento, bloqueando completamente la herramienta antes de que pudiera completar su reconocimiento inicial.
Este comportamiento es evidencia directa de que el Web Application Firewall (WAF) está activo, monitorea los patrones de tráfico HTTP en tiempo real y responde automáticamente ante herramientas de reconocimiento conocidas. La misma respuesta de bloqueo fue observada durante el escaneo de WPScan. Resultado: aprueba satisfactoriamente.
A10 — SSRF (Server-Side Request Forgery): El Ataque Que el Servidor Rechazó
Auditoría de seguridad WordPress – resultado SSRF pingback con faultCode 0 XML-RPC módulo pingback sanitizado sin vulnerabilidad
Aprovechando que xmlrpc.php está accesible (hallazgo del punto A07), se
diseñó una prueba de Server-Side Request Forgery mediante un payload XML de tipo
pingback. La idea es forzar al servidor WordPress a realizar una solicitud HTTP
saliente hacia un dominio externo controlado por el atacante. En una inyección SSRF exitosa,
el servidor contactaría http://www.google.com y el atacante recibiría esa
respuesta, lo que le permitiría explorar la red interna del servidor o exfiltrar metadatos
de la instancia cloud.
El servidor respondió con una estructura XML de error completamente vacía:
<faultCode>0</faultCode> y
<faultString></faultString>. A diferencia de una inyección SSRF
exitosa (que devuelve un código de estado numérico mayor que cero), el faultCode 0
indica que el módulo pingback está internamente sanitizado o deshabilitado para peticiones
salientes. Resultado: sin vulnerabilidad por este vector.
Lo Que Esta Auditoría de Seguridad WordPress Reveló
Tras aplicar las tres fases metodológicas completas de la auditoría de seguridad WordPress, el balance es el siguiente: la infraestructura perimetral del sitio es sólida y bien configurada, con un WAF activo, CDN de Hostinger, delegación DNS en Cloudflare y criptografía TLS 1.3 de grado bancario. Sin embargo, la capa de aplicación presenta vulnerabilidades concretas y corregibles que deben abordarse antes de exponer el sitio a tráfico real de clientes.
| Severidad | Categoría OWASP | Hallazgo | Acción requerida |
|---|---|---|---|
| Alta | A04 — Insecure Design | Sin límite de intentos de login (fuerza bruta) | Instalar Limit Login Attempts + 2FA |
| Media | A01 — Broken Access Control | wp-config.php accesible (HTTP 200) | Regla 403 en .htaccess |
| Media | A05 — Security Misconfiguration | Ausencia de X-Frame-Options, HSTS, X-Content-Type | Configurar Security Headers en servidor |
| Media | A07 — Auth Failures | xmlrpc.php accesible (amplificación de fuerza bruta) | Deshabilitar xmlrpc.php si no es necesario |
| Baja | A05 — Security Misconfiguration | Versión PHP 8.3.30 expuesta en cabecera | expose_php = Off en php.ini |
| Baja | A05 — Security Misconfiguration | BREACH Attack — Content-Encoding: deflate | Tokens CSRF únicos por solicitud |
| Correcto | A02, A03, A08, A09, A10 | TLS 1.3, WAF activo, sin SQLi, sin SSRF, .git protegido | Mantener y auditar periódicamente |
Para más información sobre cómo implementar medidas de hardening en WordPress, puedes consultar nuestra guía completa de hardening para WordPress, nuestro artículo sobre cómo configurar cabeceras de seguridad en WordPress, y la sección de plugins de seguridad recomendados para WordPress. Si deseas entender mejor el contexto de las amenazas modernas, también te recomendamos revisar nuestro artículo sobre cómo prevenir ataques de fuerza bruta en WordPress y nuestra guía de aplicación del OWASP Top 10 en entornos WordPress.
Vídeo explicativo Punto a Punto del Laboratorio de Pentesting
Conclusiones: Lo Que Esta Auditoría Nos Enseña sobre la Seguridad en WordPress
La conclusión más importante de esta auditoría de seguridad WordPress no es técnica: es metodológica. La diferencia entre un sitio comprometido y uno protegido rara vez está en si se usó un CDN o un certificado TLS de última generación. Está en si alguien se tomó el tiempo de mirar el sitio con los ojos de un atacante, documentar lo que encontró y corregirlo sistemáticamente. Los hallazgos de esta auditoría son representativos de la mayoría de instalaciones WordPress en producción en Colombia y Latinoamérica: una infraestructura perimetral razonablemente sólida, combinada con vulnerabilidades de capa de aplicación que son triviales de explotar pero igualmente triviales de corregir.
La realización de auditorías de seguridad periódicas —al menos una por trimestre o tras cada actualización mayor de WordPress, plugins o temas— es la práctica más efectiva para mantenerse por delante de las amenazas. Las herramientas utilizadas en esta auditoría (Nmap, Nikto, WPScan, sqlmap, openssl, nslookup, curl) son todas de código abierto y gratuitas. Lo que se requiere es el conocimiento para interpretarlas y la disciplina para actuar sobre sus hallazgos.
Créditos
Autores: Luis Alberto Diuche Peña – David Eduardo Martínez Moya – Elizabeth Pérez González – Sergio Numael Linares
Editor / Docente evaluador: MG. Ingeniero Carlos Iván Pinzón Romero
Código del curso: UCHEG1-8
Universidad: Universidad Central
Congreso de Colombia. (2009). Ley 1273 de 2009 — De la protección de la información y de los datos. Diario Oficial No. 47.223. https://www.funcionpublica.gov.co/eva/gestornormativo/norma.php?i=34492
Lyon, G. F. (2009). Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning. Insecure.com LLC. https://nmap.org/book/
NIST. (2008). Technical Guide to Information Security Testing and Assessment — SP 800-115. National Institute of Standards and Technology. https://csrc.nist.gov/publications/detail/sp/800-115/final
OWASP Foundation. (2021). OWASP Top Ten 2021. Open Web Application Security Project. https://owasp.org/www-project-top-ten/
PTES Technical Guidelines. (2014). Penetration Testing Execution Standard. http://www.pentest-standard.org/index.php/Main_Page
