A la lliçó anterior vam deixar ZAP llest per treballar: el certificat arrel confiat, el proxy enrutant el trànsit de BazarNube i un context amb scope i autenticació ben definits. Tota aquesta preparació tenia un objectiu: arribar fins a les zones on de veritat hi ha risc. Ara posem la maquinària en marxa. En aquesta lliçó recorrerem el flux complet d'un escaneig dinàmic (DAST) sobre l'staging de BazarNube: explorarem l'aplicació amb l'spider i l'AJAX Spider, deixarem treballar l'escàner passiu, llançarem l'escàner actiu amb una política adequada, aprendrem a interpretar les alertes per risc i confiança, farem triage de falsos positius i generarem informes que mapegin les troballes al Top Ten 2021 i al backlog de l'equip.

Nota èticolegal (imprescindible). Un escaneig actiu envia atacs reals (payloads d'injecció, càrregues que modifiquen dades, peticions massives). Executa'l únicament contra sistemes de la teva propietat o amb permís explícit per escrit. En aquest curs sempre treballem sobre https://staging.bazarnube.local, un entorn propi, aïllat i amb dades fictícies. Mai apuntis ZAP en mode attack a producció ni a tercers com la passarel·la pay.tercero.com.

1. El flux d'un escaneig de principi a fi
2. Fase 1: explorar amb l'Spider i l'AJAX Spider
3. Fase 2: l'escàner passiu
4. Fase 3: l'escàner actiu i les polítiques d'escaneig
5. Interpretar alertes: risc i confiança
6. Triage de falsos positius
7. Mapeig d'alertes de ZAP al Top Ten 2021 i al backlog de BazarNube
8. Generació d'informes (HTML, JSON, Markdown)
9. Errors comuns i consells
10. Exercicis
11. Conclusió

Un escaneig DAST no és un botó màgic: és una seqüència. ZAP només pot atacar el que coneix, així que primer cal descobrir la superfície (URLs, formularis, paràmetres, endpoints d'API) i després provar-la. L'ordre és sempre el mateix:

Cada fase alimenta la següent: com millor sigui l'exploració, més complet serà l'arbre de llocs (Sites tree) i més superfície tindrà l'escàner actiu per provar. Un escaneig amb mala cobertura dona una falsa sensació de seguretat: "0 alertes altes" no significa res si l'spider no va arribar al 60% de l'aplicació.

L'Spider parteix d'una o diverses URLs llavor i segueix els enllaços href, src i les accions de formulari que troba a l'HTML. És ràpid i barat, però només veu el que és a l'HTML estàtic. Per llançar-lo sobre el nostre context autenticat:

1. Clic dret sobre el node arrel de BazarNube al Sites tree > Attack > Spider....
2. Selecciona el Context i el User que vam definir a 06-02, perquè explori ja autenticat com a venedor.
3. Deixa marcada l'opció de respectar l'scope del context.

Des de la línia de comandes via API (ho veurem en detall a 06-04) seria:

BazarNube té un frontend React: gran part de la navegació i les dades es carreguen per JavaScript, i el catàleg es pinta amb crides fetch a l'API. L'Spider tradicional no executa JavaScript, així que es perdria gairebé tot el marketplace. Per a això hi ha l'AJAX Spider, que controla un navegador real (Firefox/Chrome headless) i explora l'aplicació com ho faria un usuari, disparant esdeveniments i capturant les peticions XHR.

Regla pràctica per a BazarNube: executa primer l'Spider tradicional (barat, cobreix l'API i les rutes server-rendered del legacy Java) i tot seguit l'AJAX Spider per al frontend React. La unió de tots dos dona la millor cobertura.

Per a les APIs REST/GraphQL, la millor "exploració" no és l'spider sinó importar la definició: ZAP pot consumir un fitxer OpenAPI/Swagger o una col·lecció, poblant l'arbre amb tots els endpoints i els seus paràmetres. Si BazarNube publica openapi.json, importa'l abans d'escanejar.

Mentre explores (i mentre navegues manualment pel proxy), l'escàner passiu treballa en segon pla: no envia ni una sola petició extra. Es limita a observar les peticions i respostes que ja passen per ZAP i a detectar problemes visibles sense atacar:

• Capçaleres de seguretat absents (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options).
• Cookies sense Secure, HttpOnly o SameSite.
• Fugues d'informació (versions de servidor, comentaris, missatges d'error, tokens en URL).
• Recursos servits per HTTP dins d'HTTPS (mixed content).

