// AUDITORIA DAST: Hardening y Validación con OWASP ZAP
// Identificación de debilidades, remediación en Edge y Origen, y validación final
// Metodología: Escaneo dinámico (DAST) sobre infra web
*DISCLAMER* -> Por seguridad y cuidado en revelación de secretos se hace omisión de capturas de logs o detalles técnicos que puedan comprometer la seguridad de la información.
0x00 Auditoría y Hardening con OWASP ZAP
Documentación del proceso de identificación de debilidades mediante escaneos dinámicos y la implementación de contramedidas en el Edge (WAF/CDN) y en el Origen (Nginx).
0x01 Escaneo Inicial
Se realizo un ataque simulado sobre midominio.com y doc.midominio.com utilizando OWASP ZAP.
10 Flags de seguridad
Riesgos principales detectados:
- Exposicion de version de software (Information Disclosure)
- Vulnerabilidad a Clickjacking (Falta de X-Frame-Options)
- Riesgo de MIME-Sniffing
- Ausencia de HSTS (Strict-Transport-Security)
0x02 Remediación en Capa de Red (WAF Edge)
Delegamos el primer escudo al WAF del proveedor CDN para optimizar el rendimiento:
- HSTS (Strict-Transport-Security): Activado para forzar HTTPS en el navegador del usuario antes de que contacte el servidor de origen.
- No-Sniff Header: Activado para prevenir que el navegador ejecute archivos con tipos MIME incorrectos.
- Proxy DNS: Oculta la IP real del servidor de origen tras la red global del CDN.
0x03 Remediación en Servidor de Origen (Nginx Hardening)
Para asegurar que el servidor es seguro por dentro, implementamos cabeceras de seguridad directamente en la configuración de Nginx.
Archivo: /etc/nginx/sites-available/your-site
# Protección contra Clickjacking
add_header X-Frame-Options "SAMEORIGIN" always;
# Refuerzo contra MIME-Sniffing
add_header X-Content-Type-Options “nosniff” always;
# Content Security Policy (CSP) - El filtro definitivo
# Solo permite scripts y estilos del propio dominio o inline seguros
add_header Content-Security-Policy “default-src ‘self’; script-src ‘self’ ‘unsafe-inline’; style-src ‘self’ ‘unsafe-inline’; img-src ‘self’ data:; connect-src ‘self’;” always;
# Referrer Policy para privacidad
add_header Referrer-Policy “no-referrer-when-downgrade” always;
Archivo: /etc/nginx/nginx.conf
Desactivamos la exposicion de version del servidor:
server_tokens off; # Oculta version de Nginx y sistema operativo
0x04 Validación Final y Resultados
Tras la implementación, se ejecutó un tercer escaneo para verificar la eficacia de las medidas.
| Vulnerabilidad | Antes (Scan 1) | Despues (Scan 3) | Remediación |
|---|---|---|---|
| HSTS | x | ok | CDN Edge |
| X-Frame-Options | x | ok | Nginx Header |
| X-Content-Type | x | ok | CDN + Nginx |
| Server Version Leak | x | ok | server_tokens off |
| CSP | x | ok | Nginx Header |
Resultado Final: Reduccion del 60% en alertas totales y descenso del nivel de riesgo de Medio a Bajo/Informativo.
0x05 Lecciones Aprendidas
NOTA: Insights clave extraídos del proceso de auditoria
1. Defensa en Profundidad: Configurar cabeceras en el WAF/CDN es rápido, pero configurarlas también en Nginx asegura que el servidor sea seguro incluso si el tráfico logrará bypasear el proxy.
2. Conflictos de Configuración: Las directivas duplicadas (como server_tokens) pueden detener el servicio.
El comando sudo nginx -t es obligatorio antes de cualquier reinicio.
3. Falsos Positivos: ZAP puede generar alertas informativas sobre CSP si la política es permisiva con unsafe-inline.
Es un compromiso necesario cuando se requiere mantener la funcionalidad del diseno web.
0x06 Auditoria DAST al subdominio
Objetivo: Securizar el subdominio de documentación (doc.midominio.com), alojado en un servidor Ubuntu con Nginx, utilizando metodologías de escaneo dinámico (DAST) con OWASP ZAP.
0x07 Diagnostico Inicial
El primer escaneo automatizado con OWASP ZAP sobre el subdominio reveló una superficie de ataque vulnerable con multiples alertas de riesgo Medio y Bajo.
- Ausencia de Cabeceras de Seguridad: Faltaban X-Content-Type-Options, X-Frame-Options y Strict-Transport-Security (HSTS).
- CSP Permisiva: La política de seguridad utilizaba la directiva 'unsafe-inline' para scripts y estilos, dejando el sistema expuesto a ataques de Cross-Site Scripting (XSS).
- Falta de Integridad (SRI): Los recursos de terceros no contaban con verificación de hash.
[CAPTURA 4] Pantalla de OWASP ZAP con el escaneo baseline del subdominio doc.yourdomain.com. Debe mostrar el arbol de sitios, el panel de alertas con las vulnerabilidades Medium/Low detectadas y el resumen de riesgos.
0x08 Defensas en Nginx
La primera medida de remediación fue aplicar las cabeceras de seguridad faltantes directamente en el bloque del servidor Nginx.
Se inyectaron cabeceras restrictivas:
add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "SAMEORIGIN" always; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; add_header Referrer-Policy "no-referrer-when-downgrade" always;
Al aplicar una CSP estricta que prohibía el código inline, el diseño visual de la interfaz (CSS) y las reglas de JavaScript embebidas en el archivo principal fueron bloqueadas por el navegador, "rompiendo" la aplicación. Esto válido que la política de Nginx funcionaba, pero requería una refactorización del código.
0x09 Refactorización Segura (Nonces Criptográficos)
Para restaurar la funcionalidad sin comprometer la seguridad (evitando volver a usar 'unsafe-inline')
1. Externalización de Recursos
Se extrajo el codigo CSS y JavaScript del archivo principal hacia archivos dedicados (style.css y security.js).
2. Implementación de Nonces Criptográficos
Se generó un token único por sesión en PHP.
Este nonce se inyectó tanto en la cabecera CSP de Nginx como en las etiquetas permitidas en el HTML:
// Generación del nonce (PHP)
$nonce = bin2hex(random_bytes(16));
// Inyección en la cabecera CSP
header(“Content-Security-Policy: script-src ‘nonce-nonce’;”);
// Uso en etiquetas HTML
<script nonce=”<?= nonce ?>"</span>>...</script>
<link <span>nonce</span>=<span>"<?= nonce ?>” rel=“stylesheet” href=“style.css”>
3. Restricción de Orígenes (CORS/CSP)
Se limitó estrictamente la carga de iframes únicamente a drive.google.com y las fuentes tipográficas a los dominios oficiales de Google Fonts.
0x0A Corrección de Scope Creep
Tras el parcheo, un segundo escaneo seguia mostrando alertas.
El análisis del reporte revelo un problema de Scope Creep (Contaminación de Alcance):
ZAP estaba escaneando dominios externos vinculados en el HTML (como fonts.googleapis.com o archive.mozilla.org), registrando vulnerabilidades de servidores de terceros sobre los que no se tiene control.
Solución:
- Se configuró el scope dentro de OWASP ZAP para limitar los vectores de ataque estrictamente al subdominio objetivo: https://doc.midominio.com
- Se anadieron cabeceras de seguridad básicas al bloque de redirección del puerto 80 en Nginx para evitar falsos positivos durante la transición a HTTPS.
0x0B Validación Final
El escaneo definitivo sobre el subdominio acotado demostró un bastionado exitoso, eliminando el 100% de las vulnerabilidades de riesgo Alto, Medio y Bajo.
Resultados del reporte final:
| Métrica | Resultado |
|---|---|
| Vulnerabilidades Reales | 0 (solo avisos informativos) |
| Detección de Sesión | Cookies endurecidas: HttpOnly, Secure, SameSite=Strict |
| Defensa Activa | 93% de peticiones rechazadas con codigos 4xx |
| Sistemas Validados | Tarpitting, Honeypot, Control de fuerza bruta |
Los sistemas de defensa activos (Tarpitting, Honeypot oculto para bots y control de fuerza bruta) funcionaron correctamente, bloqueando al escaner cuando intento realizar comportamientos anómalos.
[EOF] "Nothing is ever truly protected, not even from yourself"