CSRF: Qué es, cómo funciona y cómo proteger tu sitio web

CSRF (Cross-Site Request Forgery) es una vulnerabilidad que permite que el navegador de un usuario autenticado realice acciones en un sitio web sin su consentimiento explícito. El atacante no necesita conocer la contraseña, interceptar la sesión ni acceder directamente a la cuenta; basta con aprovechar el hecho de que el navegador ya considera que el usuario está autenticado.

¿Qué es un ataque CSRF y por qué puede ocurrir?

CSRF explicado en términos sencillos

Un ataque CSRF explota la situación en la que el usuario ya inició sesión en un sitio web y el navegador almacena los datos de su sesión. Por ejemplo, una persona accede a una tienda online o panel corporativo y permanece autenticada. Mientras la sesión siga activa, el navegador continúa enviando las credenciales automáticamente en cada solicitud al sitio.

Si durante ese periodo el usuario abre una página maliciosa, hace clic en un enlace peligroso o carga un elemento de otro dominio, el navegador puede enviar una solicitud al servicio donde ya está autenticado. El usuario puede ni siquiera notar que se está realizando una acción.

El riesgo surge cuando el servidor solo verifica que exista una sesión activa, pero no comprueba que la solicitud haya sido realmente iniciada por el usuario desde la interfaz legítima del sitio.

De forma resumida, la secuencia es: el usuario inicia sesión, obtiene una sesión activa, luego visita una página externa que inicia una solicitud al servicio objetivo. El navegador adjunta las credenciales, y el servidor interpreta la acción como legítima.

¿Qué significa Cross-Site Request Forgery?

El término completo CSRF significa Cross-Site Request Forgery, que suele traducirse como "suplantación de solicitudes entre sitios". El nombre refleja el mecanismo del ataque: la solicitud se genera desde un sitio, pero se dirige a otro haciéndose pasar por un usuario autenticado.

Es fundamental distinguir entre el ataque CSRF y la vulnerabilidad CSRF. El ataque es el intento de forzar al navegador a ejecutar una acción no deseada; la vulnerabilidad es el fallo lógico que permite al servidor aceptar la solicitud sin una verificación adicional.

El navegador, en sí mismo, no actúa de forma incorrecta: simplemente sigue el comportamiento estándar de enviar cookies y datos asociados al dominio según las políticas de seguridad. El problema radica en el lado de la aplicación, si considera suficiente la existencia de una sesión activa como prueba de que el usuario inició la acción.

Por eso, el CSRF no implica necesariamente el robo de contraseñas o la toma de control de la cuenta. El atacante aprovecha la autenticación vigente de la víctima para que el navegador ejecute una acción legítima, pero en un momento inoportuno.

¿Cómo funciona un ataque CSRF? Del sitio malicioso a la solicitud en nombre del usuario

¿Por qué el navegador envía cookies automáticamente?

Cuando el usuario inicia sesión, el sitio crea una sesión y la vincula con el navegador mediante una cookie. En futuras solicitudes al mismo dominio, el navegador adjunta automáticamente la cookie, evitando que el usuario deba introducir sus credenciales cada vez.

Esto es lo que explota el ataque CSRF. Una página externa puede intentar iniciar una solicitud al sitio donde el usuario ya está autenticado. Si el navegador permite enviar las cookies de sesión, el servidor verá la autenticación activa y podría aceptar la solicitud como válida.

El problema clave es que la existencia de la cookie prueba la sesión, pero no demuestra que el usuario desee realizar esa acción. Si la aplicación no implementa verificaciones adicionales, el atacante podría explotar la brecha entre autenticación y confirmación de intención.

Ejemplo de ataque CSRF

Imagina un servicio donde el usuario autenticado puede modificar la configuración de su cuenta. Si el servidor acepta solicitudes de cambio solo en base a la sesión activa, una página externa podría intentar enviar la misma solicitud.

El usuario simplemente visita un sitio ajeno, mientras el navegador interactúa en segundo plano con el servicio objetivo. Para el servidor, la solicitud parece provenir del cliente autenticado.

El atacante no necesariamente accede a la respuesta del servidor ni al contenido de la cuenta. El objetivo clásico del CSRF no es leer datos, sino forzar al sistema a ejecutar acciones en nombre de la víctima.

