Els dos exercicis anteriors van treballar en l'escenari ideal: vam trobar les vulnerabilitats i les vam corregir abans que causessin cap dany. La realitat no sempre concedeix aquest marge. En aquest cas d'estudi fem un pas enrere en el temps fins a un moment en què BazarNube encara no havia fet aquesta feina, i una de les vulnerabilitats del curs —l'IDOR de comandes, BZN-101— seguia viva en producció. El resultat va ser un incident de fuita de dades personals. El teu paper aquí no és el de desenvolupador que corregeix, sinó el d'analista que investiga: reconstruir què va passar, com es va detectar, per què va ocórrer i què caldria canviar perquè no es repeteixi. Aplicarem el logging i la monitorització de 03-11, la classificació del Top Ten i el marc de resposta a incidents, tot sobre una narrativa concreta. Al final tindràs no només el relat de l'incident, sinó el mètode per analitzar qualsevol altre.

1. La narrativa de l'incident
2. Cronologia dels fets
3. Com es va detectar: el paper del logging i la monitorització
4. Anàlisi de causa arrel
5. Avaluació de l'impacte
6. Resposta a l'incident: contenció, eradicació i recuperació
7. Lliçons apreses i controls OWASP que l'haurien evitat
8. Errors comuns i consells
9. Exercicis
10. Conclusió

Context. És un dimarts al matí. La Lucía rep un avís de suport: diversos clients es queixen de correus de màrqueting d'un competidor que esmenten comandes recents que van fer a BazarNube, amb detall de productes i adreces. Algú té dades que no hauria de tenir. La SRE confirma que no hi ha hagut accés a la base de dades ni credencials filtrades conegudes. L'equip obre un incident de seguretat.

L'endpoint GET /api/comandes/:id retornava qualsevol comanda a qualsevol usuari autenticat, sense comprovar la propietat (l'IDOR BZN-101 que vam remediar a 08-02). Un atacant va crear un compte legítim de client, va obtenir un token vàlid i va enumerar els identificadors de comanda de manera seqüencial (/api/comandes/1, /2, /3...), descarregant les dades de desenes de milers de comandes alienes: nom, adreça, productes i correu. No va haver-hi "hackeig" sofisticat ni malware: només una fallada d'autorització explotada amb un script i paciència.

Reconstruir la cronologia és el primer lliurable de qualsevol anàlisi. Combina el que diuen els logs d'accés, els d'aplicació i els avisos externs.

Dos fets salten a la vista: l'extracció va durar quatre dies i la detecció va trigar una setmana més, i no va arribar per un sistema propi, sinó per les queixes dels clients. Aquest retard és, en si mateix, una segona troballa tan greu com l'IDOR.

L'incident es va detectar tard i des de fora: no el va caçar BazarNube, el van caçar els seus clients. Aquesta és la pitjor manera d'assabentar-se'n, i és exactament la fallada A09 (Fallades de Registre i Monitorització) que vam estudiar a 03-11. En analitzar per què la monitorització no va saltar, l'equip va trobar tres mancances:

La lliçó de 03-11 es materialitza aquí: tenir logs no és monitoritzar. BazarNube registrava els accessos, però ningú no els correlacionava ni hi havia alertes sobre comportament anòmal. Un detector senzill —"un usuari accedeix a més de N comandes per minut"— hauria disparat una alerta el Dia 1, reduint la finestra d'exposició de dotze dies a minuts.

Durant l'anàlisi, l'equip va reconstruir el que l'evidència va deixar veure. Els logs d'accés mostraven, en cru, el patró inconfusible de l'enumeració:

Un mateix user=48213 recorrent IDs consecutius, barrejant 200 (comandes que existeixen) i 404, a ritme de diverses peticions per segon. La dada hi era des del primer minut; el que faltava era una regla que la llegís. Per això la mancança més cara no va ser no tenir logs, sinó no actuar sobre ells. La regla d'alerta que es va afegir a la recuperació s'ancora justament en aquesta senyal.

Una bona anàlisi no s'atura en "hi havia un IDOR"; es pregunta per què va arribar a producció i per què no es va detectar. La tècnica dels cinc perquès ajuda:

1. Per què es van filtrar les dades? Perquè l'endpoint retornava comandes sense comprovar la propietat (IDOR, A01).
2. Per què existia l'IDOR? Perquè l'autorització a nivell d'objecte no era un requisit verificat; es va assumir que "qui té l'ID, té permís".
3. Per què no es va detectar en desenvolupament? Perquè no hi havia revisió de codi amb checklist ni proves d'autorització amb dos usuaris (justament el de 08-01).
4. Per què no va saltar una alerta en explotar-lo? Perquè no hi havia monitorització de comportament anòmal (A09, 03-11).
5. Per què va trigar dotze dies a sortir a la llum? Perquè l'única "detecció" va ser externa: els clients afectats.

La causa arrel no és una sola línia de codi: és l'absència de diversos controls en cadena. L'IDOR va ser la porta; la manca de detecció, la raó que el dany creixés. Corregir només el codi deixaria intacte el segon problema.

Quantificar l'impacte orienta la resposta i les obligacions legals.

Que el pagament estigués tokenitzat (una decisió de disseny del threat model de 07-02) va limitar el dany: no es van filtrar números de targeta. És un exemple concret de com un control aplicat a temps redueix l'impacte d'una fallada en una altra part. La defensa en capes funciona fins i tot quan una capa falla.

L'equip va seguir les fases clàssiques de resposta a incidents (a alt nivell; el detall forense excedeix aquest curs defensiu):

