Parte: 4 — Seguridad de aplicaciones web · Fuente: The Web Application Hacker's Handbook (Stuttard & Pinto) ⏱️ Duración estimada: 90 min · Nivel: Intermedio
Entender el CSRF (falsificación de petición entre sitios): forzar al navegador de una víctima autenticada a ejecutar acciones no deseadas. Aprenderás a construir PoCs, evaluar cuándo una defensa es efectiva y por qué SameSite y los tokens anti-CSRF funcionan.
⚠️ Ética: solo en labs propios/autorizados. Un PoC de CSRF ejecuta acciones reales sobre la cuenta de la víctima.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Cómo funciona el CSRF | Base del ataque |
| 2 | Condiciones necesarias | Cuándo es explotable |
| 3 | PoC con formularios auto-enviados | Construcción del exploit |
| 4 | Tokens anti-CSRF | Defensa clásica |
| 5 | Cookies SameSite | Defensa moderna del navegador |
| 6 | Bypass de defensas débiles | Realidad de las apps |
| 7 | CSRF en APIs JSON | Matices con Content-Type |
Lax/Strict mitigan gran parte del CSRF.⚠️ Solo en labs propios.
<form action="http://dvwa.local/vulnerabilities/csrf/" method="POST">
<input type="hidden" name="password_new" value="hacked">
<input type="hidden" name="password_conf" value="hacked">
<input type="hidden" name="Change" value="Change">
</form>
<script>document.forms[0].submit()</script>
SameSite=Lax en el ataque.SameSite=Strict puede romper flujos legítimos.Content-Type: application/json es CSRF-eable.Resuelve un lab de CSRF de PortSwigger que tenga una defensa parcial (token mal validado) y demuestra el cambio de email de la víctima. Criterio de aceptación: el lab queda resuelto, entregas el PoC funcional y explicas exactamente qué debilidad del token permitió el bypass y cómo se corrige.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| El PoC no dispara la acción | Falta el token válido; el endpoint sí lo valida |
| SameSite bloquea el ataque | Cookie Lax/Strict; el CSRF clásico ya no aplica |
| POST JSON no explotable | El navegador no envía JSON cross-site sin CORS |
| Token estático reutilizable | Debilidad real; repórtalo |
| Referer/Origin bloquean | La app valida origen; busca otro vector |
❓ ¿SameSite mató el CSRF?
Lo redujo mucho, pero no del todo: hay SameSite=None, flujos GET sensibles y navegadores/configuraciones variados. Mantén tokens.
❓ ¿Las APIs REST necesitan protección CSRF? Si autentican por cookie, sí. Si usan tokens en cabecera (Bearer), el CSRF clásico no aplica.
❓ ¿Un token en URL sirve? Es riesgoso: se filtra por Referer, logs e historial. Mejor en cuerpo o cabecera.
Clase 097 — XSS almacenado y basado en DOM