Los dos ejercicios anteriores trabajaron en el escenario ideal: encontramos las vulnerabilidades y las corregimos antes de que causaran daño. La realidad no siempre concede ese margen. En este caso de estudio damos un paso atrás en el tiempo hasta un momento en que BazarNube aún no había hecho ese trabajo, y una de las vulnerabilidades del curso —el IDOR de pedidos, BZN-101— seguía viva en producción. El resultado fue un incidente de fuga de datos personales. Tu papel aquí no es el de desarrollador que corrige, sino el de analista que investiga: reconstruir qué pasó, cómo se detectó, por qué ocurrió y qué habría que cambiar para que no se repita. Aplicaremos el logging y la monitorización de 03-11, la clasificación del Top Ten y el marco de respuesta a incidentes, todo sobre una narrativa concreta. Al final tendrás no solo el relato del incidente, sino el método para analizar cualquier otro.

1. La narrativa del incidente
2. Línea de tiempo de los hechos
3. Cómo se detectó: el papel del logging y la monitorización
4. Análisis de causa raíz
5. Evaluación del impacto
6. Respuesta al incidente: contención, erradicación y recuperación
7. Lecciones aprendidas y controles OWASP que lo habrían evitado
8. Errores comunes y consejos
9. Ejercicios
10. Conclusión

Contexto. Es un martes por la mañana. Lucía recibe un aviso de soporte: varios clientes se quejan de correos de marketing de un competidor que mencionan pedidos recientes que hicieron en BazarNube, con detalle de productos y direcciones. Alguien tiene datos que no debería tener. La SRE confirma que no ha habido acceso a la base de datos ni credenciales filtradas conocidas. El equipo abre un incidente de seguridad.

El endpoint GET /api/orders/:id devolvía cualquier pedido a cualquier usuario autenticado, sin comprobar la propiedad (el IDOR BZN-101 que remediamos en 08-02). Un atacante creó una cuenta legítima de cliente, obtuvo un token válido y enumeró los identificadores de pedido de forma secuencial (/api/orders/1, /2, /3...), descargando los datos de decenas de miles de pedidos ajenos: nombre, dirección, productos y correo. No hubo "hackeo" sofisticado ni malware: solo un fallo de autorización explotado con un script y paciencia.

Reconstruir la cronología es el primer entregable de cualquier análisis. Combina lo que dicen los logs de acceso, los de aplicación y los avisos externos.

Dos hechos saltan a la vista: la extracción duró cuatro días y la detección tardó una semana más, y no llegó por un sistema propio, sino por las quejas de los clientes. Ese retraso es, en sí mismo, un segundo hallazgo tan grave como el IDOR.

El incidente se detectó tarde y por fuera: no lo cazó BazarNube, lo cazaron sus clientes. Esa es la peor forma de enterarse, y es exactamente el fallo A09 (Fallos de Registro y Monitorización) que estudiamos en 03-11. Al analizar por qué la monitorización no saltó, el equipo encontró tres carencias:

La lección de 03-11 se materializa aquí: tener logs no es monitorizar. BazarNube registraba los accesos, pero nadie los correlacionaba ni había alertas sobre comportamiento anómalo. Un detector sencillo —"un usuario accede a más de N pedidos por minuto"— habría disparado una alerta el Día 1, reduciendo la ventana de exposición de doce días a minutos.

Durante el análisis, el equipo reconstruyó lo que la evidencia dejó ver. Los logs de acceso mostraban, en crudo, el patrón inconfundible de la enumeración:

Un mismo user=48213 recorriendo IDs consecutivos, mezclando 200 (pedidos que existen) y 404, a ritmo de varias peticiones por segundo. El dato estaba ahí desde el primer minuto; lo que faltaba era una regla que lo leyera. Por eso la carencia más cara no fue no tener logs, sino no actuar sobre ellos. La regla de alerta que se añadió en la recuperación se apoya justo en esta señal.

Un buen análisis no se detiene en "había un IDOR"; pregunta por qué llegó a producción y por qué no se detectó. La técnica de los cinco porqués ayuda:

1. ¿Por qué se filtraron los datos? Porque el endpoint devolvía pedidos sin comprobar la propiedad (IDOR, A01).
2. ¿Por qué existía el IDOR? Porque la autorización a nivel de objeto no era un requisito verificado; se asumió que "quien tiene el ID, tiene permiso".
3. ¿Por qué no se detectó en desarrollo? Porque no había revisión de código con checklist ni pruebas de autorización con dos usuarios (justo lo de 08-01).
4. ¿Por qué no saltó una alerta al explotarlo? Porque no había monitorización de comportamiento anómalo (A09, 03-11).
5. ¿Por qué tardó doce días en salir a la luz? Porque la única "detección" fue externa: los clientes afectados.

La causa raíz no es una sola línea de código: es la ausencia de varios controles en cadena. El IDOR fue la puerta; la falta de detección, la razón de que el daño creciera. Corregir solo el código dejaría intacto el segundo problema.

Cuantificar el impacto orienta la respuesta y las obligaciones legales.

Que el pago estuviera tokenizado (una decisión de diseño del threat model de 07-02) limitó el daño: no se filtraron números de tarjeta. Es un ejemplo concreto de cómo un control aplicado a tiempo reduce el impacto de un fallo en otra parte. La defensa en capas funciona incluso cuando una capa falla.

El equipo siguió las fases clásicas de respuesta a incidentes (a alto nivel; el detalle forense excede este curso defensivo):