Com que no ataca, l'escaneig passiu és segur fins i tot en producció i és el motor darrere del mode safe que vam veure a 06-01. És el primer lloc on mirar: moltes de les "victòries ràpides" de BazarNube (capçaleres i flags de cookie) surten aquí sense cost ni risc.

L'escàner actiu és on ZAP realment ataca: agafa cada URL i cada paràmetre descoberts i injecta payloads per provocar comportaments vulnerables (cometes per a SQLi, scripts per a XSS, rutes per a path traversal, etc.). Per això només es llança sobre staging propi.

Una Scan Policy defineix quines famílies d'atac s'executen i amb quina intensitat. Es gestiona a Analyse > Scan Policy Manager. Els seus dos eixos són:

• Threshold (llindar): com de "segur" ha d'estar ZAP abans de reportar. Low reporta més (i genera més falsos positius); High reporta només quan està molt segur. Off desactiva aquesta família.
• Strength (força): quants payloads prova per paràmetre. Low és ràpid; Insane és exhaustiu però lent i sorollós.

Crea una política a mida (per exemple BazarNube-Web) en lloc de fer servir la de per defecte: acota el temps d'escaneig i evita soroll irrellevant. Per llançar l'actiu: clic dret sobre el context > Attack > Active Scan..., tria el User autenticat i la Policy creada.

Cada troballa és una alerta amb dos eixos independents que no cal confondre:

• Risc (Risk): l'impacte potencial si és real. Nivells: High, Medium, Low, Informational.
• Confiança (Confidence): com de segur està ZAP que no és un fals positiu. Nivells: Confirmed, High, Medium, Low, False Positive (aquest últim el marques tu després del triage).

Una troballa High risk / Low confidence no s'ignora: es verifica manualment, perquè si es confirma és de les més greus. I una Low risk / High confidence pot ser una correcció trivial que convé tancar ja. Prioritza creuant tots dos eixos:

DAST genera falsos positius: és normal i esperable. El triage és la feina de separar el real de l'espuri abans de molestar la Lucía o en Marc amb un ticket. Procés recomanat per alerta:

1. Llegeix l'evidència que dona ZAP: la petició atacant i el fragment de resposta que va disparar la regla (pestanya Response amb el highlight).
2. Reprodueix-ho amb el Request Editor o curl: el comportament se sosté fora de ZAP?
3. Contrasta amb el codi quan puguis: un XSS reflectit reportat sobre un valor que el frontend escapa amb React pot ser fals.
4. Decideix: si és real, es queda; si és espuri, clic dret > Mark as False Positive (o puja-li el threshold d'aquesta regla). Documenta per què.

Un fals positiu mal tancat és tan perillós com no escanejar: si marques com a FP alguna cosa real, l'enterres. Deixa sempre una nota del raonament.

Les alertes de ZAP parlen l'idioma de les scan rules; el negoci i el backlog parlen l'idioma del Top Ten 2021 (que vam veure a M3). Traduir d'un a l'altre és el que converteix un informe tècnic en feina prioritzada. Aquesta és la taula de correspondència per a BazarNube:

Compte amb l'IDOR. El Broken Access Control de tipus IDOR (accés a una comanda aliena canviant l'id) que vam estudiar a M3 és difícil de detectar per a un DAST genèric, perquè ZAP no sap quin recurs "hauria" de veure cada usuari. ZAP té el complement Access Control Testing, però requereix que defineixis dos usuaris amb rols diferents i les regles d'accés esperades. No confiïs en l'escàner actiu per al control d'accés: completa'l amb proves manuals o de negoci.

Amb el triage fet, es genera l'informe. Des de la GUI: Report > Generate Report.... ZAP ofereix plantilles segons el destinatari:

Per API o CLI (anticipant 06-04):

L'informe no és el final de la feina: és l'entrada del backlog. Cada alerta confirmada es converteix en un BZN-xxx amb la seva categoria del Top Ten, la seva evidència i la seva prioritat per risc.

