{"id":86330,"date":"2026-05-07T14:31:03","date_gmt":"2026-05-07T19:31:03","guid":{"rendered":"https:\/\/niixer.com\/?p=86330"},"modified":"2026-05-07T14:31:06","modified_gmt":"2026-05-07T19:31:06","slug":"auditoria-de-seguridad-wordpress-pentesting-y-vulnerabilidades","status":"publish","type":"post","link":"https:\/\/niixer.com\/index.php\/2026\/05\/07\/auditoria-de-seguridad-wordpress-pentesting-y-vulnerabilidades\/","title":{"rendered":"Auditor\u00eda de seguridad WordPress: pentesting y vulnerabilidades"},"content":{"rendered":"\n

<\/p>\n\n\n\n

Una auditor\u00eda de seguridad WordPress<\/strong> es el primer paso para identificar vulnerabilidades antes de que un atacante pueda explotarlas. Cuando dise\u00f1amos y lanzamos una tienda virtual en WordPress, lo \u00faltimo en lo que pensamos es en c\u00f3mo podr\u00eda ser vulnerada.<\/p>\n\n\n\n

Sin embargo, precisamente esa omisi\u00f3n es el punto de partida de la mayor\u00eda de los incidentes de seguridad que afectan a sitios web en Colombia y el resto de Latinoam\u00e9rica cada a\u00f1o. Con el objetivo de cerrar esa brecha y documentar hallazgos concretos, realizamos una auditor\u00eda completa sobre una tienda virtual propia, desplegada en Hostinger con WooCommerce, aplicando metodolog\u00edas como OWASP Top 10, an\u00e1lisis DNS\/WHOIS\/SSL y reconocimiento OSINT.<\/p>\n\n\n\n

Este art\u00edculo documenta paso a paso lo que encontramos: desde la infraestructura de red hasta vulnerabilidades reales que podr\u00edan comprometer datos de clientes, permitir ataques de fuerza bruta o exponer el c\u00f3digo fuente del sitio.<\/p>\n\n\n\n

Por Qu\u00e9 Necesitas un Contrato Antes de Hackear tu Propio Sitio<\/h2>\n\n\n\n

El t\u00e9rmino “hacking \u00e9tico” no es un eufemismo; es una categor\u00eda jur\u00eddica con implicaciones\nlegales muy concretas. En Colombia, la Ley 1273 de 2009<\/a> tipifica como delito\nel acceso no autorizado a sistemas inform\u00e1ticos, la intercepci\u00f3n de datos, el da\u00f1o\ninform\u00e1tico y el uso de software malicioso, con penas que van desde 48 meses hasta\n8 a\u00f1os de prisi\u00f3n. La \u00fanica diferencia entre un pentester legal y un ciberataque ilegal es,\nen palabras simples, un papel firmado: el contrato de autorizaci\u00f3n.<\/p>\n\n\n\n

Marcos de referencia como el PTES (Penetration Testing Execution Standard)<\/strong>,\nel NIST SP 800-115<\/a> y la OWASP Testing Guide<\/a> son un\u00e1nimes al respecto: antes de ejecutar cualquier<\/p>\n\n\n\n

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\u00e1cticas del sector, sino que puede anular la validez legal de cualquier hallazgo y exponer al auditor a responsabilidades civiles y penales.<\/p>\n\n\n\n

Para esta auditor\u00eda, todas las pruebas se ejecutaron sobre un sitio web creado y administrado\n\u00edntegramente por el equipo auditor, bajo un contrato de autorizaci\u00f3n firmado antes de iniciar\ncualquier actividad t\u00e9cnica. Ning\u00fan sistema de terceros fue vulnerado, ning\u00fan dato fue\nmodificado ni eliminado, y todos los hallazgos se documentaron con el \u00fanico prop\u00f3sito de\naprender a identificarlos y corregirlos.<\/p>\n\n\n\n

C\u00f3mo realizar una auditor\u00eda de seguridad WordPress paso a paso<\/h2>\n\n\n\n

El entorno auditado fue configurado como una tienda virtual funcional que replica fielmente\nel stack tecnol\u00f3gico que encontrar\u00eda cualquier auditor al evaluar un e-commerce colombiano\nde mediana escala.<\/p>\n\n\n\n

Esta combinaci\u00f3n es la misma que encontrar\u00eda cualquier analista al revisar miles de sitios\nactivos en la regi\u00f3n: un CMS popular, hosting compartido de bajo costo, CDN configurado\nautom\u00e1ticamente y un conjunto de plugins instalados sin revisi\u00f3n sistem\u00e1tica de seguridad.\nLo que aqu\u00ed documentamos aplica, con m\u00ednimas variaciones, a la gran mayor\u00eda de\ninstalaciones WordPress en producci\u00f3n hoy.<\/p>\n\n\n\n

Fase 1 \u2014 Reconocimiento de Red en una auditor\u00eda de seguridad WordPress<\/h3>\n\n\n\n

El reconocimiento es la primera y m\u00e1s determinante fase de cualquier proceso de\nauditor\u00eda de seguridad WordPress<\/strong> o de cualquier sistema web. Su objetivo\nno es vulnerar nada: es comprender. Un auditor que no conoce la topolog\u00eda de red de su\nobjetivo, los servicios que expone y los posibles vectores de entrada est\u00e1 actuando a ciegas,\nlo que reduce dram\u00e1ticamente la efectividad de las pruebas posteriores. Existen dos\nmodalidades complementarias:<\/p>\n\n\n\n

1.1 Prueba de Conectividad con Ping: La Primera Huella Digital del Servidor<\/h4>\n\n\n\n

El comando ping<\/code> utiliza el protocolo ICMP (Internet Control Message Protocol,\nRFC 792, capa 3 del modelo OSI) para enviar mensajes Echo Request<\/em> (tipo 8) y\nrecibir Echo Reply<\/em> (tipo 0) del servidor destino. En un contexto de pentesting,\nel ping cumple tres funciones simult\u00e1neas: confirma si el host est\u00e1 activo, mide la latencia\nde ida y vuelta (RTT) en milisegundos, y \u2014crucialmente\u2014 revela la direcci\u00f3n IP que\nresuelve el dominio, que puede ser la del CDN y no la del servidor f\u00edsico real.<\/p>\n\n\n\n

Se ejecutaron tres pings sucesivos en momentos distintos sobre el dominio objetivo\npalevioletred-wildcat-394676.hostingersite.com<\/code>. Cada ejecuci\u00f3n resolvi\u00f3 a\nuna IP diferente, confirmando el balanceo de carga activo en la infraestructura.<\/p>\n\n\n\n

Primer Ping<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

En el primer ping<\/strong>, el dominio resolvi\u00f3 a 191.101.104.36<\/code>\n(alias free.cdn.hstgr.net<\/code>), con tiempos de respuesta entre 84 ms y 210 ms.\nEl pico at\u00edpico en el tercer paquete (210 ms) es completamente normal en redes CDN,\ndonde la ruta puede variar ligeramente entre paquetes dependiendo del nodo que sirva\nla respuesta.<\/p>\n\n\n\n

Auditor\u00eda de seguridad WordPress – segundo y tercer ping evidenciando rotaci\u00f3n de IP por CDN Hostinger<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

El segundo ping<\/strong> resolvi\u00f3 a 212.1.212.250<\/code> con tiempos\nsimilares pero un pico en el quinto paquete (269 ms), y el tercer ping<\/strong>\nentreg\u00f3 una tercera IP diferente: 195.35.60.114<\/code>. Este comportamiento de\nrotaci\u00f3n de IPs entre ejecuciones es la confirmaci\u00f3n m\u00e1s directa de que el sitio opera\ndetr\u00e1s de un sistema de balanceo de carga activo. Desde la perspectiva de seguridad,\nesto significa que no existe un \u00fanico nodo que “derribar” para afectar la disponibilidad\ndel sitio, lo que representa una ventaja defensiva importante frente a ataques DDoS.<\/p>\n\n\n\n

La verificaci\u00f3n adicional con curl ipinfo.io\/[IP]<\/code> confirm\u00f3 que todas las\nIPs pertenecen a AS47583 Hostinger International Limited<\/strong>, datacenter\nde Asheville, North Carolina. Aunque el sitio es administrado desde Colombia, sus\nservidores f\u00edsicos residen en territorio estadounidense, con implicaciones tanto de\nrendimiento (latencia transatl\u00e1ntica promedio ~85 ms desde Bogot\u00e1) como de jurisdicci\u00f3n\nlegal en caso de incidentes de seguridad.<\/p>\n\n\n\n

1.2 Traceroute: El Mapa de Red que la Infraestructura No Quiere que Veas<\/h4>\n\n\n\n

La herramienta traceroute<\/code> (Linux) o tracert<\/code> (Windows) mapea\nla ruta de los paquetes IP desde el equipo del auditor hasta el servidor destino, enviando\npaquetes con valores TTL (Time To Live) crecientes. Cuando el TTL expira en un router\nintermedio, ese dispositivo descarta el paquete y responde con un mensaje ICMP\nTime Exceeded<\/em>, revelando su direcci\u00f3n IP y la latencia hasta ese punto. Salto a\nsalto, se construye el mapa completo de la red entre origen y destino.<\/p>\n\n\n\n

Auditor\u00eda de seguridad WordPress – traceroute con todos los saltos ocultos mostrando infraestructura CDN protegida<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

El resultado fue contundente: a partir del segundo salto, todos los routers intermedios\nrespondieron con * * *<\/code>, lo que indica que est\u00e1n configurados para ignorar\nlas sondas ICMP\/UDP usadas por traceroute. El \u00fanico salto visible fue el primero,\ncorrespondiente al gateway de la m\u00e1quina virtual (10.0.2.2<\/code>). Esta respuesta\nno es un error; es exactamente el comportamiento esperado y deseado en infraestructuras\nCDN corporativas modernas: impide que un atacante externo conozca la topolog\u00eda interna\nde la red, el n\u00famero de dispositivos intermedios o la ubicaci\u00f3n f\u00edsica de los servidores.<\/p>\n\n\n\n

Como alternativa, se intent\u00f3 el traceroute con el flag -T -p 80<\/code> (TCP sobre\npuerto HTTP), que en ocasiones logra traversar firewalls que bloquean UDP. Este m\u00e9todo\nrevel\u00f3 dos saltos: el gateway local y un nodo con IP p\u00fablica 191.101.104.121<\/code>\nperteneciente al CDN de Hostinger. Sin embargo, la ruta completa hasta el servidor de\norigen permaneci\u00f3 opaca, confirmando que la arquitectura de red del objetivo cuenta con\nuna protecci\u00f3n perimetral robusta y bien configurada.<\/p>\n\n\n\n

1.3 Escaneo de Puertos con Nmap: El Rayos X de la Infraestructura<\/h4>\n\n\n\n

Nmap<\/a>\n(Network Mapper) es la herramienta de referencia mundial para el descubrimiento de\nhosts y servicios en red. Permite identificar puertos abiertos, detectar versiones exactas\nde software mediante service fingerprinting, inferir el sistema operativo del servidor y\nejecutar scripts de detecci\u00f3n de vulnerabilidades a trav\u00e9s del motor NSE (Nmap Scripting\nEngine). Para esta auditor\u00eda de seguridad WordPress<\/strong> se ejecutaron tres\nvariantes con profundidad creciente.<\/p>\n\n\n\n

Escaneo R\u00e1pido \u2014 nmap -F<\/code><\/h4>\n\n\n\n

Auditor\u00eda de seguridad WordPress – nmap -F mostrando solo puertos 80 y 443 abiertos con 98 filtrados<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

El escaneo r\u00e1pido con el flag -F<\/code> analiza los 100 puertos TCP m\u00e1s comunes.\nEl resultado fue claro y positivo desde el punto de vista defensivo: 98 puertos\nest\u00e1n filtrados<\/strong> (bloqueados por firewall, sin respuesta) y \u00fanicamente dos est\u00e1n\nabiertos: el puerto 80\/tcp (HTTP)<\/strong> y el puerto 443\/tcp\n(HTTPS)<\/strong>. Esto significa que la superficie de ataque expuesta est\u00e1 reducida al\nm\u00ednimo estrictamente necesario para operar un sitio web. No hay puertos de gesti\u00f3n\nremota abiertos, como el 22 (SSH), 3306 (MySQL), 3389 (RDP) o 8080 (HTTP alternativo),\nlo que representa una buena pr\u00e1ctica de seguridad: el acceso administrativo al servidor\nse realiza por canales seguros y no expuestos al internet p\u00fablico.<\/p>\n\n\n\n

Detecci\u00f3n de Versiones \u2014 nmap -sV<\/code><\/h4>\n\n\n\n

Auditor\u00eda de seguridad WordPress – nmap -sV revelando servidor nginx y CDN hcdn de Hostinger con service fingerprin<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

El escaneo de versiones con el flag -sV<\/code> aplica t\u00e9cnicas de service\nfingerprinting para determinar exactamente qu\u00e9 software corre detr\u00e1s de cada puerto abierto.\nEl resultado identifica el servicio en ambos puertos como hcdn<\/strong> (el CDN\npropietario de Hostinger), y dentro del bloque Service Fingerprint<\/em> se puede leer\nclaramente la cadena <center>nginx<\/center><\/code>, confirmando que el\nservidor web subyacente es nginx<\/strong>. Las versiones HTTP soportadas son\nHTTP\/1.0, HTTP\/1.1 y HTTP\/3.<\/p>\n\n\n\n

Este hallazgo tiene implicaciones de seguridad directas. Exponer el nombre del software\ndel servidor en las cabeceras HTTP (Server: hcdn<\/code>) y en las p\u00e1ginas de error\ninternas le entrega a cualquier atacante un vector de investigaci\u00f3n: basta con buscar en\nbases de datos de vulnerabilidades como el\nNVD del NIST<\/a>\nlos CVE asociados a la versi\u00f3n de nginx detectada para identificar exploits aplicables.\nLa recomendaci\u00f3n inmediata es ocultar la cabecera Server<\/code> mediante la directiva\nserver_tokens off;<\/code> en la configuraci\u00f3n de nginx.<\/p>\n\n\n\n

Escaneo Agresivo \u2014 nmap -A<\/code><\/h4>\n\n\n\n

Auditor\u00eda de seguridad WordPress – nmap -A con scripts NSE revelando robots.txt redireccionamiento HTTP a HTTPS y m\u00faltiples IPs<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

El escaneo agresivo con el flag -A<\/code> activa simult\u00e1neamente la detecci\u00f3n de\nversiones, el traceroute integrado y la ejecuci\u00f3n de scripts NSE. Los hallazgos m\u00e1s\nrelevantes fueron tres: primero, la redirecci\u00f3n autom\u00e1tica de HTTP a HTTPS<\/strong>\nmediante un c\u00f3digo 302 Moved<\/code>, que confirma que ning\u00fan contenido se sirve\nen texto plano. Segundo, la detecci\u00f3n de que el archivo robots.txt<\/code> contiene\nal menos una entrada disallowed<\/em>; parad\u00f3jicamente, este archivo act\u00faa como un\nmapa de directorios sensibles para cualquier auditor, ya que si algo aparece all\u00ed es porque\nel administrador considera que no debe indexarse. Tercero, la confirmaci\u00f3n de m\u00faltiples\ndirecciones IPv4 e IPv6 asociadas al dominio, que refuerza el modelo de balanceo de carga\nidentificado previamente.<\/p>\n\n\n\n

Fase 2 \u2014 DNS, WHOIS y SSL en una auditor\u00eda de seguridad WordPress<\/h3>\n\n\n\n

Una de las fases m\u00e1s subestimadas de una auditor\u00eda de seguridad WordPress<\/strong>\nes el an\u00e1lisis de la informaci\u00f3n p\u00fablica disponible sobre el dominio. Los registros DNS,\nlas bases de datos WHOIS y los certificados SSL son fuentes abiertas que cualquier persona\npuede consultar sin generar un solo paquete de tr\u00e1fico hacia el servidor objetivo. La\ncantidad de informaci\u00f3n estrat\u00e9gica que revelan sobre la infraestructura, las herramientas\nutilizadas y los posibles vectores de ingenier\u00eda social es, en muchos casos, sorprendente.<\/p>\n\n\n\n

2.1 Registros DNS con nslookup: Tres Capas de Informaci\u00f3n Cr\u00edtica<\/p>\n\n\n\n

Registro A \u2014 La IP que Est\u00e1 Detr\u00e1s del Dominio<\/h4>\n\n\n\n

Auditor\u00eda de seguridad WordPress – nslookup registro tipo A mostrando alias free.cdn.hstgr.net con IPs del CDN Hostinger<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

La consulta nslookup -type=A [dominio]<\/code> devolvi\u00f3 una respuesta no autoritativa\nque revel\u00f3 el hallazgo m\u00e1s importante de esta fase: el dominio auditado no apunta\ndirectamente al servidor de origen<\/strong>. En cambio, es un alias (CNAME) que redirige\nel tr\u00e1fico hacia free.cdn.hstgr.net<\/code>, devolviendo simult\u00e1neamente dos\ndirecciones IP: 191.101.104.113<\/code> y 191.96.144.240<\/code>. Esto confirma\nque el sitio opera detr\u00e1s de la CDN de Hostinger, lo que oculta la IP real del servidor\nf\u00edsico y distribuye la carga entre m\u00faltiples nodos.<\/p>\n\n\n\n

Desde la perspectiva del pentester, este hallazgo es fundamental: cualquier escaneo\no ataque dirigido a estas IPs impactar\u00e1 sobre los nodos del CDN, no sobre el servidor de\norigen real. Esta arquitectura es una de las defensas m\u00e1s efectivas contra ataques DDoS\ndirectos y dificulta significativamente el rastreo de la infraestructura f\u00edsica subyacente.<\/p>\n\n\n\n

Registro MX \u2014 Qu\u00e9 Dice (y Qu\u00e9 Oculta) Sobre el Correo Corporativo<\/h4>\n\n\n\n

Auditor\u00eda de seguridad WordPress – nslookup registro MX mostrando SOA de Cloudflare sin servidores de correo expuestos<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

La consulta del Registro MX (nslookup -type=MX hostingersite.com<\/code>) no devolvi\u00f3\nservidores de correo convencionales como Outlook o Google Workspace. En su lugar, la consola\narroj\u00f3 los datos del registro de Autoridad Principal (SOA), revelando que la gesti\u00f3n completa\nde DNS est\u00e1 delegada a la plataforma Cloudflare mediante los name servers\nemily.ns.cloudflare.com<\/code> y dns.cloudflare.com<\/code>.<\/p>\n\n\n\n

Este resultado tiene dos lecturas desde la perspectiva de seguridad. Por un lado, la ausencia\nde servidores de correo expuestos es positiva: impide que un atacante determine qu\u00e9\nherramientas ofim\u00e1ticas usan internamente los empleados (dato valioso para ataques de\ningenier\u00eda social dirigida). Por otro lado, la delegaci\u00f3n total a Cloudflare confirma que\ntoda la seguridad DNS depende de la solidez de esa plataforma, lo que hace cr\u00edtico\nmantener las credenciales de esa cuenta extremadamente protegidas.<\/p>\n\n\n\n

Registro TXT \u2014 La Pol\u00edtica de Correo que Elimina el Email Spoofing<\/h4>\n\n\n\n

Auditor\u00eda de seguridad WordPress – nslookup registro TXT mostrando pol\u00edtica SPF v=spf1 -all configuraci\u00f3n estricta<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

La consulta del Registro TXT (nslookup -type=TXT hostingersite.com<\/code>) revel\u00f3\nla cadena v=spf1 -all<\/code>. Este es el est\u00e1ndar SPF (Sender Policy Framework),\nun protocolo de autenticaci\u00f3n de correo electr\u00f3nico que define qu\u00e9 servidores est\u00e1n\nautorizados a enviar correos a nombre de un dominio. El par\u00e1metro -all<\/code>,\nconocido como Hard Fail<\/em>, indica que ninguna direcci\u00f3n IP est\u00e1 autorizada<\/strong>\na enviar correos usando @hostingersite.com<\/code>. Cualquier mensaje que intente\nhacerse pasar por ese dominio ser\u00e1 rechazado directamente por los servidores de destino.\nEsta configuraci\u00f3n elimina pr\u00e1cticamente por completo el riesgo de email spoofing contra\neste dominio, lo que representa una excelente pr\u00e1ctica de higiene criptogr\u00e1fica.<\/p>\n\n\n\n

2.2 WHOIS: Qu\u00e9 Sabe el Mundo sobre el Propietario de tu Dominio<\/p>\n\n\n\n

Auditor\u00eda de seguridad WordPress – resultado WHOIS mostrando Hostinger operations UAB clientTransferProhibited y nameservers Cloudflare<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

La b\u00fasqueda WHOIS sobre hostingersite.com<\/code> mediante la herramienta Sysinternals\nWhois v1.21 revel\u00f3 la siguiente informaci\u00f3n de inter\u00e9s para la auditor\u00eda:<\/p>\n\n\n\n

El dato m\u00e1s relevante desde la perspectiva defensiva es el estado\nclientTransferProhibited<\/code>. Este mecanismo de seguridad bloquea el dominio\na nivel de registro, impidiendo que sea transferido a otro registrar sin autorizaci\u00f3n\nexpl\u00edcita del propietario. Esto previene el Domain Hijacking<\/em>, una t\u00e9cnica de\nataque en la que un actor malicioso intenta tomar el control del dominio mediante\ningenier\u00eda social dirigida al registrar o mediante el aprovechamiento de credenciales\ncomprometidas. Al tener este bloqueo activo, incluso si un atacante obtiene las credenciales\nde la cuenta de Hostinger, no podr\u00eda transferir el dominio sin un proceso de validaci\u00f3n\nadicional.<\/p>\n\n\n\n

Por otro lado, el registro WHOIS no expone ning\u00fan dato personal del propietario real del\nsitio web (nombre, tel\u00e9fono, correo), lo que cumple con los est\u00e1ndares actuales de\nprivacidad en internet y dificulta las tareas de reconocimiento para ataques de ingenier\u00eda\nsocial. El \u00fanico punto de mejora identificado es la ausencia de DNSSEC activo\n(unsigned<\/code>), una capa adicional de autenticaci\u00f3n DNS que protege contra\nataques de envenenamiento de cach\u00e9.<\/p>\n\n\n\n

2.3 Certificado SSL\/TLS: Una Criptograf\u00eda de Grado Bancario<\/p>\n\n\n\n

Auditor\u00eda de seguridad WordPress – an\u00e1lisis openssl s_client mostrando TLS 1.3 certificado DigiCert RapidSSL cadena de confianza v\u00e1lida<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

El an\u00e1lisis del certificado SSL con el comando\nopenssl s_client -showcerts -connect [dominio]:443<\/code> arroj\u00f3 los resultados m\u00e1s\npositivos de toda la auditor\u00eda desde el punto de vista criptogr\u00e1fico. El handshake TLS fue\nexitoso y revel\u00f3 la siguiente cadena de confianza:<\/p>\n\n\n\n

DigiCert Inc es una de las Autoridades Certificadoras comerciales de mayor reconocimiento\na nivel mundial, lo que garantiza que todos los navegadores modernos conf\u00eden en el\ncertificado sin mostrar advertencias de seguridad. La negociaci\u00f3n bajo TLS 1.3 con el\ncifrador TLS_AES_256_GCM_SHA384<\/code> significa que toda la comunicaci\u00f3n entre\nel navegador del cliente y el servidor est\u00e1 protegida con cifrado de 256 bits, el mismo\nest\u00e1ndar que utilizan las instituciones financieras y los organismos gubernamentales para\nproteger transacciones sensibles.<\/p>\n\n\n\n

El certificado de tipo Wildcard (*.hostingersite.com<\/code>) es pr\u00e1ctico desde el\npunto de vista operativo, ya que cubre autom\u00e1ticamente cualquier subdominio sin necesidad\nde emitir certificados individuales. Sin embargo, conviene monitorear peri\u00f3dicamente los\nregistros de Transparencia de Certificados (CT Logs) de este dominio, ya que cualquier\ncertificado emitido para un subdominio de hostingersite.com<\/code> aparecer\u00e1 en esos\nregistros p\u00fablicos y podr\u00eda revelar subdominios internos no intencionados.<\/p>\n\n\n\n

Tambi\u00e9n se identific\u00f3, mediante el comando nslookup -type=NS hostingersite.com<\/code>,\nque los name servers autoritativos son emily.ns.cloudflare.com<\/code> y\nterin.ns.cloudflare.com<\/code>, con soporte completo para IPv4 e IPv6, lo que confirma\nla infraestructura dual-stack y la delegaci\u00f3n total de la autoridad DNS a Cloudflare.<\/p>\n\n\n\n

Video Recomendado: Introducci\u00f3n al Pentesting Web con OWASP<\/p>\n\n\n\n

Para complementar los conceptos t\u00e9cnicos de esta auditor\u00eda, te recomendamos el siguiente\nrecurso audiovisual oficial del proyecto OWASP, que explica de forma visual las categor\u00edas\ndel Top 10 y c\u00f3mo afectan a aplicaciones web reales como WordPress:<\/p>\n\n\n\n

Video:<\/strong>\n\nOWASP Top 10 2021 \u2014 Explicaci\u00f3n Completa para Desarrolladores Web<\/a>\n(YouTube, OWASP Foundation)<\/p>\n\n\n\n

Fase 3 \u2014 OWASP Top 10 en una auditor\u00eda de seguridad WordPress<\/h2>\n\n\n\n

El OWASP Top 10<\/a> es el est\u00e1ndar de referencia m\u00e1s utilizado en el mundo para evaluar la\nseguridad de aplicaciones web. Publicado y mantenido por la Open Web Application Security\nProject Foundation, clasifica las diez categor\u00edas de riesgo m\u00e1s cr\u00edticas bas\u00e1ndose en datos\nreales de miles de organizaciones a nivel global. A continuaci\u00f3n documentamos los hallazgos\npara cada categor\u00eda aplicada durante esta auditor\u00eda de seguridad WordPress<\/strong>.<\/p>\n\n\n\n

A01 \u2014 Control de Acceso Roto (Broken Access Control)<\/h3>\n\n\n\n

Esta categor\u00eda eval\u00faa si un usuario puede acceder a p\u00e1ginas, archivos o funciones a las que\nno deber\u00eda tener acceso. Las pruebas se realizaron sobre tres rutas cr\u00edticas de WordPress:<\/p>\n\n\n\n

Auditor\u00eda de seguridad WordPress – curl wp-admin mostrando HTTP 301 sin exposici\u00f3n de contenido con content-security-policy activo<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

\/wp-admin (Panel de Administraci\u00f3n):<\/strong> el acceso al panel de administraci\u00f3n\nmediante curl -I https:\/\/[dominio]\/wp-admin<\/code> devolvi\u00f3 un c\u00f3digo\nHTTP\/2 301<\/code> que redirige correctamente hacia \/wp-admin\/<\/code> sin exponer\nning\u00fan contenido sin autenticaci\u00f3n. Adicionalmente, la cabecera\ncontent-security-policy: upgrade-insecure-requests<\/code> confirma que hay una pol\u00edtica\nde seguridad de contenido activa. Resultado: sin vulnerabilidad en este vector.<\/em><\/p>\n\n\n\n

Auditor\u00eda de seguridad WordPress – curl wp-config.php devolviendo HTTP 200 exponiendo PHP 8.3.30 vulnerabilidad cr\u00edtica<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

\/wp-config.php (Archivo de Configuraci\u00f3n):<\/strong> aqu\u00ed se identific\u00f3 la primera\nvulnerabilidad concreta de la auditor\u00eda. El acceso a \/wp-config.php<\/code> devolvi\u00f3\nun HTTP\/2 200<\/strong>, lo que significa que el archivo es accesible p\u00fablicamente\ny que la cabecera x-powered-by: PHP\/8.3.30<\/code> queda expuesta a cualquier\nvisitante. Si bien el contenido del archivo en s\u00ed no se sirve directamente gracias a la\nconfiguraci\u00f3n de PHP, la respuesta 200 confirma su existencia e indica la versi\u00f3n exacta\ndel int\u00e9rprete, informaci\u00f3n que puede usarse para buscar CVE espec\u00edficos de esa versi\u00f3n.\nResultado: vulnerabilidad media \u2014 exposici\u00f3n de informaci\u00f3n t\u00e9cnica.<\/em><\/p>\n\n\n\n

Recomendaci\u00f3n:<\/strong> a\u00f1adir la siguiente regla en el archivo\n.htaccess<\/code> de la ra\u00edz del sitio para devolver un error 403 y ocultar la\ncabecera x-powered-by<\/code>:<\/p>\n\n\n\n

<Files wp-config.php>\n  order allow,deny\n  deny from all\n<\/Files><\/code><\/pre>\n\n\n\n
Auditor\u00eda de seguridad WordPress – curl wp-content devolviendo HTTP 301 sin vulnerabilidad de broken access control<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\/wp-content (Directorio de Contenido):<\/strong> la respuesta fue\nHTTP\/2 301<\/code> con redirecci\u00f3n correcta y content-security-policy<\/code>\nactivo, sin exposici\u00f3n de contenido sin autenticaci\u00f3n. Resultado: sin vulnerabilidad.<\/em><\/p>\n\n\n\n
A02 \u2014 Fallos Criptogr\u00e1ficos (Cryptographic Failures SSL\/TLS)<\/h3>\n\n\n\n
Auditor\u00eda de seguridad WordPress – nmap ssl-enum-ciphers mostrando TLS 1.2 y TLS 1.3 con todos los cifradores calificados grado A<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
El escaneo con el script NSE de Nmap --script ssl-enum-ciphers -p 443<\/code> enumer\u00f3\ntodas las suites criptogr\u00e1ficas disponibles en el servidor. El an\u00e1lisis confirm\u00f3 que solo\nest\u00e1n habilitados cifradores calificados como grado A<\/strong> tanto en TLS 1.2\ncomo en TLS 1.3:<\/p>\n\n\n\n
No se detectaron cifradores obsoletos como RC4, DES, 3DES o EXPORT, lo que significa\nque el sitio no es vulnerable a ataques de downgrade criptogr\u00e1fico conocidos como\nPOODLE, BEAST o DROWN. Resultado: sin vulnerabilidad significativa.<\/em><\/p>\n\n\n\n
A03 \u2014 Inyecci\u00f3n SQL (SQL Injection)<\/h3>\n\n\n\n
Auditor\u00eda de seguridad WordPress – formulario de login con payload OR 1=1 mostrando mensaje de error gen\u00e9rico sin exposici\u00f3n de base de datos<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
La inyecci\u00f3n SQL ocurre cuando un atacante inserta c\u00f3digo SQL malicioso en campos de\nformularios web para manipular directamente la base de datos subyacente. La prueba cl\u00e1sica\nOR '1'='1<\/code> fue ejecutada manualmente en el formulario de inicio de sesi\u00f3n.\nEl sistema respondi\u00f3 con un mensaje de error gen\u00e9rico que simplemente indica que el usuario\nno existe, sin revelar informaci\u00f3n sobre el esquema de base de datos, la versi\u00f3n\nde MySQL\/MariaDB ni el contenido de ninguna tabla<\/strong>. Este comportamiento indica el\nuso de consultas parametrizadas o prepared statements en el backend de WordPress.<\/p>\n\n\n\n
Auditor\u00eda de seguridad WordPress – resultado de sqlmap bloqueado con HTTP 403 por WAF activo en el sitio<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Adicionalmente, la herramienta automatizada\nsqlmap<\/a>\nfue ejecutada contra el formulario de PQR del sitio. El servidor respondi\u00f3 con un\nHTTP 403<\/strong> bloqueando el escaneo autom\u00e1tico desde el primer intento, y la\nherramienta report\u00f3 que no encontr\u00f3 formularios en la URL objetivo porque el formulario\nutiliza renderizado JavaScript din\u00e1mico, lo que lo hace invisible para sqlmap sin una\nconfiguraci\u00f3n avanzada con Selenium. Resultado: sin vulnerabilidad confirmada.<\/em><\/p>\n\n\n\n
A04 \u2014 Dise\u00f1o Inseguro (Insecure Design): La Vulnerabilidad que Nadie Ve hasta que Es Tarde<\/h3>\n\n\n\n
Las vulnerabilidades de dise\u00f1o inseguro no son errores de c\u00f3digo: son decisiones\narquitect\u00f3nicas tomadas desde el principio del desarrollo que crean brechas de seguridad\nestructurales. A diferencia de un bug que puede parchearse con una actualizaci\u00f3n, el dise\u00f1o\ninseguro requiere cambios en la l\u00f3gica funcional del sistema.<\/p>\n\n\n\n
Auditor\u00eda de seguridad WordPress – formulario de login con m\u00e1s de 5 intentos fallidos sin bloqueo vulnerabilidad fuerza bruta<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
La prueba ejecutada fue directa: se realizaron m\u00e1s de cinco intentos de inicio de sesi\u00f3n\ncon credenciales incorrectas sobre el panel \/wp-login.php<\/code>, usando nombres de\nusuario y contrase\u00f1as distintas en cada intento. El sistema nunca activ\u00f3 ning\u00fan mecanismo\nde bloqueo temporal, no mostr\u00f3 ning\u00fan CAPTCHA adicional despu\u00e9s del tercer intento,\nno increment\u00f3 el tiempo de espera entre intentos y no bloque\u00f3 la direcci\u00f3n IP de origen.\nEste comportamiento expone el sitio a ataques de fuerza bruta automatizados, en los que\nherramientas como Hydra o Burp Suite Intruder pueden probar miles de combinaciones de\ncontrase\u00f1as por minuto sin interrupci\u00f3n.<\/p>\n\n\n\n
\u26a0 Vulnerabilidad cr\u00edtica \u2014 Riesgo alto.<\/strong> Esta es, sin duda, la\nvulnerabilidad m\u00e1s peligrosa identificada durante toda la auditor\u00eda, porque un atacante\nque obtenga acceso al panel de administraci\u00f3n puede comprometer completamente el sitio,\ninstalar backdoors, robar datos de clientes o redirigir el tr\u00e1fico a sitios maliciosos.<\/p>\n\n\n\n
Recomendaci\u00f3n:<\/strong> instalar el plugin\nLimit Login Attempts Reloaded<\/a> (gratuito,\nm\u00e1s de dos millones de instalaciones activas) y configurarlo para bloquear al usuario y\nla IP tras exactamente tres intentos fallidos, con un per\u00edodo de bloqueo progresivo.\nAdicionalmente, se recomienda implementar autenticaci\u00f3n de dos factores (2FA) mediante\nplugins como WP 2FA o Google Authenticator for WordPress.<\/p>\n\n\n\n
A05 \u2014 Mala Configuraci\u00f3n de Seguridad (Security Misconfiguration)<\/h3>\n\n\n\n
Auditor\u00eda de seguridad WordPress – nikto escaneando el sitio mostrando m\u00faltiples cabeceras de seguridad faltantes PHP expuesto y vulnerabilidades<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
El an\u00e1lisis con nikto v2.5.0<\/code>, la herramienta de escaneo de servidores web\nde referencia en el sector, identific\u00f3 cuatro vulnerabilidades activas relacionadas con\nla configuraci\u00f3n de cabeceras HTTP de seguridad. Esta es la categor\u00eda con m\u00e1s hallazgos\nde toda la auditor\u00eda, y la m\u00e1s representativa de lo que ocurre en la mayor\u00eda de las\ninstalaciones WordPress en producci\u00f3n que no han pasado por una revisi\u00f3n de seguridad\nespecializada:<\/p>\n\n\n\n
1. Vulnerable a Clickjacking:<\/strong> <\/h4>\n\n\n\n
la cabecera X-Frame-Options<\/code> no est\u00e1 presente. Esta cabecera le indica al navegador si una p\u00e1gina puede ser incrustada dentro de un <iframe><\/code> en otro sitio. Sin ella, un atacante podr\u00eda crear una p\u00e1gina maliciosa que incruste el checkout de la tienda dentro de un iframe invisible, solapado sobre un bot\u00f3n de clic inocente. Cuando el cliente hace clic en lo que cree que es un bot\u00f3n leg\u00edtimo, en realidad est\u00e1 interactuando con el formulario de pago del sitio real debajo (t\u00e9cnica conocida como UI Redressing).<\/p>\n\n\n\n
Auditor\u00eda de seguridad WordPress – nikto identificando ausencia de X-Frame-Options y X-Content-Type-Options vulnerabilidades clickjacking MIME sniffing<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
<\/p>\n\n\n\n
2. Vulnerable a MIME Sniffing:<\/strong> <\/h4>\n\n\n\n
la cabecera X-Content-Type-Options: nosniff<\/code> no est\u00e1 configurada. Esto permite que los navegadores m\u00e1s antiguos o en modos espec\u00edficos “adivinen” el tipo MIME de un archivo, lo que puede llevar a que un archivo aparentemente inofensivo (como un .txt<\/code> subido por un usuario) sea interpretado y ejecutado como HTML o JavaScript por el navegador.<\/p>\n\n\n\n
Auditor\u00eda de seguridad WordPress – nikto identificando ausencia HSTS y Content-Encoding deflate vulnerabilidad MIME Sniffing<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
<\/p>\n\n\n\n
3. Vulnerable a MITM (Man-in-the-Middle):<\/strong> <\/h4>\n\n\n\n
la cabecera Strict-Transport-Security (HSTS)<\/code> no est\u00e1 definida. Sin HSTS, el navegador no tiene instrucciones expl\u00edcitas 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\u00e1tico a HTTPS, un atacante posicionado en la misma red (por ejemplo, en una red Wi-Fi p\u00fablica) podr\u00eda interceptar esa primera solicitud y realizar un ataque de degradaci\u00f3n de protocolo.<\/p>\n\n\n\n
Auditor\u00eda de seguridad WordPress – nikto identificando ausencia HSTS y Content-Encoding deflate vulnerabilidades MITM<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
<\/p>\n\n\n\n
4. Vulnerable a BREACH Attack:<\/strong> <\/h4>\n\n\n\n
La cabecera Content-Encoding: deflate<\/code> indica que el servidor comprime las respuestas HTTP con el algoritmo DEFLATE. Cuando la compresi\u00f3n HTTP se combina con HTTPS y el contenido comprimido incluye secretos predecibles (como tokens CSRF), un atacante con capacidad de observar el tr\u00e1fico cifrado puede inferir el valor del secreto mediante el ataque BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext), que explota la correlaci\u00f3n entre la longitud del texto cifrado comprimido y el contenido del secreto.<\/p>\n\n\n\n
Auditor\u00eda de seguridad WordPress – nikto identificando ausencia HSTS y Content-Encoding deflate vulnerabilidade BREACH Attack<\/strong><\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Correcci\u00f3n para todas las vulnerabilidades de cabeceras:<\/strong> a\u00f1adir las\nsiguientes directivas en el archivo .htaccess<\/code> o en la configuraci\u00f3n del\nservidor web:<\/p>\n\n\n\n
Header always set X-Frame-Options \"SAMEORIGIN\"\nHeader always set X-Content-Type-Options \"nosniff\"\nHeader always set Strict-Transport-Security \"max-age=31536000; includeSubDomains; preload\"\nHeader always set Referrer-Policy \"strict-origin-when-cross-origin\"\nHeader always set Permissions-Policy \"geolocation=(), microphone=(), camera=()\"<\/code><\/pre>\n\n\n\n
A06 \u2014 Componentes Vulnerables (Vulnerable and Outdated Components)<\/h3>\n\n\n\n
Auditor\u00eda de seguridad WordPress – WPScan identificando tema flash-pro con versi\u00f3n CSS 6.9.4 y enumeraci\u00f3n de plugins en proceso<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
La herramienta WPScan<\/a>\n(WordPress Security Scanner, v3.8.25) fue ejecutada con el flag --enumerate p<\/code>\npara identificar los plugins activos y sus versiones. El escaneo confirm\u00f3 que el tema activo\nes Flash Pro<\/strong>, detectado mediante la URL del archivo CSS\n(style.css?ver=6.9.4<\/code>), aunque la versi\u00f3n exacta del tema no pudo determinarse\ndefinitivamente por m\u00e9todos pasivos.<\/p>\n\n\n\n
El WAF bloque\u00f3 la enumeraci\u00f3n agresiva de plugins tras 754 solicitudes procesadas, lo que\nimpidi\u00f3 obtener el listado completo de los 19 plugins activos. Este comportamiento del WAF\nes, en s\u00ed mismo, un indicador positivo: el sistema est\u00e1 activamente monitoreando y limitando\nel reconocimiento automatizado. Sin embargo, el hecho de que la versi\u00f3n del core de WordPress\n(6.9.4<\/code>) y del tema sean detectables mediante m\u00e9todos pasivos sigue siendo un\nvector de informaci\u00f3n que debe gestionarse.<\/p>\n\n\n\n
Recomendaci\u00f3n:<\/strong> mantener WordPress core, todos los temas y plugins\nactualizados a la \u00faltima versi\u00f3n estable mediante actualizaciones autom\u00e1ticas. Eliminar\ntemas y plugins inactivos que no se utilicen. Ocultar la versi\u00f3n de WordPress de los\nmetadatos del HTML y del archivo readme.html<\/code>.<\/p>\n\n\n\n
A07 \u2014 Fallos de Identificaci\u00f3n y Autenticaci\u00f3n (xmlrpc.php Expuesto)<\/h3>\n\n\n\n
Auditor\u00eda de seguridad WordPress – xmlrpc.php accesible mostrando XML-RPC server accepts POST requests only vector de ataque<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
La verificaci\u00f3n de accesibilidad al archivo xmlrpc.php<\/code> confirm\u00f3 que el endpoint\nest\u00e1 activo y responde con el mensaje “XML-RPC server accepts POST requests only”<\/em>.\nEste archivo, incluido en WordPress para permitir la publicaci\u00f3n remota desde aplicaciones\nm\u00f3viles y clientes de terceros, es un vector de ataque conocido por tres razones principales:<\/p>\n\n\n\n
Resultado: vector de ataque activo \u2014 riesgo medio.<\/em>\nRecomendaci\u00f3n:<\/strong> si no se utilizan aplicaciones m\u00f3viles ni integraci\u00f3n con\nherramientas externas que requieran XML-RPC, deshabilitar completamente el endpoint\nmediante la siguiente regla en .htaccess<\/code>:<\/p>\n\n\n\n
<Files xmlrpc.php>\n  Order Deny,Allow\n  Deny from all\n<\/Files><\/code><\/pre>\n\n\n\n
Auditor\u00eda de seguridad WordPress – curl .git\/config devolviendo HTTP 403 confirmando protecci\u00f3n de repositorio de c\u00f3digo fuente<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Esta vulnerabilidad ocurre cuando la infraestructura expone accidentalmente el directorio\n.git<\/code> al internet p\u00fablico, lo que permite a cualquier persona descargar el\nhistorial completo del c\u00f3digo fuente del sitio, incluyendo configuraciones sensibles,\ncredenciales hardcodeadas y la l\u00f3gica de negocio interna. La prueba consisti\u00f3 en solicitar\nel archivo \/.git\/config<\/code> mediante curl -I -s<\/code>.<\/p>\n\n\n\n
El servidor respondi\u00f3 con HTTP\/1.1 403 Forbidden<\/strong>, lo que confirma que\nla infraestructura protege proactivamente los directorios sensibles y que el sitio no es\nvulnerable a la exposici\u00f3n de repositorios de c\u00f3digo. Resultado: sin vulnerabilidad.<\/em><\/p>\n\n\n\n
A09 \u2014 Fallos de Registro y Monitoreo (WAF Activo Verificado)<\/h3>\n\n\n\n
Esta categor\u00eda eval\u00faa si el sistema detecta y responde activamente ante ataques en curso.\nEl an\u00e1lisis se apoya directamente en los resultados del punto A03: cuando sqlmap intent\u00f3\nescanear el sitio, el servidor respondi\u00f3 con un HTTP 403 autom\u00e1tico<\/strong> desde\nel primer intento, bloqueando completamente la herramienta antes de que pudiera completar\nsu reconocimiento inicial.<\/p>\n\n\n\n
Este comportamiento es evidencia directa de que el Web Application Firewall (WAF)<\/strong>\nest\u00e1 activo, monitorea los patrones de tr\u00e1fico HTTP en tiempo real y responde\nautom\u00e1ticamente ante herramientas de reconocimiento conocidas. La misma respuesta de bloqueo\nfue observada durante el escaneo de WPScan. Resultado: aprueba satisfactoriamente.<\/em><\/p>\n\n\n\n
A10 \u2014 SSRF (Server-Side Request Forgery): El Ataque Que el Servidor Rechaz\u00f3<\/h3>\n\n\n\n
Auditor\u00eda de seguridad WordPress – resultado SSRF pingback con faultCode 0 XML-RPC m\u00f3dulo pingback sanitizado sin vulnerabilidad<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Aprovechando que xmlrpc.php<\/code> est\u00e1 accesible (hallazgo del punto A07), se\ndise\u00f1\u00f3 una prueba de Server-Side Request Forgery mediante un payload XML de tipo\npingback<\/em>. La idea es forzar al servidor WordPress a realizar una solicitud HTTP\nsaliente hacia un dominio externo controlado por el atacante. En una inyecci\u00f3n SSRF exitosa,\nel servidor contactar\u00eda http:\/\/www.google.com<\/code> y el atacante recibir\u00eda esa\nrespuesta, lo que le permitir\u00eda explorar la red interna del servidor o exfiltrar metadatos\nde la instancia cloud.<\/p>\n\n\n\n
El servidor respondi\u00f3 con una estructura XML de error completamente vac\u00eda:\n<faultCode>0<\/faultCode><\/code> y\n<faultString><\/faultString><\/code>. A diferencia de una inyecci\u00f3n SSRF\nexitosa (que devuelve un c\u00f3digo de estado num\u00e9rico mayor que cero), el faultCode 0<\/em>\nindica que el m\u00f3dulo pingback est\u00e1 internamente sanitizado o deshabilitado para peticiones\nsalientes. Resultado: sin vulnerabilidad por este vector.<\/em><\/p>\n\n\n\n
Lo Que Esta Auditor\u00eda de Seguridad WordPress Revel\u00f3<\/h2>\n\n\n\n
Tras aplicar las tres fases metodol\u00f3gicas completas de la\nauditor\u00eda de seguridad WordPress<\/strong>, el balance es el siguiente: la\ninfraestructura perimetral del sitio es s\u00f3lida y bien configurada, con un WAF activo,\nCDN de Hostinger, delegaci\u00f3n DNS en Cloudflare y criptograf\u00eda TLS 1.3 de grado bancario.\nSin embargo, la capa de aplicaci\u00f3n presenta vulnerabilidades concretas y corregibles que\ndeben abordarse antes de exponer el sitio a tr\u00e1fico real de clientes.<\/p>\n\n\n\n
Severidad<\/th>Categor\u00eda OWASP<\/th>Hallazgo<\/th>Acci\u00f3n requerida<\/th><\/tr><\/thead>
 Alta<\/strong><\/td>A04 \u2014 Insecure Design<\/td>Sin l\u00edmite de intentos de login (fuerza bruta)<\/td>Instalar Limit Login Attempts + 2FA<\/td><\/tr>
Media<\/strong><\/td>A01 \u2014 Broken Access Control<\/td>wp-config.php accesible (HTTP 200)<\/td>Regla 403 en .htaccess<\/td><\/tr>
Media<\/strong><\/td>A05 \u2014 Security Misconfiguration<\/td>Ausencia de X-Frame-Options, HSTS, X-Content-Type<\/td>Configurar Security Headers en servidor<\/td><\/tr>
 Media<\/strong><\/td>A07 \u2014 Auth Failures<\/td>xmlrpc.php accesible (amplificaci\u00f3n de fuerza bruta)<\/td>Deshabilitar xmlrpc.php si no es necesario<\/td><\/tr>
 Baja<\/strong><\/td>A05 \u2014 Security Misconfiguration<\/td>Versi\u00f3n PHP 8.3.30 expuesta en cabecera<\/td>expose_php = Off en php.ini<\/td><\/tr>
 Baja<\/strong><\/td>A05 \u2014 Security Misconfiguration<\/td>BREACH Attack \u2014 Content-Encoding: deflate<\/td>Tokens CSRF \u00fanicos por solicitud<\/td><\/tr>
 Correcto<\/strong><\/td>A02, A03, A08, A09, A10<\/td>TLS 1.3, WAF activo, sin SQLi, sin SSRF, .git protegido<\/td>Mantener y auditar peri\u00f3dicamente<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Para m\u00e1s informaci\u00f3n sobre c\u00f3mo implementar medidas de hardening en WordPress, puedes\nconsultar nuestra\ngu\u00eda completa de hardening para WordPress<\/a>,\nnuestro art\u00edculo sobre\nc\u00f3mo configurar cabeceras de seguridad en WordPress<\/a>,\ny la secci\u00f3n de\nplugins de seguridad recomendados para WordPress<\/a>.\nSi deseas entender mejor el contexto de las amenazas modernas, tambi\u00e9n te recomendamos\nrevisar nuestro art\u00edculo sobre\nc\u00f3mo prevenir ataques de fuerza bruta en WordPress<\/a>\ny nuestra gu\u00eda de\naplicaci\u00f3n del OWASP Top 10 en entornos WordPress<\/a>.<\/p>\n\n\n\n
V\u00eddeo explicativo Punto a Punto del Laboratorio de Pentesting<\/strong><\/h2>\n\n\n\n
\n