La falsificación de solicitudes entre sitios (CSRF / XSRF), también conocida como Sea Surf o Session Riding, es una vulnerabilidad de seguridad web que engaña a un navegador web para que ejecute una acción no deseada. En consecuencia, el atacante abusa de la confianza que una aplicación web tiene en el navegador de la víctima. Permite a un atacante eludir parcialmente la política del mismo origen, que está destinada a evitar que diferentes sitios web interfieran entre sí.
En esta sección, explicaremos qué es la falsificación de solicitudes entre sitios, describiremos algunos ejemplos de vulnerabilidades CSRF comunes y explicaremos cómo prevenir ataques CSRF.
Indice
¿Qué es CSRF?
Cross-Site Request Forgery (también conocida como CSRF) es una vulnerabilidad de seguridad web que permite a un atacante inducir a los usuarios a realizar acciones que no pretenden realizar. Permite a un atacante eludir parcialmente la misma política de origen, que está diseñada para evitar que diferentes sitios web interfieran entre sí.
Los ataques de falsificación de solicitudes entre sitios (CSRF) son vulnerabilidades comunes de aplicaciones web que se aprovechan de la confianza que un sitio web ya ha otorgado a un usuario y su navegador. En un ataque CSRF, un atacante suele utilizar técnicas de ingeniería social para manipular a un usuario autenticado para que ejecute acciones maliciosas sin su conocimiento o consentimiento.
Simplemente haciendo clic en un enlace aparentemente legítimo en un correo electrónico o mensaje de chat, el usuario puede, sin saberlo, darle a un atacante la capacidad de apropiarse de su identidad y privilegios de acceso.
A partir de ese momento, el atacante puede hacerse pasar por su víctima y usar su cuenta para realizar cualquier cosa, desde una broma inofensiva a un usuario desprevenido hasta una transferencia de dinero ilícita que drena la cuenta bancaria de la víctima. Si el usuario objetivo es un administrador web con amplios privilegios de acceso, un ataque CSRF puede comprometer toda la aplicación web.
Cuando tiene éxito, un ataque CSRF puede ser perjudicial tanto para la empresa que opera el sitio como para el usuario que ha accedido a él. Estos ataques pueden afectar negativamente las relaciones con los clientes, dañar la confianza del cliente y dar lugar a casos de fraude o robo de recursos financieros. Los ataques CSRF se han empleado contra los principales servicios y sitios como Gmail y Facebook, entre otros.
CSRF también se conoce por varios otros nombres, incluidos XSRF, «surf en el mar», sesión de equitación, falsificación de referencias entre sitios y enlaces hostiles. Microsoft se refiere a este tipo de ataque como un ataque de un clic en su proceso de modelado de amenazas y en muchos lugares de su documentación en línea.
¿Cómo funciona?
Cuando los usuarios intentan acceder a un sitio, su navegador a menudo incluye automáticamente las credenciales asociadas con el sitio junto con su solicitud para que el proceso de inicio de sesión sea más conveniente. Estas credenciales pueden incluir la cookie de sesión del usuario, las credenciales de autenticación básicas, la dirección IP, las credenciales de dominio de Windows, etc. Sin embargo, una vez que el usuario está autenticado en el sitio, el sitio no tiene forma de distinguir una solicitud falsificada de una solicitud de usuario legítima.
Al apropiarse de la identidad y el acceso de la víctima a través de un ataque CSRF, un atacante puede hacer que un usuario realice acciones no deseadas. Por lo general, el atacante persuade a la víctima para que haga clic en un enlace utilizando una técnica de ingeniería social a través de un correo electrónico, mensaje de chat o una forma similar de comunicación.
El usuario puede encontrar, sin saberlo, código HTML o JavaScript malicioso en el mensaje de correo electrónico o después de cargar una página del sitio que solicita una URL de tarea específica. Luego, la tarea se ejecuta, ya sea directamente o mediante un error de secuencia de comandos entre sitios. El usuario a menudo no se da cuenta de que ha sucedido algo hasta que se produce una acción maliciosa.
Los ataques CSRF generalmente tienen como objetivo funciones que causan un cambio de estado en el servidor, pero también pueden usarse para acceder a datos confidenciales. Al realizar un ataque CSRF exitoso en la cuenta de una víctima, un actor malintencionado puede iniciar una transferencia de fondos, comprar un artículo, colocar un producto en un carrito de compras, alterar la información de la cuenta, como una dirección de envío, cambiar una contraseña o usar cualquier otra función que está disponible en el sitio web vulnerable.
Existen algunas limitaciones. Para llevar a cabo un ataque CSRF exitoso, considera lo siguiente:
- El éxito de un ataque CSRF depende de la sesión de un usuario con una aplicación vulnerable. El ataque solo tendrá éxito si el usuario está en una sesión activa con la aplicación vulnerable.
- Un atacante debe encontrar una URL válida para crear maliciosamente. La URL debe tener un efecto de cambio de estado en la aplicación de destino.
- Un atacante también necesita encontrar los valores correctos para los parámetros de URL. De lo contrario, la aplicación de destino podría rechazar la solicitud maliciosa.
Impacto de los ataques CSRF
Cuando un sitio web envía una solicitud de datos a otro sitio web en nombre de un usuario junto con la cookie de sesión del usuario, un atacante puede lanzar un ataque de falsificación de solicitud entre sitios, que abusa de una relación de confianza entre el navegador de la víctima y el servidor web.
En algunos casos, dependiendo del tipo de acción, el atacante puede obtener el control total de la cuenta del usuario. Si el usuario comprometido tiene un rol privilegiado dentro de la aplicación, el atacante podría tomar el control total de toda la funcionalidad y los datos de la aplicación, lo cual es devastador tanto para la empresa como para el usuario. El resultado puede ser el robo de datos, transferencias de fondos no autorizadas, relaciones con los clientes dañadas, contraseñas cambiadas y muchos más.
Defectos CSRF almacenados y su impacto
En algunos casos, es posible almacenar un ataque CSRF directamente en el sitio vulnerable. Estas vulnerabilidades se denominan defectos CSRF almacenados. Un atacante puede crear una falla CSRF almacenada simplemente almacenando una etiqueta IMG o IFRAME en un campo que acepte HTML, o realizando un ataque más complejo de secuencias de comandos entre sitios (XSS). El gusano Samy MySpace es un caso notable en el que las técnicas XSS comprometieron un sitio a gran escala.
Si un atacante puede almacenar un ataque CSRF en el sitio de destino, el impacto puede ser mucho más severo. En este caso, dado que la página que contiene la carga maliciosa ahora está contenida dentro del sitio y, por lo tanto, parece completamente legítima, es más probable que la víctima vea y confíe en la página que contiene el ataque que en una página aleatoria en Internet. Y dado que la víctima ya ha sido autenticada en el sitio en este escenario, el atacante tendrá una oportunidad aún mejor de atacarlos con un ataque CSRF.
¿Qué son los tokens CSRF?
Un token CSRF es un valor secreto único e impredecible generado por una aplicación del lado del servidor y enviado al cliente para su inclusión en las solicitudes HTTP posteriores emitidas por el cliente. Después de que se emite el token, cuando el cliente realiza una solicitud, el servidor comprueba si la solicitud contiene el token esperado y lo rechaza si el token falta o no es válido.
Los tokens CSRF pueden prevenir ataques CSRF, porque evitan que los atacantes formen solicitudes HTTP completamente válidas, que pueden enviar a una víctima. El atacante no puede determinar ni predecir el valor del token CSRF del usuario, por lo que la aplicación no debe aceptar ninguna solicitud que genere.
Vulnerabilidades comunes de CSRF
Algunas de las vulnerabilidades CSRF más comunes son causadas por errores en el proceso de verificación del token CSRF. Asegúrate de que tu proceso CSRF no tenga ninguna de estas debilidades.
La validación depende de la presencia del token
En algunas aplicaciones, el proceso de verificación se omite si el token no existe. Esto significa que el atacante solo necesita encontrar código que contenga información del token y eliminarlo, y la aplicación no realiza la validación del token.
El token CSRF no está asociado con la sesión del usuario
Algunas aplicaciones mantienen un grupo de tokens y, siempre que se utilice un token del grupo, se acepta. Sin embargo, la aplicación no vincula tokens específicos a usuarios específicos. Un atacante solo necesita obtener al menos un token del grupo y puede usarlo para hacerse pasar por cualquier usuario.
Cambios en la validación de tokens con el método HTTP
En algunas aplicaciones, el uso del método GET en lugar del método POST hará que la validación CSRF no funcione correctamente. El atacante simplemente necesita cambiar de POST a GET y evitar fácilmente el proceso de verificación.
El token CSRF se copia en la cookie
Algunas aplicaciones no mantienen un registro de los tokens que ya están en uso. En su lugar, copian los parámetros de solicitud asociados con cada token en la cookie del usuario. En esta configuración, el atacante puede crear una cookie que contiene un token utilizando el formato esperado de la aplicación, colocarlo en el navegador del usuario y luego ejecutar un ataque CSRF. La solicitud enviada por el navegador del usuario será validada, porque coincidirá con la cookie maliciosa proporcionada por el atacante.
¿Cómo prevenir ataques CSRF?
Existen varios métodos para fortalecer tu programa de seguridad de aplicaciones web para que sea menos vulnerable a un posible ataque CSRF. Al igual que con otras medidas de seguridad de aplicaciones web, la mejor defensa implica escanear y probar regularmente la seguridad de tus aplicaciones web :
Asegúrate de que tu aplicación web tenga protección CSRF
Si su aplicación web no tiene actualmente protección CSRF, podría ser vulnerable a esta forma de ataque. Las herramientas de seguridad de la aplicación web pueden ayudarlo a determinar rápidamente si existe tal vulnerabilidad dentro de su aplicación web y proporcionarle los pasos necesarios para solucionar el problema.
Utiliza técnicas de validación avanzadas para reducir el CSRF
Puedes ayudar a reducir la probabilidad de un ataque CSRF si cuentas con técnicas de validación avanzadas para cualquier persona que pueda visitar páginas en tu sitio, especialmente si estás operando una red social o un sitio comunitario.
Los tokens CSRF, que a veces también se denominan tokens anti-CSRF ya que están destinados a desviar los ataques CSRF, son un ejemplo. Por lo general, se componen de una cadena de números aleatoria grande que es única tanto para la sesión individual como para el usuario, lo que hace que sea mucho más difícil para los atacantes adivinar el token adecuado requerido para crear una solicitud válida.
Al implementar tokens CSRF en los envíos de formularios y las URL de efectos secundarios, puedes asegurarte de que cada envío o solicitud de formulario esté vinculado a un usuario autenticado y protegido de un posible ataque CSRF. En los casos que involucran operaciones altamente sensibles, OWASP señala que es posible que también desees considerar la implementación de una protección basada en la interacción del usuario (ya sea reautenticación / token único) junto con técnicas de mitigación basadas en token.
Realiza pruebas periódicas de seguridad de aplicaciones web para identificar CSRF
Incluso después de haber resuelto con éxito una vulnerabilidad en una aplicación web que habría habilitado un ataque CSRF, es posible que surjan vulnerabilidades en el futuro a medida que la aplicación se actualiza y se realizan cambios en su código. Por esta razón, es aconsejable escanear y probar continuamente tus aplicaciones web en busca de vulnerabilidades de seguridad que puedan albergar, incluidas las vulnerabilidades asociadas con ataques CSRF, utilizando herramientas de seguridad de aplicaciones web.
Defensa CSRF basada en la interacción del usuario
Generalmente, los mecanismos de defensa que requieren la intervención del usuario pueden afectar negativamente la experiencia del usuario. Sin embargo, en algunos casos, como las transacciones financieras, es apropiado y obligatorio implementar este tipo de técnica. Por ejemplo, puedes agregar un CAPTCHA, que ayuda a validar que de hecho es un usuario humano en lugar de un robot.
Un token de una sola vez también puede garantizar que sea el usuario y no un atacante el que utilice una sesión iniciada. El token se suele enviar a la dirección de correo electrónico o teléfono del usuario, validando con la información proporcionada previamente por el usuario. Además, puedes introducir la reautenticación, que puede ayudar a diferenciar entre una sesión CSRF y un usuario real.
Iniciar sesión CSRF
Muchos desarrolladores ignoran las vulnerabilidades CSRF en el formulario de inicio de sesión de una aplicación. Esto se debe a que el usuario aún no está autenticado en esta etapa, por lo que los desarrolladores asumen que no hay riesgo de CSRF. Sin embargo, esta suposición no siempre es correcta. Los atacantes pueden realizar ataques CSRF de inicio de sesión, que pueden tener diferentes impactos según la aplicación.
Los ataques CSRF de inicio de sesión se pueden mitigar creando una sesión previa (iniciando una sesión antes de la autenticación del usuario) y solicitando el token en el formulario de inicio de sesión.
Es difícil mitigar el CSRF de inicio de sesión si no puede confiar en los subdominios (por ejemplo, si permite que sus usuarios definan sus propios subdominios). En estos casos, puede utilizar una verificación estricta del encabezado de referencia del subdominio y del nivel de ruta para reducir el riesgo de CSRF en los formularios de inicio de sesión.
Atributo de cookie de SameSite
El SameSite atributo de cookie intenta mitigar los ataques CSRF. El atributo le dice al navegador cuándo está bien enviar cookies con solicitudes entre sitios. El SameSiteatributo de cookie viene con tres valores posibles – Strict, Laxo None.
La mayoría de los navegadores móviles y todos los navegadores de escritorio admiten este atributo.
El Strict valor puede indicarle al navegador que no envíe una cookie al sitio durante una sesión de navegación entre sitios. Esto incluye una sesión que sigue un enlace regular. Por ejemplo, cuando un usuario inicia sesión en GitHub y navega por un proyecto privado de GitHub alojado por una corporación, el navegador no envía una cookie de sesión a GitHub, lo que restringe el acceso al proyecto.
Si no es necesario permitir que los sitios externos se vinculen a páginas transaccionales, puedes utilizar la Strict marca. Sin embargo, si necesitas crear un equilibrio entre usabilidad y seguridad, permitiendo que los usuarios dirigidos por enlaces externos mantengan las sesiones registradas, debes usar el Lax valor predeterminado. Generalmente, las solicitudes entre sitios concedidas durante el modo Lax se consideran métodos HTTP seguros.
Aunque los ataques CSRF solo funcionan en usuarios que actualmente están autenticados en un sitio, estos exploits pueden ser devastadores cuando tienen éxito. Un atacante que se ha hecho pasar por un usuario puede proceder a realizar una serie de acciones sin su conocimiento o consentimiento, robar dinero o cometer fraude.
Como resultado, una empresa puede encontrar su reputación seriamente dañada, experimentando una pérdida de la confianza del cliente e incluso enfrentando multas regulatorias en algunos casos. Al implementar de manera proactiva un programa integral de seguridad de aplicaciones, su empresa puede reducir la posibilidad de un ataque de este tipo.