• Llançar l'actiu sense haver explorat. Si l'arbre de llocs està buit, l'escàner actiu no ataca res. Explora (Spider + AJAX Spider o import OpenAPI) abans.
• Oblidar l'autenticació. Si ZAP perd la sessió a mitja escaneig, tot l'autenticat queda sense provar. Verifica els indicadors de sessió del context (06-02) i afegeix /logout a les exclusions.
• Confondre risc amb confiança. Són eixos diferents. Un High risk / Low confidence es verifica, no es descarta.
• Escanejar producció "només una mica". No existeix un actiu "suau" segur: modifica dades i genera càrrega. Només staging propi.
• Fiar-se del "0 altes". Sense cobertura, zero alertes no és tranquil·litat. Mira sempre quantes URLs es van explorar.
• No documentar els falsos positius. Un FP sense justificació és deute ocult; el següent que el vegi no sabrà si fiar-se'n.
• Esperar que ZAP trobi IDOR/lògica de negoci. El DAST cobreix injeccions i misconfig; el control d'accés fi i la lògica requereixen prova manual.

Exercici 1. L'equip es queixa que ZAP "no troba gairebé res" al catàleg de BazarNube, que és un React SPA. L'arbre de llocs mostra només la home i /login. Què ha fallat a la fase d'exploració i com ho corregeixes?

Exercici 2. ZAP reporta una alerta "Cross Site Scripting (Reflected)" amb Risk: High i Confidence: Low sobre el paràmetre q del cercador. Descriu el procés de triage pas a pas abans d'obrir (o no) el ticket BZN-087.

Exercici 3. Has de prioritzar tres alertes per a la reunió amb la Lucía: (A) SQL Injection, High/Confirmed; (B) CSP Header Not Set, Medium/High; (C) Application Error Disclosure, Low/High. Ordena-les i mapeja cadascuna a la seva categoria del Top Ten 2021.

Solució 1. Només es va executar l'Spider tradicional, que no executa JavaScript, així que no va veure el catàleg carregat per React. La correcció és llançar l'AJAX Spider (que fa servir un navegador real) sobre el mateix context autenticat i, si BazarNube publica una definició OpenAPI de la seva API, importar-la per poblar tots els endpoints. Després es rellança l'escaneig amb l'arbre ja complet.

Solució 2. (1) Obrir l'alerta i llegir l'evidència: la petició injectada i el fragment de resposta ressaltat. (2) Reproduir amb el Request Editor o curl per veure si el payload torna sense escapar en la resposta HTML (no només en un JSON que el front mai renderitza com a HTML). (3) Comprovar si el valor acaba realment al DOM sense escapar; si React el pinta amb {q} l'escapa per defecte (possible FP), però si es fa servir dangerouslySetInnerHTML o s'insereix server-side, és real. (4) Si es confirma, obrir BZN-087 com a A03 Injection prioritari; si és espuri, marcar False Positive amb nota del motiu.

Solució 3. Ordre de prioritat: A > B > C.

• (A) SQL Injection, High/Confirmed -> A03: Injection. Màxima prioritat: confirmada i d'alt impacte.
• (B) CSP Header Not Set, Medium/High -> A05: Security Misconfiguration. Important i de correcció barata.
• (C) Application Error Disclosure, Low/High -> A05: Security Misconfiguration. Real però de baix impacte; victòria ràpida.

Ja domines el cicle complet d'un escaneig dinàmic en ZAP: explorar amb Spider i AJAX Spider, deixar treballar el passiu, atacar amb l'actiu fent servir una política a mida, interpretar les alertes per risc i confiança, fer triage de falsos positius, mapejar cada troballa al Top Ten 2021 i al backlog de BazarNube, i empaquetar-ho en un informe accionable. Tot això, sempre, contra el teu propi staging.

Fer això a mà cada vegada que es toca el codi no escala. A l'última lliçó del mòdul, 06-04 Automatització de Proves de Seguretat, portarem ZAP al pipeline: zap-baseline.py i zap-full-scan.py amb Docker, l'Automation Framework en YAML, l'API en mode daemon, i pipelines complets de GitHub Actions i GitLab CI que executen un DAST sobre BazarNube en cada canvi, publiquen l'informe com a artefacte i trenquen el build quan apareixen vulnerabilitats per sobre del llindar.