Qué es CSRF - Funcionamiento y medidas contra Cross-Site Request Forgery

Qué es CSRF (Cross-Site Request Forgery)

CSRF (Cross-Site Request Forgery) es una técnica de ataque que hace que el navegador del usuario envíe solicitudes no intencionadas a un sitio web donde el usuario está autenticado. El atacante prepara una página web o correo trampa, y en el momento en que la víctima lo visualiza, se envía automáticamente una solicitud fraudulenta desde el navegador de la víctima al sitio objetivo.

El navegador adjunta automáticamente las cookies asociadas al dominio de destino, sin importar en qué página se haya originado la solicitud, por lo que si la víctima ha iniciado sesión, la solicitud del atacante también se procesa como autenticada. Las operaciones que modifican el estado, como cambios de contraseña, transferencias, cambios de dirección de correo y compras, son los objetivos del ataque.

Funcionamiento del ataque y ejemplos concretos

Los ataques CSRF se ejecutan siguiendo este flujo.

La víctima inicia sesión en el sitio objetivo (por ejemplo, banca en línea) y la cookie de sesión se almacena en el navegador.
La víctima visualiza la página trampa preparada por el atacante (enlace en correo, publicación en foro, etc.).
El HTML o JavaScript incrustado en la página trampa envía una solicitud desde el navegador de la víctima al sitio objetivo.
El navegador adjunta automáticamente la cookie de sesión, por lo que el sitio objetivo la procesa como una solicitud legítima.

Por ejemplo, si la función de transferencia está diseñada de modo que POST /transfer reciba el destinatario y el importe desde el cuerpo de la solicitud, el atacante solo necesita incrustar un formulario de envío automático en la página trampa para ejecutar una transferencia desde la cuenta de la víctima. Si el formulario se coloca en un iframe fuera de la pantalla y se envía con JavaScript, la víctima no percibe que la operación ha ocurrido.

Se confunde fácilmente con XSS, pero CSRF no ejecuta el script del atacante en el navegador de la víctima, sino que falsifica solicitudes legítimas desde el navegador de la víctima, lo cual es fundamentalmente diferente.

Implementación de medidas de defensa

El núcleo de las medidas contra CSRF es implementar un mecanismo que verifique que la solicitud se basa en la intención del usuario legítimo.

Token CSRF

El servidor genera un token aleatorio al mostrar el formulario y lo incrusta en un campo hidden. Al enviar el formulario, se verifica la coincidencia del token, rechazando las solicitudes falsificadas desde sitios externos. Este método se denomina patrón de token de sincronización (Synchronizer Token Pattern): el token es único por sesión y, por la política de mismo origen, el JavaScript de sitios externos no puede leerlo. Sin embargo, si existe XSS el propio token puede ser robado, por lo que los tokens CSRF solo funcionan combinados con medidas contra XSS. Si no desea mantener el token en el servidor, el patrón de cookie de doble envío, que coloca un valor firmado tanto en la cookie como en la solicitud y compara ambos, sirve como alternativa.

Atributo SameSite de cookies

Configurando el atributo SameSite de las cookies, se puede controlar la adjunción de cookies en solicitudes cross-site.

SameSite=Strict: No adjunta cookies en ninguna solicitud desde sitios externos. Es lo más seguro, pero el estado de sesión no se mantiene al acceder desde enlaces externos.
SameSite=Lax: Solo adjunta cookies en solicitudes GET de navegación de nivel superior (clics en enlaces). No se adjuntan en solicitudes POST, por lo que puede prevenir muchos ataques CSRF. No obstante, cuando el atributo no se especifica y el navegador aplica Lax como valor predeterminado, el trato es más permisivo y sí se adjuntan cookies en solicitudes POST realizadas dentro de los dos minutos posteriores a la emisión de la cookie.
SameSite=None: Adjunta cookies también en solicitudes cross-site. Requiere combinarse con el atributo Secure.

