DAST: Análisis Dinámico con OWASP ZAP

Resumen Ejecutivo

OWASP ZAP prueba la aplicación en ejecución como lo haría un atacante, detectando vulnerabilidades que el análisis estático no puede encontrar.

• Valor: Detecta fallos de configuración, headers de seguridad faltantes, inyecciones y problemas de autenticación en runtime.
• Eficiencia: Escaneo automatizado post-deploy a QA — no requiere configuración por parte del desarrollador.
• Riesgo sin esto: SAST analiza código, pero no detecta configuraciones inseguras del servidor, headers faltantes o problemas de autenticación que solo se manifiestan en runtime.

DAST (Dynamic Application Security Testing) es una técnica de “caja negra” que prueba una aplicación en ejecución para encontrar vulnerabilidades de seguridad. A diferencia de SAST, que lee tu código, DAST interactúa con tu aplicación como lo haría un atacante, enviando peticiones maliciosas para ver cómo responde.

En HERA, utilizamos la reconocida herramienta open-source OWASP ZAP (Zed Attack Proxy) para realizar estos análisis.

SAST vs. DAST: Dos Caras de la Misma Moneda

Es crucial entender que SAST y DAST no son competidores, sino complementarios.

SAST vs. DAST: Comparación

SAST

SonarQube

Análisis de Caja Blanca

Ventajas

• Analiza el 100% del código fuente
• Rápido — se ejecuta en cada build
• Identifica la línea exacta del código vulnerable
• Detecta problemas en etapa temprana

Limitaciones

• No ve la aplicación en ejecución
• Propenso a falsos positivos
• No detecta errores de configuración del servidor

+

DAST

OWASP ZAP

Análisis de Caja Negra

Ventajas

• Encuentra errores de configuración del servidor
• Muy pocos falsos positivos
• Prueba la app tal como corre en producción
• Detecta vulnerabilidades runtime (XSS, SQLi)

Limitaciones

• No tiene visibilidad del código fuente
• Es más lento — no corre en cada commit
• Requiere una app desplegada en QA

SAST y DAST son complementarios — juntos brindan cobertura completa de seguridad

Mensaje clave SAST analiza código estático. DAST analiza la aplicación corriendo. Ambos son complementarios.

¿Cómo funciona DAST en HERA?

El análisis DAST no se ejecuta en cada commit, ya que requiere una aplicación desplegada y puede ser lento. En su lugar, lo integramos de la siguiente manera:

1. Despliegue a QA: Después de que un MR se integra en la rama develop, el pipeline despliega automáticamente la nueva versión al ambiente de QA.
2. Ejecución de ZAP: Una vez desplegada la app, un job en el pipeline de develop inicia el escaneo DAST con OWASP ZAP contra la URL del ambiente de QA (ej. https://mi-app-qa.cloudherdez.com).
3. Análisis Pasivo y Activo:
   • Spider (Crawl): ZAP primero navega la aplicación para descubrir todas las páginas y endpoints.
   • Passive Scan: Mientras navega, analiza todas las peticiones y respuestas en busca de fallos de seguridad obvios (ej. falta de headers de seguridad).
   • Active Scan: ZAP comienza a “atacar” la aplicación, enviando miles de payloads maliciosos a los endpoints descubiertos para probar vulnerabilidades como SQL Injection, XSS, etc.
4. Reporte: Al finalizar, ZAP genera un reporte con las vulnerabilidades encontradas, que se adjunta como un artefacto al pipeline de GitLab.

Integración en el Pipeline

El job de DAST forma parte del Golden Pipeline y corre después del deploy a QA sobre la rama develop. El equipo de producto no lo escribe a mano — se hereda del template vía include:.

Contrato del job dast-zap

Atributo	Valor
Stage	security (puede posicionarse como post-deploy en algunas variantes del template)
Imagen base	OWASP ZAP oficial
Target URL	URL del ambiente QA del producto (derivada del CI_PROJECT_NAME y convención de dominio)
Dependencia	needs: deploy-qa — requiere que la app ya esté desplegada en QA
Trigger	Automático sobre rama develop (después del deploy a QA)
Tipo de escaneo por defecto	Baseline (pasivo, rápido) — pensado para no frenar el ciclo de desarrollo
allow_failure	true — no bloquea el pipeline por defecto; las vulnerabilidades se gestionan como tickets
Artefacto	Reporte HTML (zap_report.html), retenido siempre (incluso si el job falla)

Escaneo activo vs. pasivo

El default es zap-baseline.py — pasivo y rápido, útil para feedback continuo en cada deploy a QA. Para análisis más profundo (y significativamente más lento) existe zap-full-scan.py. El Golden Pipeline expone la variante via variable del service-manifest.yml; la elección depende de la criticidad del producto y del tiempo disponible en el pipeline.

Implementación canónica en el Golden Pipeline

La definición exacta del job (versión pineada de ZAP, script de wait-for-ready, flags del escaneo, rules para branch/MR, artifacts:) vive en grupo-herdez/platform/pipelines/gitlab-ci/ bajo el stage security. El portal documenta el contrato observable; el código canónico vive en el template para evitar drift.

---

Vulnerabilidades Comunes Detectadas por DAST

DAST es particularmente bueno para encontrar vulnerabilidades del OWASP Top 10, como:

• A01: Broken Access Control: Intentos de acceder a URLs de administrador sin estar logueado.
• A03: Injection: Inyección de SQL, Cross-Site Scripting (XSS), etc.
• A05: Security Misconfiguration: Falta de headers de seguridad importantes (Content-Security-Policy, X-Content-Type-Options), listado de directorios habilitado, etc.
• A07: Identification and Authentication Failures: Problemas con la gestión de sesiones, cookies inseguras, etc.

El reporte de ZAP te dará detalles exactos sobre la URL, el parámetro y el payload que causaron la vulnerabilidad, facilitando su reproducción y corrección.

---

Ejemplo de Remediación: Headers de Seguridad Faltantes

Una de las alertas más comunes de ZAP es la ausencia de headers de seguridad HTTP. La corrección se aplica en la configuración del servidor o del framework:

// Node.js / Express — middleware de headers de seguridad
const helmet = require('helmet');

app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'"],
      styleSrc: ["'self'", "'unsafe-inline'"],
      imgSrc: ["'self'", "data:", "https:"],
    },
  },
  hsts: { maxAge: 31536000, includeSubDomains: true },
  frameguard: { action: 'sameorigin' },
  noSniff: true,
  xssFilter: true,
}));

Tras redesplegar a QA con estos headers, el siguiente escaneo de ZAP dejará de reportar estas alertas.

---

Lista de Verificación para Tech Leads

Después de cada escaneo DAST en QA:

• El reporte de ZAP fue revisado (artefacto adjunto al pipeline)
• Las alertas de riesgo High tienen un issue de GitLab asignado con SLA
• Los headers de seguridad obligatorios están presentes (CSP, HSTS, X-Content-Type-Options, X-Frame-Options)
• Las alertas de riesgo Medium tienen fecha estimada de corrección
• Las alertas Informational o falsos positivos fueron documentados como tales en el issue