• Contenció (Dia 12, 10:00). Es desactiva l'endpoint /api/comandes/:id (feature flag) per aturar la fuita immediatament, encara que costi trencar una funció. Es revoquen els tokens del compte atacant i es preserven els logs com a evidència. La prioritat és aturar l'hemorràgia, no arreglar bé encara.
• Eradicació (Dia 13). S'implementa i desplega el fix definitiu de BZN-101 (el filtre user_id de 08-02), verificat amb dos usuaris. Es revisa la resta d'endpoints buscant la mateixa classe de fallada (remediar per família).
• Recuperació (Dia 13-14). Es reactiva l'endpoint corregit, es monitoritza de prop, i s'afegeix l'alerta de taxa d'accés a comandes que faltava. Es confirma que l'extracció no continua.
• Notificació (Dia 14). S'informa els afectats i l'autoritat de protecció de dades segons l'obligació legal, amb transparència sobre quines dades i quines mesures s'han pres.

La contenció ràpida i la notificació transparent són tan part de la resposta com el pedaç tècnic. Un bon maneig de l'incident redueix el dany reputacional gairebé tant com evita el tècnic.

El tancament de tot incident és un post-mortem sense culpables que es tradueix en accions concretes. Aquestes són les de BazarNube:

La conclusió del post-mortem va ser incòmoda: l'IDOR ja estava previst com a amenaça al threat model del checkout (07-02, fila "Usuari normal força la comanda d'un altre"), però la mitigació mai no es va implementar ni es va verificar. La fallada no va ser de coneixement, sinó de procés: una amenaça identificada que no es va convertir en un requisit verificat. Aquest és precisament el forat que l'exercici de millora de la lliçó següent es proposa tancar.

• Buscar culpables en lloc de causes. Un post-mortem que assenyala "qui va escriure la línia" no arregla el procés i garanteix que ningú no reporti el pròxim incident. Cultura blameless.
• Quedar-se a la causa tècnica. "Era un IDOR" és només el primer perquè. Sense analitzar per què no es va detectar ni per què va arribar a producció, el següent incident serà igual.
• Confondre contenció amb solució. Desactivar l'endpoint atura la fuita, però no és l'arranjament. Contén ràpid, eradica bé, no confonguis les fases.
• No preservar evidència. Esborrar o rotar logs durant la resposta destrueix la informació per entendre l'abast i per a possibles obligacions legals.
• Consell: mesura sempre el temps de detecció (de l'atac a assabentar-te'n). És la mètrica que més es descuida i la que més redueix el dany quan millora. Un IDOR detectat en minuts filtra desenes de comandes, no desenes de milers.

Exercici 1. Detecció. Dissenya la regla d'alerta més simple que hauria caçat aquest atac el Dia 1. Indica sobre quina senyal opera, el llindar aproximat i per què evita ofegar-se en falsos positius.

Exercici 2. Causa arrel. Aplica els cinc perquès a un incident diferent: es filtren contrasenyes perquè es guardaven en text pla. Arriba almenys fins al quart perquè i proposa el control OWASP de cada nivell.

Exercici 3. Impacte i resposta. Si el pagament no hagués estat tokenitzat i s'haguessin filtrat dades de targeta, què canviaria en l'avaluació d'impacte i en les obligacions de notificació? Enumera tres diferències.

Solució 1. La senyal és el nombre de comandes diferents que un mateix usuari consulta per unitat de temps. Regla: "alertar si un usuari accedeix a més de, p. ex., 50 order_id diferents en 5 minuts". Opera sobre el log d'accés enriquit amb el user_id autenticat. Evita falsos positius perquè un client normal consulta les seves poques comandes, no centenars seqüencials; el llindar es calibra amb el percentil 99 del trànsit legítim. Complement útil: detectar el patró seqüencial d'IDs, encara més específic de l'enumeració.

Solució 2.

1. Per què es van filtrar les contrasenyes? Estaven en text pla a la BD. → Control: hashing amb algorisme lent (bcrypt/Argon2), A02 (03-02).
2. Per què en text pla? No hi havia requisit d'emmagatzematge segur de credencials. → Control: ASVS V2.4 com a criteri d'acceptació (M4).
3. Per què no es va detectar? Cap revisió de codi ni SAST va assenyalar el desat insegur. → Control: revisió + SAST al pipeline (07-03).
4. Per què ningú no ho va prioritzar? L'emmagatzematge de credencials no estava al threat model. → Control: threat modeling del flux d'autenticació (07-02).

Solució 3. Tres diferències: (1) Dades afectades passen a incloure dades financeres, elevant la severitat a crítica i l'impacte potencial (frau directe). (2) Marc regulatori: entren obligacions de PCI-DSS a més de protecció de dades, amb notificació a les marques de targeta i possibles sancions. (3) Resposta: caldria forçar reemissió de targetes i monitorització de frau, un abast i cost molt superiors. Il·lustra per què la tokenització (no emmagatzemar el PAN) és una de les decisions de disseny de major retorn.

Hem analitzat un incident complet de BazarNube: la seva cronologia, la detecció tardana i externa que va delatar una fallada de monitorització tan greu com la mateixa vulnerabilitat, la causa arrel en cadena que els cinc perquès van revelar, l'impacte acotat gràcies a la tokenització, i una resposta ordenada de contenció, eradicació i recuperació. La lliçó de fons és que un incident rarament neix d'una sola fallada: neix d'una amenaça coneguda que el procés no va convertir en control verificat, i d'una detecció que no existia. BazarNube en va sortir amb una llista d'accions i una certesa: necessita madurar la seva seguretat de manera sistemàtica, no a cop d'incident. Això és exactament el que veurem a l'última lliçó del mòdul, 08-04: com l'aplicació passa d'aquest estat reactiu i insegur a un de madur, aplicant de manera integrada tot l'après al curs.