• Contención (Día 12, 10:00). Se desactiva el endpoint /api/orders/:id (feature flag) para detener la fuga inmediatamente, aun a costa de romper una función. Se revocan los tokens de la cuenta atacante y se preservan los logs como evidencia. La prioridad es parar la hemorragia, no arreglar bien todavía.
• Erradicación (Día 13). Se implementa y despliega el fix definitivo de BZN-101 (el filtro user_id de 08-02), verificado con dos usuarios. Se revisa el resto de endpoints en busca de la misma clase de fallo (remediar por familia).
• Recuperación (Día 13-14). Se reactiva el endpoint corregido, se monitoriza de cerca, y se añade la alerta de tasa de acceso a pedidos que faltaba. Se confirma que la extracción no continúa.
• Notificación (Día 14). Se informa a los afectados y a la autoridad de protección de datos según la obligación legal, con transparencia sobre qué datos y qué medidas se han tomado.

La contención rápida y la notificación transparente son tan parte de la respuesta como el parche técnico. Un buen manejo del incidente reduce el daño reputacional casi tanto como evita el técnico.

El cierre de todo incidente es un post-mortem sin culpables que se traduce en acciones concretas. Estas son las de BazarNube:

La conclusión del post-mortem fue incómoda: el IDOR ya estaba previsto como amenaza en el threat model del checkout (07-02, fila "Usuario normal fuerza el pedido de otro"), pero la mitigación nunca se implementó ni se verificó. El fallo no fue de conocimiento, sino de proceso: una amenaza identificada que no se convirtió en un requisito verificado. Ese es precisamente el hueco que el ejercicio de mejora de la próxima lección se propone cerrar.

• Buscar culpables en vez de causas. Un post-mortem que señala a "quien escribió la línea" no arregla el proceso y garantiza que nadie reporte el próximo incidente. Cultura blameless.
• Quedarse en la causa técnica. "Era un IDOR" es solo el primer porqué. Sin analizar por qué no se detectó ni por qué llegó a producción, el siguiente incidente será igual.
• Confundir contención con solución. Desactivar el endpoint para la fuga, pero no es el arreglo. Contén rápido, erradica bien, no confundas las fases.
• No preservar evidencia. Borrar o rotar logs durante la respuesta destruye la información para entender el alcance y para posibles obligaciones legales.
• Consejo: mide siempre el tiempo de detección (del ataque a que te enteras). Es la métrica que más se descuida y la que más reduce el daño cuando mejora. Un IDOR detectado en minutos filtra decenas de pedidos, no decenas de miles.

Ejercicio 1. Detección. Diseña la regla de alerta más simple que habría cazado este ataque el Día 1. Indica sobre qué señal opera, el umbral aproximado y por qué evita ahogarse en falsos positivos.

Ejercicio 2. Causa raíz. Aplica los cinco porqués a un incidente distinto: se filtran contraseñas porque se guardaban en texto plano. Llega al menos hasta el cuarto porqué y propón el control OWASP de cada nivel.

Ejercicio 3. Impacto y respuesta. Si el pago no hubiera estado tokenizado y se hubieran filtrado datos de tarjeta, ¿qué cambiaría en la evaluación de impacto y en las obligaciones de notificación? Enumera tres diferencias.

Solución 1. La señal es el número de pedidos distintos que un mismo usuario consulta por unidad de tiempo. Regla: "alertar si un usuario accede a más de, p. ej., 50 order_id diferentes en 5 minutos". Opera sobre el log de acceso enriquecido con el user_id autenticado. Evita falsos positivos porque un cliente normal consulta sus pocos pedidos, no cientos secuenciales; el umbral se calibra con el percentil 99 del tráfico legítimo. Complemento útil: detectar el patrón secuencial de IDs, aún más específico de la enumeración.

Solución 2.

1. ¿Por qué se filtraron las contraseñas? Estaban en texto plano en la BD. → Control: hashing con algoritmo lento (bcrypt/Argon2), A02 (03-02).
2. ¿Por qué en texto plano? No había requisito de almacenamiento seguro de credenciales. → Control: ASVS V2.4 como criterio de aceptación (M4).
3. ¿Por qué no se detectó? Ninguna revisión de código ni SAST señaló el guardado inseguro. → Control: revisión + SAST en el pipeline (07-03).
4. ¿Por qué nadie lo priorizó? El almacenamiento de credenciales no estaba en el threat model. → Control: threat modeling del flujo de autenticación (07-02).

Solución 3. Tres diferencias: (1) Datos afectados pasan a incluir datos financieros, elevando la severidad a crítica y el impacto potencial (fraude directo). (2) Marco regulatorio: entran obligaciones de PCI-DSS además de protección de datos, con notificación a las marcas de tarjeta y posibles sanciones. (3) Respuesta: habría que forzar reemisión de tarjetas y monitorización de fraude, un alcance y coste muy superiores. Ilustra por qué la tokenización (no almacenar el PAN) es una de las decisiones de diseño de mayor retorno.

Hemos analizado un incidente completo de BazarNube: su cronología, la detección tardía y externa que delató un fallo de monitorización tan grave como la propia vulnerabilidad, la causa raíz en cadena que los cinco porqués revelaron, el impacto acotado gracias a la tokenización, y una respuesta ordenada de contención, erradicación y recuperación. La lección de fondo es que un incidente rara vez nace de un solo fallo: nace de una amenaza conocida que el proceso no convirtió en control verificado, y de una detección que no existía. BazarNube salió de esto con una lista de acciones y una certeza: necesita madurar su seguridad de forma sistemática, no a golpe de incidente. Eso es exactamente lo que veremos en la última lección del módulo, 08-04: cómo la aplicación pasa de este estado reactivo e inseguro a uno maduro, aplicando de forma integrada todo lo aprendido en el curso.