Al mòdul anterior vam tancar SAMM assenyalant que diverses millores del roadmap de BazarNube (les pràctiques de Security Testing i Secure Build) no se sostenen només amb estratègia: exigeixen executar proves de seguretat reals sobre l'aplicació en marxa. Aquest "amb què ho fem?" té un nom concret en el món del codi obert: OWASP ZAP. Amb aquesta lliçó passem de l'estratègia (Top Ten, ASVS, SAMM) a l'eina que ens deixa confirmar i descobrir vulnerabilitats de manera dinàmica, mentre l'app corre en staging. En aquest primer capítol entendràs què és ZAP, com està construït per dins i quin paper juga dins del flux d'assegurament de BazarNube.

1. Què és ZAP i d'on ve
2. ZAP com a proxy d'intercepció i com a DAST
3. Arquitectura i components clau
4. Escaneig passiu enfront d'escaneig actiu
5. Els modes de ZAP (safe, protected, standard, attack)
6. Casos d'ús habituals
7. Com encaixa ZAP en el flux de BazarNube
8. Nota èticolegal

ZAP són les sigles de Zed Attack Proxy. És una eina gratuïta i de codi obert per trobar vulnerabilitats de seguretat en aplicacions i APIs web mentre s'executen. És, amb diferència, l'escàner dinàmic (DAST) lliure més usat del món.

Un apunt sobre el seu govern, perquè genera confusió:

• Va néixer i va créixer durant anys com a projecte insígnia (flagship) d'OWASP.
• El 2023 el projecte es va traslladar a la fundació Software Security Project (SSP), on continua el seu desenvolupament. Per això trobaràs documentació que l'anomena "OWASP ZAP" i documentació més recent que l'anomena només "ZAP".
• A efectes pràctics per a BazarNube tant és el paraigua organitzatiu: l'eina, el binari i la comunitat són els mateixos. En aquest curs l'anomenarem ZAP.

Recorda el que vam veure a M2: ZAP és DAST (Dynamic Application Security Testing). Prova l'aplicació en execució, des de fora, com ho faria un atacant, sense necessitat de veure el codi font. És complementari a SAST (analitza el codi estàtic) i a SCA (analitza dependències). No competeixen: es combinen.

ZAP té dues cares que convé no barrejar:

La clau és que tot passa pel proxy. ZAP no endevina l'estructura de l'app: n'aprèn de les peticions que el travessen. Com millor "vegi" el teu trànsit (navegació manual + spiders), millors seran els seus resultats.

Per dins, ZAP és un conjunt de peces que col·laboren. Conèixer-les t'ajuda a interpretar la GUI i, més endavant, a automatitzar.

