CSRF

CSRF (Cross-Site Request Forgery) es un ataque donde un sitio malicioso hace que el navegador de una víctima emita una solicitud autenticada contra un sitio objetivo, aprovechando las cookies que el navegador adjunta automáticamente.

Ejemplo clásico: ha iniciado sesión en banco.ejemplo.com. Visita evil.ejemplo, que contiene <img src="https://banco.ejemplo.com/transfer?to=atacante&amount=1000" />. Su navegador envía diligentemente la solicitud con sus cookies de sesión bancaria. El banco, incapaz de distinguir el origen legítimo, procesa la transferencia.

Defensas modernas:

• Atributo SameSite en cookies (Lax por defecto en navegadores modernos) — bloquea las cookies en solicitudes POST de origen cruzado.
• Tokens CSRF — tokens aleatorios emitidos por el servidor incluidos en los formularios, verificados al enviar. Estándar de la industria durante décadas.
• Validación de las cabeceras Origin/Referer — defensa en profundidad.
• Autenticación con token Bearer (en cabeceras, no en cookies) — inmune a CSRF por defecto.

Los frameworks modernos (Django, Rails, Spring) incluyen protección CSRF habilitada por defecto. El cambio de cookie a Lax por defecto de 2020 eliminó efectivamente el CSRF para la mayoría de las aplicaciones modernas sin ningún cambio de código.

Ejemplo práctico

Una vulnerabilidad de 2008 en muchos routers domésticos ilustra el ataque clásico. La interfaz de administración del router vivía en http://192.168.1.1/, usaba cookies de autenticación básica y exponía un formulario como POST /apply.cgi?dns=... para cambiar el servidor DNS. Un atacante controlaba un sitio web separado que incluía un formulario invisible de envío automático apuntando a esa URL. Un usuario con sesión iniciada que visitara la página maliciosa haría que su navegador enviara silenciosamente el formulario POST a su router, con las cookies de autenticación adjuntas automáticamente, y el DNS sería reemplazado por el del atacante. Desde la perspectiva del router, cada solicitud parecía legítima. La solución en la que se asentó la industria: añadir un token CSRF por sesión al formulario, validarlo al enviar, y rechazar las solicitudes donde el token falta o es incorrecto. Una segunda solución llegó con las cookies SameSite=Lax en Chrome 80 (2020) — el navegador deja de enviar cookies en POST entre sitios, derrotando el ataque en la capa de cookies independientemente de las comprobaciones del lado del servidor.

Cuándo y por qué importa

CSRF importa siempre que una aplicación autentique usuarios mediante cookies que el navegador adjunta automáticamente — que es la mayoría de las aplicaciones web heredadas y muchas modernas. El error es asumir que “somos una API, CSRF no se aplica”: si la API usa cookies de sesión (en lugar de tokens bearer) y acepta POST codificados en formulario o JSON simple sin preflight, es vulnerable. El segundo error es confiar únicamente en la cabecera Referer — muchos proxies corporativos y herramientas de privacidad la eliminan, rompiendo a usuarios legítimos. El mínimo moderno para una aplicación basada en cookies: configurar SameSite=Lax (o Strict para endpoints sensibles) en todas las cookies de autenticación, validar un token CSRF en cada solicitud que cambie de estado, y rechazar solicitudes con cabeceras Origin no coincidentes en endpoints JSON. Para nuevas APIs, cambie completamente a autenticación con token bearer mediante la cabecera Authorization y la superficie de ataque desaparece. Referencia: OWASP — Falsificación de solicitudes entre sitios.

El patrón de cookie de doble envío: cuando un backend no puede almacenar estado por sesión, el token CSRF puede emitirse mediante una cookie y requerirse que también aparezca en una cabecera de solicitud personalizada. El navegador adjunta automáticamente la cookie en cada solicitud, pero los sitios de origen cruzado no pueden leer su valor para copiarlo en la cabecera — la política del mismo origen bloquea la lectura. El servidor compara los dos y rechaza las discrepancias. Esta es la técnica que la mayoría de los frameworks modernos de aplicaciones de una sola página (Angular, la configuración predeterminada de Axios) usan para la defensa CSRF en APIs JSON.

Por qué CSRF es cada vez más irrelevante: la combinación de los valores predeterminados SameSite=Lax (Chrome 80, 2020), la autenticación con token bearer y el preflight CORS en solicitudes no simples ha reducido la superficie de ataque práctica a los endpoints heredados codificados en formulario que aún dependen de las cookies. Para las nuevas APIs construidas hoy, prescindir por completo de las cookies y usar cabeceras Authorization: Bearer <token> elimina el CSRF sin ceremonias. El ranking de riesgo de OWASP movió CSRF fuera de la lista de los 10 principales en 2017 debido a la generalización de las defensas estructurales. Referencia: Hoja de referencia de prevención de CSRF de OWASP.