CSRF — Cross-Site Request Forgery

Resumen

CSRF ocurre cuando un atacante logra que el navegador de una víctima haga un request no deseado a un sitio donde la víctima está autenticada. Si estás logueado en tu banco y visitás un sitio malicioso, ese sitio puede hacer un POST a tubanco.com/transferir con los parámetros que el atacante quiere, y tu banco procesa el request con tus credenciales.

La defensa estándar es el token CSRF: un valor aleatorio que el servidor genera, incluye en el formulario y verifica al recibir el POST. Como el atacante no puede leer la respuesta del banco (same-origin policy), no puede obtener el token. Frameworks modernos como Django, Rails y Laravel incluyen protección CSRF por defecto.

Alcance y supuestos

Cubre CSRF, sus vectores y defensas. Asume familiaridad con HTTP y cookies.

Modelo mental

Alguien que te sigue después de que sacaste plata del cajero y te distrae mientras un cómplice mete tu tarjeta en otro cajero. El cajero confía en la tarjeta aunque la persona que la usa no seas vos.

Uso práctico

• ✅ Todo formulario que modifica estado debe tener token CSRF.
• ❌ APIs que usan tokens Bearer en headers —no basadas en cookies— son inmunes a CSRF tradicional.

Ejemplo trabajado: CSRF en un banco

La víctima está logueada en banco.com. Visita foro-gratis.com que tiene un form oculto: <form action='banco.com/transferir' method='POST'><input name='destino' value='atacante'><input name='monto' value='10000'></form>. Si el banco no valida token CSRF, el navegador envía las cookies de sesión y la transferencia se ejecuta.

Evidencia

• OWASP mantiene una guía de prevención de CSRF. Frameworks modernos incluyen protección por defecto.