El atributo SameSite es eficaz como defensa en profundidad, pero por sí solo no constituye una medida contra CSRF. La condición de mismo sitio se evalúa por dominio registrable, de modo que una cookie emitida por app.example.com se considera del mismo sitio incluso en solicitudes procedentes de other.example.com, y el secuestro de un subdominio o el contenido de terceros en un dominio compartido se convierten en vías de evasión. También siguen existiendo cookies que deben especificar SameSite=None para integraciones con servicios externos, así como navegadores antiguos y navegadores integrados donde el valor predeterminado no se aplica, por lo que conviene combinarlo siempre con la verificación de tokens.

Otras medidas

Verificación de encabezados Origin / Referer: Confirmar que el origen de la solicitud es el propio sitio. Sin embargo, el Referer puede no enviarse debido a configuraciones de privacidad o proxies.
Requerimiento de encabezados personalizados: Como los formularios HTML no pueden añadir encabezados arbitrarios, exigir un encabezado propio como X-Requested-With permite rechazar las solicitudes falsificadas enviadas mediante formularios. Añadir ese encabezado desde JavaScript cross-site requiere un preflight de CORS, pero esta defensa no se sostiene si se amplían los orígenes permitidos mientras Access-Control-Allow-Credentials está habilitado, por lo que la lista de orígenes permitidos debe reducirse al mínimo.
Reparto de funciones con los encabezados de seguridad: CSP y X-Frame-Options no son mecanismos que detengan el CSRF en sí. Conviene defenderse del CSRF con las condiciones de adjunción de cookies y la verificación del origen de la solicitud, y diseñar los encabezados de seguridad como el medio de cerrar las vías distintas del XSS y el clickjacking.

Protección CSRF integrada en los frameworks

Muchos frameworks web de servidor proporcionan protección CSRF integrada.

Django: CsrfViewMiddleware está habilitado de forma predeterminada y verifica el token que incrusta la etiqueta de plantilla {% csrf_token %}. Sobre HTTPS también compara el encabezado Origin con CSRF_TRUSTED_ORIGINS, por lo que cubre los ataques que llegan a través de subdominios.
Ruby on Rails: En las aplicaciones recién creadas config.action_controller.default_protect_from_forgery está habilitado, por lo que los tokens CSRF se generan y verifican automáticamente. Para indicarlo de forma explícita, se escribe protect_from_forgery with: :exception.
Spring Security: La protección CSRF se aplica de forma predeterminada a los métodos HTTP no seguros, como POST. Al usar la integración con Thymeleaf o JSP, CsrfToken se inserta automáticamente en los formularios.
Next.js / SPA: En las rutas API que usan autenticación por cookies, combinar cookies SameSite con la verificación del encabezado Origin. También considerar protección adicional con WAF.

Si desactiva la protección CSRF del framework, verifique que las medidas alternativas estén implementadas de forma segura. Si excluye la protección CSRF en endpoints API, la premisa es cambiar a autenticación por token (Bearer Token) y no usar autenticación basada en cookies.

Para obtener más información sobre este tema, consulte Encabezados de seguridad HTTP - 5 encabezados esenciales para proteger tu sitio web.

Conceptos erróneos comunes

CSRF no ocurre con solicitudes GET: Si se implementan operaciones que modifican el estado (eliminación, cambio de configuración, etc.) con solicitudes GET, también son objetivo de CSRF. Se puede enviar una solicitud GET simplemente configurando una URL en el atributo src de una etiqueta img, por lo que los cambios de estado deben implementarse siempre con POST/PUT/DELETE. Aunque <code>SameSite=Lax</code> se haya convertido en el valor predeterminado, Lax permite el paso de GET al considerarlo un método seguro, por lo que las implementaciones que modifican el estado mediante GET no quedan protegidas por el valor predeterminado del navegador.
Si se usa HTTPS, se puede prevenir CSRF: HTTPS proporciona cifrado de comunicación y prevención de alteración, pero no tiene relación con CSRF. CSRF es un ataque que envía solicitudes legítimas desde el navegador del usuario legítimo, y el ataque funciona incluso si la comunicación está cifrada.

CSRF (Cross-Site Request Forgery)