• Proxy d'intercepció: el cor. Captura tot el trànsit HTTP(S). Permet pausar peticions (breakpoints) i editar-les abans d'enviar-les.
• Sites tree (arbre de llocs): el mapa jeràrquic de tot el que ZAP ha vist de BazarNube (dominis, rutes, endpoints, paràmetres). És la font sobre la qual operen els escàners.
• Spider tradicional: rastreja l'app seguint enllaços de l'HTML. Ràpid, però es perd amb contingut generat per JavaScript.
• AJAX Spider: controla un navegador real (headless) per rastrejar aplicacions d'una sola pàgina (SPA). Imprescindible per al frontend React de BazarNube, on moltes rutes no existeixen fins que el JS les genera.
• Escàner passiu: observa el trànsit que ja ha passat pel proxy i detecta problemes sense enviar res de nou (capçaleres de seguretat absents, cookies sense flags, fugues d'informació). És segur per naturalesa.
• Escàner actiu: injecta payloads (SQLi, XSS, path traversal...) contra els paràmetres descoberts i observa la resposta. És intrusiu.
• Alertes: cada troballa, classificada per risc (Alt/Mitjà/Baix/Informatiu) i confiança.
• Add-ons (Marketplace): ZAP és modular; gairebé tota la funcionalitat avançada (AJAX Spider, regles d'escaneig, formats d'informe, l'Automation Framework) arriba com a complements actualitzables.

Aquesta distinció és la més important de tota la lliçó, perquè marca què és segur llançar i què no.

Regla mental per a BazarNube: el passiu pots tenir-lo sempre encès; l'actiu només es llança contra el staging propi i amb coneixement de l'equip.

ZAP té un interruptor global que limita el que pot fer. És la teva xarxa de seguretat per no atacar per error alguna cosa que no has de fer.

Consell: en començar amb BazarNube treballa en Protected amb un scope ben definit (ho veurem a 06-02). Així, encara que l'spider descobreixi un enllaç extern (per exemple una passarel·la de pagament de tercers), ZAP no l'atacarà.

• Exploració manual assistida: navegues BazarNube amb el proxy posat i ZAP va detectant problemes passivament mentre uses el web.
• Escaneig automàtic d'una URL o d'una API (amb la seva definició OpenAPI/Swagger).
• Proves d'APIs: importes l'especificació OpenAPI del backend Node/Express i ZAP coneix tots els endpoints sense necessitat d'spider.
• Regressió de seguretat en CI/CD: cada desplegament llança un baseline scan (ho veurem a 06-04).
• Confirmar troballes concretes: un pentester va reportar un IDOR; uses ZAP per reproduir-lo de manera controlada.

Recorda el fil del curs. A M3 el Top Ten ens va donar troballes concretes a BazarNube: un IDOR a /api/orders/{id}, SQLi en un cercador, XSS a les ressenyes de producte, capçaleres de seguretat absents, un endpoint legacy Java amb risc de XXE, i una funció d'importació amb pinta de SSRF. A M4 vam convertir part d'això en requisits verificables d'ASVS. A M5 SAMM ens va dir organitzativament que calia fer Security Testing.

ZAP és la peça que tanca el bucle: agafa aquestes troballes teòriques i les verifica dinàmicament en el staging de BazarNube.

La Lucía (backend) vol confirmar si el SQLi del cercador segueix viu després d'un pedaç. En Marc (frontend) vol saber si l'XSS de ressenyes es dispara amb el nou sanititzador. L'SRE vol que tot això corri sol en cada desplegament a staging. ZAP respon als tres.

ZAP envia atacs reals. L'escàner actiu injecta injeccions SQL, XSS i més contra l'aplicació objectiu. Això té implicacions serioses:

• Només pots escanejar activament sistemes de la teva propietat o per als quals tinguis permís explícit i per escrit.
• A BazarNube treballem sempre contra un entorn de staging propi, mai contra producció ni contra la infraestructura de tercers (passarel·les de pagament, CDNs, APIs externes).
• Un escaneig actiu pot corrompre dades, disparar correus, esgotar recursos o tombar el servei. Tracta'l com una prova destructiva.
• Escanejar un sistema aliè sense autorització pot constituir un delicte en la majoria de jurisdiccions.

Aquesta advertència es repetirà al llarg del mòdul. No és una formalitat: és la línia que separa l'AppSec professional de l'accés no autoritzat.

• Confondre "ZAP troba vulnerabilitats sol": ZAP només prova el que ha vist passar pel seu proxy. Si no explores bé l'app (manual + spiders), grans zones queden sense analitzar.
• Llançar escaneig actiu "per veure què surt" sense scope: acabes atacant dominis de tercers. Defineix sempre l'scope i treballa en mode Protected.
• Creure que l'escàner passiu és suficient: el passiu no troba SQLi ni XSS; per a això necessites l'actiu. Tots dos són complementaris.
• Oblidar l'AJAX Spider en SPAs: amb un frontend React com el de BazarNube, l'spider tradicional gairebé no veu res. Necessites l'AJAX Spider.
• Consell: comença sempre per entendre el trànsit com a proxy abans d'automatitzar. Si no entens quines peticions fa BazarNube, no interpretaràs bé les alertes.

Exercici 1. Classifica cada troballa segons com la detectaria l'escàner passiu o l'actiu de ZAP: (a) la cookie de sessió de BazarNube no té el flag HttpOnly; (b) el cercador és vulnerable a SQLi; (c) falta la capçalera Content-Security-Policy; (d) un paràmetre redirect permet redirecció oberta.

Exercici 2. L'equip provarà BazarNube en staging però tem que ZAP toqui per error la passarel·la de pagament externa pay.tercero.com, que apareix enllaçada des del checkout. Quin mode de ZAP triaries i què has de configurar per evitar-ho?

Exercici 3. En Marc pregunta per què l'spider tradicional gairebé no va trobar rutes del panell de venedor de BazarNube, que és una SPA en React. Explica la causa i la solució dins de ZAP.

Solució 1. (a) Passiu: es detecta observant la capçalera Set-Cookie sense enviar res de nou. (b) Actiu: requereix injectar payloads i observar la resposta. (c) Passiu: és l'absència d'una capçalera en respostes ja vistes. (d) Actiu: cal provar valors maliciosos en el paràmetre redirect.

Solució 2. Triar el mode Protected, que només permet accions intrusives contra URLs dins de l'scope. Definir l'scope incloent únicament el domini de staging de BazarNube i excloent (o simplement no incloent) pay.tercero.com. Així, encara que l'spider descobreixi l'enllaç, ZAP no llançarà atacs contra ell.

Solució 3. L'spider tradicional només segueix enllaços presents a l'HTML inicial. En una SPA React, les rutes i enllaços es generen dinàmicament amb JavaScript després de la càrrega, així que gairebé no hi ha enllaços estàtics a seguir. La solució és fer servir l'AJAX Spider, que maneja un navegador real capaç d'executar el JS i descobrir les rutes generades.

Ja tens el mapa mental de ZAP: un proxy d'intercepció que a més fa d'escàner DAST, amb peces ben diferenciades (sites tree, spiders, escàner passiu i actiu, alertes) i una sèrie de modes que acoten quant mal pot fer. Has vist la distinció crítica entre passiu (observar, segur) i actiu (atacar, només en staging propi) i com ZAP tanca el bucle que vam obrir amb el Top Ten, ASVS i SAMM sobre BazarNube.

A la següent lliçó, 06-02 Instal·lació i Configuració, passem de la teoria a tenir ZAP funcionant: l'instal·larem (paquet i Docker), configurarem el navegador i el certificat arrel per inspeccionar HTTPS, i prepararem el context, l'scope i l'autenticació necessaris per provar les zones autenticades de BazarNube.