Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) engaña al navegador de un usuario autenticado para que realice solicitudes no autorizadas a una aplicación web. El navegador envía automáticamente las cookies con las solicitudes, por lo que el servidor no puede distinguir entre solicitudes legítimas y falsificadas sin medidas adicionales.

Escenario:

1. La víctima ha iniciado sesión en bank.com (cookie de sesión en el navegador)
2. La víctima visita la página del atacante con: <img src="https://bank.com/transfer?to=attacker&amount=1000">
3. El navegador envía la solicitud GET con la cookie de bank.com adjunta
4. El banco procesa la transferencia

El CSRF mediante POST requiere un formulario:

La principal defensa es un token CSRF: un valor aleatorio, secreto y específico de la sesión (o de la solicitud) que se inserta en los formularios. El servidor valida el token en cada solicitud que cambia el estado. Un atacante de otro dominio no puede leer el token (política del mismo origen).

SameSite=Strict: la cookie no se envía con ninguna solicitud entre sitios. SameSite=Lax: la cookie se envía con navegaciones seguras de nivel superior (enlaces), pero no con solicitudes POST desde otros sitios. Los navegadores modernos utilizan Lax de forma predeterminada, lo que reduce significativamente el riesgo de CSRF.

Una alternativa al almacenamiento de tokens en el servidor: establezca una cookie CSRF aleatoria y exija que también se envíe como parámetro de la solicitud. Un atacante no puede leer la cookie (mismo origen), por lo que no puede hacerla coincidir en los datos del formulario.

En las solicitudes AJAX, exigir un encabezado personalizado (por ejemplo, X-Requested-With: XMLHttpRequest) proporciona protección contra CSRF porque los navegadores impiden que los scripts entre orígenes establezcan encabezados arbitrarios (CORS lo impone).

Los tokens CSRF fallan si:

• Existe XSS: el atacante puede leer el token mediante JavaScript
• El token se filtra en la URL (encabezado Referer)
• El token es predecible o se reutiliza
• CORS está configurado incorrectamente para permitir el origen del atacante

Pasos de prueba:

1. Identifique las solicitudes que cambian el estado (POST, PUT, DELETE)
2. Elimine o modifique el token CSRF y vuelva a enviar la solicitud
3. Diseñe un envío de formulario entre orígenes y compruebe si tiene éxito
4. Verifique el atributo SameSite en las cookies de sesión

Las API REST que utilizan JSON suelen estar exentas de CSRF si:

• Exigen Content-Type: application/json (los formularios HTML no pueden establecerlo)
• Utilizan autenticación basada en tokens (encabezado Authorization, no cookies)

Pero las API que aceptan cookies aún deben implementar protección contra CSRF.

Con SameSite=Lax como valor predeterminado en Chrome, Firefox y Safari, muchos ataques CSRF tradicionales quedan bloqueados. Sin embargo, los ataques desde subdominios y ciertos patrones de navegación aún pueden eludir Lax. Combine SameSite con tokens CSRF para obtener una defensa sólida.

¿Cuál es la principal defensa contra los ataques CSRF en las aplicaciones web?

CSRF aprovecha el envío automático de cookies por parte del navegador para falsificar solicitudes autenticadas desde sitios maliciosos. Defensa principal: tokens CSRF validados en el servidor. Defensa secundaria: atributo de cookie SameSite=Strict/Lax. Las API que utilizan autenticación mediante tokens en encabezados (no cookies) son naturalmente resistentes al CSRF. Combine las defensas; XSS puede eludir los tokens CSRF si está presente.