¿Qué acciones son especialmente peligrosas?

Las solicitudes más críticas son aquellas que modifican el estado del sistema: cambios de datos de contacto, ajustes de seguridad, parámetros del perfil o acciones en paneles administrativos.

El riesgo es mayor si estas operaciones no requieren confirmación adicional y se ejecutan inmediatamente tras recibir la solicitud. Cuanto más privilegios tenga el usuario, mayor será el posible impacto: el daño potencial de un CSRF en una cuenta estándar y en una cuenta de administrador es muy diferente.

Por eso, las operaciones sensibles deben comprobarse no solo por la sesión activa. El servidor necesita un indicio adicional de que la solicitud fue generada por la interfaz confiable e iniciada por el propio usuario.

CSRF token: cómo el sitio distingue una solicitud legítima de una falsa

¿Qué es un CSRF token?

Un CSRF token es un valor adicional que el servidor espera recibir junto con solicitudes sensibles. Normalmente, se genera para el usuario, la sesión o un formulario concreto y se inserta en la página donde se realiza la acción.

Cuando el usuario envía el formulario o cambia ajustes a través de la interfaz habitual, el navegador reenvía el token al servidor. Este compara el valor recibido con el esperado y solo ejecuta la operación si la comprobación es satisfactoria.

Gracias a esto, una sesión activa ya no es suficiente. Aunque el navegador adjunte la cookie, si la solicitud carece de un CSRF token válido, será rechazada.

¿Por qué el atacante no puede simplemente enviar el token correcto?

Un sitio externo no debe tener acceso libre al contenido de la página de otro dominio. Puede intentar iniciar una solicitud, pero normalmente no puede leer el CSRF token de un formulario legítimo ni incluirlo en la solicitud falsificada.

Aquí radica la diferencia clave con las cookies. Las cookies de sesión suelen enviarse automáticamente por el navegador según la configuración, pero el token CSRF debe ser incluido explícitamente por la aplicación.

Si el valor del token es impredecible y el servidor lo verifica antes de ejecutar la acción, la falsificación se vuelve mucho más difícil. El simple hecho de estar autenticado ya no es suficiente.

Otras formas de protección contra CSRF

La configuración de las cookies también puede aportar protección adicional. El atributo SameSite limita el envío de cookies en escenarios cross-site, reduciendo la probabilidad de que una página externa explote la sesión activa del usuario.

El servidor también puede comprobar las cabeceras Origin o Referer para identificar el origen de la solicitud. Estas comprobaciones son útiles como una capa extra de seguridad, especialmente en operaciones reservadas a la interfaz del propio servicio.

Para acciones muy sensibles, se emplea la reconfirmación de identidad: por ejemplo, solicitar la contraseña nuevamente, un código de un solo uso o una confirmación expresa de la operación. Así, incluso con sesión activa y un intento de falsificación, no se ejecutará la acción crítica automáticamente.

CSRF y XSS: diferencias entre ataques

CSRF explota la confianza del sitio en el navegador

En un ataque CSRF, el atacante aprovecha la autenticación existente del usuario. El navegador puede enviar una solicitud acompañada de las cookies de sesión y el servidor la aceptará como legítima.

La característica principal del CSRF es que el código malicioso no tiene por qué ejecutarse dentro del propio sitio objetivo. El ataque puede iniciarse en una página externa que fuerza al navegador a contactar otro servicio en nombre del usuario.

XSS explota la confianza del usuario en el sitio

XSS (Cross-Site Scripting) funciona de forma distinta. El problema surge cuando el sitio permite la inserción y ejecución de JavaScript ajeno dentro de su propia página.

Si este script se ejecuta, accede a las funcionalidades que el navegador permite al código de ese sitio. Según el tipo de vulnerabilidad, puede modificar el contenido, interceptar acciones del usuario o enviar solicitudes en su nombre.

En el CSRF, el atacante no suele acceder al contenido de la página objetivo; su objetivo es enviar una solicitud concreta. En XSS, el código malicioso se ejecuta dentro del sitio de confianza, ampliando enormemente el alcance del ataque.

¿Por qué protegerse de un ataque no cubre al otro?

