¿Qué es el cross site request forgery? Guía completa para desarrolladores y responsables

¿Qué es el cross site request forgery? Es un tipo de ataque web que obliga a un navegador autenticado a ejecutar acciones no autorizadas en una aplicación donde el usuario ya tiene sesión iniciada. Aunque a primera vista parece sencillo, sus consecuencias pueden ser críticas: transferencias bancarias, cambios de contraseña o publicaciones no deseadas en cuentas con privilegios.

Definición técnica y un mini-caso ilustrativo

Desde el punto de vista técnico, el cross site request forgery (CSRF) explota la confianza que una aplicación deposita en el navegador del usuario. El atacante no roba credenciales: se aprovecha de que el navegador envía cookies o cabeceras de autenticación automáticamente hacia un dominio legítimo.

Mini-caso: un usuario con sesión abierta en banca.example.com visita una página maliciosa. Esa página contiene un formulario oculto que envía una petición POST a banca.example.com/transfer con parámetros para mover dinero. Al cargar la página, el formulario se envía automáticamente y la petición lleva las cookies de sesión del usuario, por lo que el servidor la procesa como legítima.

Cómo funciona un ataque CSRF: paso a paso y vectores comunes

Un ataque CSRF típico sigue estos pasos:

• Preparación: el atacante crea contenido alojado en otro dominio (página, imagen, petición fetch desde un script, etc.).
• Engaño: la víctima visita ese contenido mientras mantiene una sesión activa en la aplicación objetivo.
• Ejecución: el navegador envía automáticamente credenciales (cookies, cabeceras) con la petición maliciosa al servidor vulnerable.
• Resultado: el servidor interpreta la petición como legítima y ejecuta la acción solicitada.

Vectores habituales: formularios auto-submit, etiquetas img apuntando a URLs que ejecutan acciones por GET (práctica insegura), peticiones XHR desde scripts si las políticas CORS están mal configuradas, y enlaces en correos o mensajes con parámetros peligrosos.

Errores de diseño que facilitan CSRF y cómo detectarlos

Algunos fallos de implementación elevan el riesgo de CSRF:

• Usar métodos GET para operaciones que cambian estado. Las peticiones GET deben ser idempotentes y seguras; cualquier acción que modifique datos debe usar POST, PUT o DELETE junto con medidas anti-CSRF.
• No validar el origen de la petición. Ignorar cabeceras Referer o Origin cuando son verificables facilita el ataque.
• Confiar solo en cookies sin mecanismos adicionales. Las cookies se envían automáticamente y no constituyen por sí solas una defensa.
• Ausencia de tokens anti-CSRF en formularios o APIs. Sin token sincronizado no hay forma práctica de distinguir una petición legítima de una forjada.

Detección práctica: revisar logs para peticiones de cambio de estado sin acción de UI correlacionable, pruebas dinámicas con herramientas de seguridad para simular CSRF, y auditorías de código para localizar endpoints que aceptan cambios vía GET o que no requieren tokens.

Estrategias prácticas y comprobadas para prevenir CSRF

Prevenir CSRF requiere combinar medidas en servidor y en cliente. Las más efectivas y aplicables son las siguientes:

1. Tokens sincronizados (synchronizer token pattern): generar un token único por sesión y validarlo con cada petición de modificación. El token suele incluirse en formularios y cabeceras personalizadas.
2. SameSite en cookies: marcar la cookie de sesión con SameSite=Lax o Strict reduce la exposición a envíos automáticos desde otros sitios. Lax es compatible con la mayoría de flujos; Strict es más restrictivo.
3. Verificación de Origin/Referer: aceptar solicitudes de cambio solo si la cabecera Origin o Referer coincide con el dominio esperado. Útil en entornos con navegadores que envían esas cabeceras.
4. Cabeceras personalizadas: exigir una cabecera que solo puede añadirse desde JavaScript en el mismo origen (por ejemplo: X-Requested-By) y validar su presencia. No es infalible, pero complica el ataque.
5. Política CORS estricta: para APIs, permitir solo orígenes concretos y controlar métodos y credenciales de forma explícita.

Al elegir una o varias de estas medidas, considerar el impacto en la experiencia de usuario y en integraciones de terceros. Por ejemplo, SameSite=Strict puede romper algunos flujos de redirección desde emails o servicios externos; elegir Lax con token anti-CSRF suele ser un buen compromiso.

Implementación: patrones, comparación y ejemplos de uso

Patrón sincronizador vs doble submit cookie:

• Synchronizer token pattern: el servidor guarda el token en la sesión y lo compara con el token enviado. Alta seguridad, requiere almacenamiento de sesión.
• Double submit cookie: el servidor verifica que el token enviado en una cabecera o campo coincida con el token presente en una cookie accesible por cliente. Menos dependiente de sesión, pero requiere proteger la cookie y evitar lectura por terceros.

Comparación rápida: si la aplicación ya maneja sesiones en servidor, el token sincronizado suele ser más robusto. Para APIs REST sin sesiones tradicionales, conviene usar tokens en cabeceras junto con políticas CORS y tokens firmados (JWT) que incluyan claims de origen.

Ejemplo de decisión práctica: una aplicación monolítica con formularios HTML se beneficia del token en formulario + SameSite=Lax en la cookie. Una API consumida por SPAs requiere CORS restringido y tokens en Authorization con protección adicional por cabeceras y revocación.

Advertencias técnicas importantes

• No confiar en la ausencia de Referer u Origin: algunos navegadores o filtros de privacidad los eliminan. Diseñar controles en capas.
• Evitar depender exclusivamente de JavaScript del lado cliente: si un usuario puede ejecutar acciones desde UI sin enviar token, la protección falla.
• Probar escenarios de integración: partners que embeberán contenidos, proxies, y clientes móviles pueden necesitar adaptaciones en la estrategia anti-CSRF.

Checklist operativo para mitigar CSRF y cierre accionable

Checklist rápido para equipos de desarrollo y operaciones:

1. Revisar endpoints que modifican estado: asegurar que no aceptan cambios vía GET.
2. Implementar token anti-CSRF para formularios y validarlo siempre en servidor.
3. Configurar SameSite en cookies de sesión; evaluar impacto en flujos legítimos.
4. Verificar cabeceras Origin/Referer cuando sea práctico.
5. Restringir CORS a orígenes concretos y revisar métodos permitidos.
6. Incluir pruebas automatizadas que simulen CSRF en el pipeline de CI.
7. Documentar y comunicar a equipos externos cómo integrarse sin romper protecciones.

En resumen, diseñar defensas contra cross site request forgery exige entender tanto la lógica del navegador como los flujos de negocio. Implementar tokens sincronizados, aplicar SameSite a las cookies y validar el origen de las peticiones forman una estrategia efectiva y pragmática. Revisar regularmente la configuración y añadir pruebas automatizadas reduce el riesgo de que una vulnerabilidad pase desapercibida, y permite mantener la aplicación segura sin afectar la usabilidad.

Para finalizar, cuando se evalúe la seguridad de una aplicación, conviene repetir la pregunta clave: ¿qué es el cross site request forgery? y confirmar que ni el diseño ni las decisiones de implementación permiten que una petición forjada realice cambios en nombre de un usuario legítimo.