Cerramos la lección anterior (07-03) con una idea: Burp Professional es excelente, pero tiene licencia de pago y no es siempre la mejor opción cuando lo que quieres es integrar las pruebas web en tuberías automáticas. Para ese terreno existe una alternativa libre, completa y mantenida por la comunidad: OWASP ZAP (Zed Attack Proxy). Es el compañero natural de Burp en el maletín del pentester web, y en la auditoría de TechNova sería la herramienta con la que dejarías un escaneo corriendo o la que montarías en el pipeline de la tienda tienda.technova.lab.

Esta lección cubre la arquitectura de ZAP, la diferencia clave entre escaneo pasivo y activo, el spider tradicional y el AJAX Spider para aplicaciones modernas, los modos automático vs. manual, el HUD (Heads-Up Display) sobre el navegador, y —lo más distintivo— su automatización y API para CI/CD y DevSecOps. Cerramos con una tabla comparativa Burp vs. ZAP para saber cuándo usar cada una. No repetimos la teoría de las vulnerabilidades web (Módulo 4): aquí se trata de manejar la herramienta y entender su encaje en pipelines. Todo, como siempre, contra objetivos autorizados o tu laboratorio.

1. Qué es OWASP ZAP y por qué es relevante
2. Arquitectura y modos de trabajo
3. Escaneo pasivo vs. activo
4. Spider y AJAX Spider
5. El HUD: pruebas desde el navegador
6. Automatización y API para CI/CD
7. Tabla comparativa: Burp vs. ZAP
8. Errores Comunes y Consejos
9. Ejercicios
10. Conclusión

OWASP ZAP es un proxy de interceptación web de código abierto y gratuito, proyecto insignia de la Open Web Application Security Project (hoy bajo la Software Security Project). Comparte la idea central de Burp —sentarse entre el navegador y el servidor— pero con dos diferencias que definen su carácter:

• Es libre y completo: incluye escaneo activo automático sin coste, algo que en Burp está reservado a la edición Pro.
• Está pensado para automatizarse: ofrece una API y utilidades diseñadas para ejecutarse sin interfaz gráfica, dentro de tuberías de integración continua.

Eso lo convierte en la opción de referencia para DevSecOps: meter una prueba de seguridad web en cada despliegue, de forma desatendida y gratuita.

ZAP se organiza en torno al mismo esquema de proxy, con un conjunto de componentes propios.

ZAP ofrece modos de política de seguridad que limitan lo que puede hacer, una salvaguarda pensada justo para evitar atacar por error algo fuera de alcance:

El modo Protected es la buena práctica: garantiza que el escaneo activo solo golpee lo que has declarado como objetivo autorizado, evitando el clásico accidente de escanear un dominio de terceros.

Esta es la distinción más importante de ZAP y la que hay que tener siempre clara.

• El escaneo pasivo está siempre activo en segundo plano: mientras navegas por la tienda de TechNova, ZAP analiza cada respuesta y levanta alertas (por ejemplo, falta de cabeceras de seguridad, justo uno de los hallazgos del Módulo 6) sin tocar nada.
• El escaneo activo es intrusivo: lanza payloads contra los parámetros descubiertos para provocar y confirmar vulnerabilidades. Es potente pero peligroso en producción, porque puede insertar datos basura, disparar acciones o tumbar el servicio.

Uso responsable: el pasivo es seguro casi en cualquier contexto; el activo solo se lanza contra objetivos autorizados o tu laboratorio, y controlando el impacto. Contra tienda.technova.lab en tu red host-only puedes escanear activamente sin miedo porque el servidor es tuyo.

Antes de escanear hay que descubrir las URLs de la aplicación. ZAP trae dos rastreadores:

• Spider tradicional: sigue enlaces del HTML de forma recursiva. Rápido y suficiente para webs clásicas servidas por el servidor, como una tienda PHP tradicional.
• AJAX Spider: controla un navegador real para ejecutar JavaScript y descubrir contenido que solo aparece tras la interacción. Imprescindible en aplicaciones modernas (SPA con React, Angular, Vue) donde el spider clásico apenas ve nada porque el contenido se genera en el cliente.

Para la tienda PHP de TechNova, el spider tradicional cubre casi todo; el AJAX Spider entraría en juego si la tienda tuviera un carrito o un buscador construidos con JavaScript dinámico.

El HUD (Heads-Up Display) es una función distintiva de ZAP: superpone sus controles directamente sobre la página web en el navegador, sin tener que saltar a la ventana de ZAP. Ves alertas, lanzas el spider o el escaneo activo y revisas hallazgos desde iconos en los márgenes de la propia web.

• Ventaja: flujo muy visual e ideal para aprender, porque relaciona cada alerta con lo que ves en pantalla.
• Cuándo: trabajo manual e interactivo. Para automatización se usa el modo headless y la API (siguiente apartado).

Se activa desde la barra de ZAP ("Enable HUD") y abriendo el navegador proxificado. Es una de las razones por las que ZAP es muy recomendable para quien empieza en pruebas web.

Aquí está el gran diferencial de ZAP frente a Burp. ZAP puede ejecutarse sin interfaz gráfica (headless) y controlarse por API REST o por scripts, lo que permite meter una prueba de seguridad web dentro de una tubería de despliegue. Es la base del DevSecOps: seguridad automatizada en cada release.

Un uso habitual es el baseline scan (escaneo de línea base, sobre todo pasivo) empaquetado en Docker, ideal para un pipeline de CI/CD:

• zap-baseline.py navega y ejecuta el escaneo pasivo, generando un informe.
• -t indica el objetivo (autorizado); -r el fichero de informe HTML.
• Devuelve un código de salida distinto de cero si encuentra alertas, lo que permite hacer fallar el build si aparecen problemas de seguridad.