Los CSRF token protegen frente a la suplantación de solicitudes desde sitios externos, pero no resuelven el XSS. Si el atacante logra ejecutar JavaScript en la aplicación vulnerable, dicho script podría interactuar con la interfaz y los mecanismos de protección.

Lo contrario también es cierto: filtrar datos, escapar entradas y aplicar Content Security Policy protege del XSS, pero no sustituye la verificación de los tokens CSRF ni la configuración de SameSite en las cookies.

Por eso, CSRF y XSS pertenecen a categorías diferentes de vulnerabilidades web. Pueden tener consecuencias similares, como ejecutar acciones en nombre del usuario, pero emplean mecanismos distintos y requieren protecciones específicas.

Cómo proteger tu sitio frente a ataques CSRF

Verifica todas las solicitudes que modifican datos

La protección contra CSRF empieza con la lógica correcta de la aplicación web. Las solicitudes que alteran datos o el estado del sistema no deben ejecutarse solo por recibir una cookie de sesión válida.

Es fundamental evitar el uso de solicitudes GET para operaciones que impliquen cambios. GET debe emplearse solo para obtener información. Cambios de configuración, eliminaciones, transacciones y demás acciones deben realizarse mediante métodos como POST, PUT, PATCH o DELETE junto con una comprobación extra.

Sin embargo, elegir el método HTTP adecuado no basta. Si el servidor solo confía en la sesión activa, la vulnerabilidad puede persistir. Por tanto, las solicitudes sensibles deben contener una comprobación de origen o un valor de confirmación.

Utiliza CSRF tokens y cookies SameSite

Una de las principales defensas son los CSRF tokens. El servidor genera un valor impredecible y lo espera en cada solicitud sensible. Una página externa no puede conocer el token, por lo que aunque haya sesión activa, la solicitud será rechazada.

El atributo SameSite en las cookies añade otra capa de protección. Limita la transferencia de cookies en escenarios cross-site y reduce la probabilidad de que el navegador adjunte credenciales a solicitudes iniciadas en otros sitios.

Los CSRF tokens y las cookies SameSite no son excluyentes, sino complementarios. El token valida la legitimidad de la solicitud, mientras que SameSite restringe el envío automático de cookies entre sitios.

CSRF es solo una de las muchas vulnerabilidades web. Por ejemplo, en una inyección SQL, el atacante apunta a las consultas a la base de datos, no al navegador del usuario. Puedes aprender más en el artículo SQL-inyección: qué es, riesgos y cómo proteger tus bases de datos.

Comprobaciones adicionales para operaciones críticas

Para acciones especialmente importantes, la comprobación del CSRF token puede no ser suficiente. Cambios de contraseña, añadir métodos de recuperación o gestionar privilegios podrían requerir una reconfirmación de identidad.

Esto puede incluir la reintroducción de la contraseña, el uso de un código de un solo uso o la confirmación expresa de la acción. Así se reduce el riesgo de que una solicitud accidental o manipulada cause cambios graves en la cuenta.

El servidor también puede analizar las cabeceras Origin y Referer para identificar la procedencia de la solicitud y rechazar aquellas de fuentes no previstas. Sin embargo, estas comprobaciones funcionan mejor como capa extra que como única defensa.

Una protección robusta se basa en varios niveles: uso correcto de métodos HTTP, CSRF tokens, cookies SameSite, verificación de origen y confirmación adicional en acciones críticas.

Conclusión

El ataque CSRF no explota el robo de contraseñas, sino la confianza del sitio en el navegador ya autenticado. Si el usuario ha iniciado sesión y el servidor considera que la sesión activa es suficiente para aceptar cualquier acción, una página externa puede intentar iniciar solicitudes en su nombre.

La protección principal se basa en los CSRF tokens, que permiten al servidor validar que la solicitud proviene de la aplicación. Además, se recomienda aplicar cookies SameSite, comprobar las cabeceras Origin y Referer, emplear los métodos HTTP adecuados y requerir reconfirmación en operaciones críticas.

Para el desarrollador, la regla clave es sencilla: una sesión activa no basta para asumir que el usuario inició la solicitud. Si la aplicación modifica datos, el servidor debe verificar de forma independiente la legitimidad de esa acción.