Qué es CSRF y cómo proteger tu aplicación
Autor: Redacción Domeny.ForSale Publicado
En resumen: CSRF es un ataque en el que una página ajena induce al navegador de un usuario que ha iniciado sesión a enviar una solicitud no deseada a otro sitio. Si ese sitio solo comprueba que el usuario tiene la sesión iniciada, puede ejecutar la operación sin su consentimiento consciente. La protección se basa en medidas dentro de la aplicación: tokens CSRF, una configuración adecuada de las cookies y la comprobación del origen de las solicitudes.
Cómo funciona CSRF: ejemplo con el panel de una tienda
CSRF son las siglas de Cross-Site Request Forgery, es decir, falsificación de solicitudes entre sitios. El ataque aprovecha que el navegador puede adjuntar automáticamente la cookie de sesión a las solicitudes dirigidas a un sitio determinado. Esa cookie permite al servidor reconocer al usuario que ha iniciado sesión sin volver a pedirle la contraseña.
Imagina que gestionas una tienda en línea y tienes abierto el panel de administración. En otra pestaña visitas una página preparada por un atacante. Esa página intenta enviar al panel una solicitud para cambiar la dirección de correo electrónico asociada a tu cuenta.
Si el navegador adjunta la cookie de sesión y el panel no comprueba además la autenticidad de la solicitud, el servidor puede interpretarla como una decisión tuya. El atacante no necesita conocer la contraseña ni leer la cookie: basta con que el navegador la utilice al enviar la solicitud.
Es como si alguien presentara una orden para su ejecución con tu sello adjuntado automáticamente. El sistema reconoce el sello, pero no comprueba si realmente quieres realizar esa operación concreta.
Cuándo puede tener éxito el ataque y qué no lo impide
Un ataque CSRF típico requiere varias condiciones: el usuario tiene una sesión activa, el navegador envía automáticamente las credenciales y la aplicación acepta una solicitud predecible que modifica el estado de la cuenta. Puede tratarse de cambiar datos, añadir un usuario o eliminar una entrada. Las consecuencias dependen de las operaciones disponibles y de los permisos de la víctima.
Por lo general, el atacante no necesita leer la respuesta del servidor. El navegador puede impedir que la página ajena lea los datos del panel, pero aun así permitir el envío de determinadas solicitudes. Por eso, la política del mismo origen, que limita el acceso de los scripts a recursos de otros orígenes, no sustituye la protección frente a CSRF.
HTTPS tampoco resuelve este problema. Cifra la conexión y protege los datos en tránsito, pero no confirma que el usuario haya ordenado conscientemente la operación. Tampoco basta con utilizar el método POST en lugar de GET: una página ajena puede enviar un formulario POST convencional.
CSRF no es lo mismo que XSS. XSS consiste en ejecutar código no deseado en el contexto de un sitio de confianza, mientras que CSRF aprovecha la confianza del sitio en las solicitudes procedentes del navegador del usuario. Sin embargo, una vulnerabilidad XSS puede comprometer las defensas frente a CSRF, por ejemplo, al permitir leer el token.
Cómo proteger una aplicación frente a CSRF
El punto de partida más seguro es la protección integrada en el framework que utilices. Debes activarla y asegurarte de que abarque todas las operaciones que modifican datos, no solo el formulario de inicio de sesión.
- Valida el token CSRF. Es un valor impredecible que la aplicación incluye en el formulario o proporciona para que se envíe en la cabecera correspondiente. El servidor lo comprueba antes de ejecutar la operación. En una variante habitual, el token está vinculado a la sesión; una página ajena no debería poder leerlo ni adivinarlo. El token no debe incluirse en la URL.
- Configura el atributo SameSite de la cookie de sesión. Este atributo limita el envío de la cookie en contextos entre sitios. Las opciones Lax y Strict ofrecen distintos niveles de restricción, por lo que debes comprobar cómo afecta la opción elegida al inicio de sesión y a las integraciones. SameSite es una capa de protección, no un sustituto del token válido en todos los casos.
- Comprueba el origen de la solicitud. La cabecera Origin, y también Referer en un mecanismo diseñado adecuadamente, ayudan a determinar de dónde procede la solicitud. Compara ese origen con una lista de direcciones permitidas definidas con precisión, en lugar de buscar únicamente un fragmento del nombre de dominio.
- No modifiques datos mediante GET. Abrir un enlace no debería eliminar una cuenta ni confirmar un pedido. Las operaciones que modifican datos deben utilizar los métodos adecuados y seguir sometiéndose a la comprobación CSRF.
Para las acciones especialmente sensibles, exige una nueva autenticación o una confirmación independiente. Las cookies de sesión también deben tener configurados adecuadamente los atributos Secure y HttpOnly, aunque ninguno de ellos evita por sí solo los ataques CSRF.
¿Una API también necesita protección?
Una API, es decir, una interfaz que permite la comunicación entre programas, también puede ser vulnerable a CSRF si utiliza una sesión autenticada mediante una cookie. El simple hecho de responder en formato JSON no garantiza la seguridad.
Cuando el cliente añade explícitamente un token de acceso en la cabecera Authorization y el navegador no lo adjunta automáticamente, el mecanismo típico de CSRF no suele ser aplicable. Sin embargo, esto no implica inmunidad frente al robo del token o a XSS. CORS, el mecanismo que regula el acceso entre orígenes, tampoco constituye por sí solo una protección frente a CSRF.
Qué comprobar en tu propio sitio
Empieza por una operación, por ejemplo, el cambio de dirección de correo electrónico. Con una cuenta de prueba, en tu propio entorno o con permiso del propietario, comprueba que una solicitud sin token CSRF o con un token incorrecto se rechaza y realmente no modifica los datos. Después, revisa la configuración de la cookie y las demás vías que permiten ejecutar la misma operación.
Si utilizas un sistema ya desarrollado, confirma cómo funciona su protección en la documentación oficial de la versión que usas y de las extensiones instaladas. Como usuario, no puedes corregir la falta de medidas de seguridad del servidor; puedes reducir el riesgo cerrando la sesión cuando termines de trabajar en un panel con funciones sensibles. Como propietario de la aplicación, empieza por revisar las operaciones que modifican datos: en ellas es necesario comprobar que la solicitud procede realmente de una interfaz autorizada.
Consulta también: ¿Qué significa www?
Lee también