Ese código de salida es la clave del encaje en CI/CD: el pipeline puede bloquear un despliegue inseguro automáticamente. Para escaneos más completos existe zap-full-scan.py (incluye escaneo activo, solo contra entornos autorizados). Y para orquestar todo de forma declarativa, ZAP ofrece los Automation Framework (planes en YAML) y la API para integraciones a medida.

Uso responsable: incluso en CI/CD, el objetivo del escaneo debe ser un entorno propio (staging, laboratorio), nunca un tercero. Automatizar no elimina la necesidad de autorización.

Ambas hacen lo esencial (proxy, spider, repetición manual, escaneo). Elegir depende del contexto.

Regla práctica:

• Elige Burp para pentesting manual profundo, sobre todo si dispones de la edición Pro: Repeater e Intruder son el estándar del trabajo interactivo.
• Elige ZAP cuando el presupuesto es cero, cuando necesitas escaneo activo gratuito, o cuando quieres automatizar en CI/CD y DevSecOps.
• En la práctica, muchos profesionales usan ambas: Burp para el trabajo manual del engagement y ZAP para la automatización y los escaneos desatendidos. No son rivales excluyentes; son complementarias.

• Lanzar escaneo activo sin autorización. El activo envía payloads reales y puede dañar datos o el servicio. Úsalo solo contra tu laboratorio u objetivos autorizados; para lo demás, quédate en pasivo.
• Confundir spider y escaneo. El spider descubre URLs; el escáner las prueba. Sin spider (o AJAX Spider) previo, el escaneo no ve media aplicación.
• Olvidar el AJAX Spider en SPAs. En webs con mucho JavaScript, el spider tradicional apenas descubre contenido. Usa el AJAX Spider.
• No usar el modo Protected en engagements. Sin él, un escaneo activo podría golpear un dominio fuera de alcance. Restringe las acciones al scope.
• Automatizar contra terceros. Meter ZAP en CI/CD no exime de autorización: apunta siempre a staging o laboratorio propio.
• Consejo: empieza con el escaneo pasivo y el HUD para aprender sin riesgo, y da el salto al activo y a la automatización cuando controles el impacto.

Ejercicio 1. Explica con tus palabras la diferencia entre el escaneo pasivo y el activo de ZAP, con un ejemplo de qué detectaría cada uno en la tienda de TechNova, y di cuál puedes lanzar sin autorización y por qué.

Ejercicio 2. Quieres integrar una prueba de seguridad web en el pipeline de despliegue de la tienda de TechNova (entorno de staging propio). Escribe el comando de zap-baseline.py con Docker y explica cómo harías que el build falle si aparecen alertas.

Ejercicio 3. Un equipo duda entre Burp y ZAP. El escenario A es un pentest manual profundo de una semana; el escenario B es añadir seguridad automática a cada despliegue con presupuesto cero. Recomienda una herramienta para cada escenario y justifícalo.

Solución 1. El escaneo pasivo solo observa el tráfico que genero al navegar, sin enviar ataques: detectaría, por ejemplo, la ausencia de cabeceras de seguridad o cookies sin el flag Secure en la tienda. El escaneo activo envía payloads contra los parámetros para provocar vulnerabilidades: detectaría una inyección SQL en producto.php?id= lanzando comillas y sentencias. Puedo lanzar el pasivo sin autorización porque no toca el servidor (solo mira); el activo requiere autorización explícita o mi propio laboratorio, porque es intrusivo y puede alterar datos o degradar el servicio.

Solución 2.

zap-baseline.py devuelve un código de salida distinto de cero cuando encuentra alertas. En el pipeline, basta con no ignorar ese código: si el paso de CI falla (exit code ≠ 0), el build se marca como fallido y se bloquea el despliegue. Así una web con problemas de seguridad no llega a producción. El objetivo es staging propio, no un tercero.

Solución 3. Escenario A (pentest manual profundo): Burp Suite, preferiblemente Pro. Repeater e Intruder son el estándar para el trabajo interactivo y minucioso de un engagement de una semana. Escenario B (seguridad automática, presupuesto cero): OWASP ZAP, por ser libre, incluir escaneo activo gratuito y estar diseñado para ejecutarse headless con API y en Docker dentro de un pipeline de CI/CD. Muchos equipos, de hecho, usan las dos: Burp para lo manual y ZAP para lo automatizado.

OWASP ZAP es la alternativa libre y completa a Burp, y brilla justo donde Burp cobra o no llega: escaneo activo gratuito y, sobre todo, automatización en CI/CD y DevSecOps. Repasamos su arquitectura y sus modos de seguridad (con Protected como buena práctica), la distinción capital entre escaneo pasivo (observa, seguro) y activo (ataca, requiere autorización), el spider y el AJAX Spider para descubrir aplicaciones clásicas y modernas, el HUD para aprender de forma visual, y su API/modo headless para meter seguridad en cada despliegue con zap-baseline.py y hacer fallar el build ante alertas. La tabla comparativa dejó la regla clara: Burp para el pentest manual profundo, ZAP para lo libre y lo automatizado, y en la práctica ambas a la vez.

Con ZAP completamos el instrumental web y, con él, el recorrido a fondo por las cuatro grandes herramientas del maletín: Kali como entorno, Metasploit para explotación, y Burp y ZAP para la web. Ya sabes con qué trabaja un pentester. Queda la pregunta más importante de todas: cómo seguir creciendo en esta profesión de forma legal y ética. La última lección del curso responde a eso: Recursos de Aprendizaje Continuo.