CSRF significa falsificación de solicitud entre sitios. Permite que un atacante elabore una solicitud manipulada a través de un correo electrónico o por otros medios y, por lo tanto, realice acciones de cambio de estado en sitios web en los que actualmente está autenticado como usted mismo. La intención de CSRF no es leer datos confidenciales, sino escribir o realizar cambios en sus datos para beneficio de los atacantes.
Un escenario de ejemplo de CSRF
Por ejemplo, ha iniciado sesión en su sitio web de banca neta https://mybank.com. La URL de solicitud para realizar una transferencia de fondos en su aplicación de banca neta parece,
https://mybank.com/transferFunds.do?beneficiary=Siva&amount=500
El atacante quiere transferir su dinero a su cuenta. Así que elabora un correo electrónico con el siguiente contenido HTML,
<img src=’https://mybank.com/transferFunds.do?beneficiary=Attacker&amount=50000′ height=’0px’ width=’0px’ alt=’Logotipo no disponible’>
Cuando abre este correo electrónico, se realiza una llamada desde su navegador donde inicia sesión en su cuenta bancaria neta para transferir fondos a la cuenta del atacante. Por lo tanto, con solo abrir el correo electrónico, se debita su cuenta ya que ya ha iniciado sesión en el sitio web del banco. La imagen puede verse rota y mostrar texto alternativo, pero el atacante logra lo que esperaba: realizar una acción de cuenta de débito que cambia el estado en su sitio web bancario.
Dado que el atacante puede crear y enviarle la solicitud que se ejecuta en su navegador, el atacante no tiene forma de leer los datos que son específicos de su cuenta. La intención principal de CSRF es realizar acciones de escritura.
Mecanismos de protección CSRF convencionales
Dado que CSRF es una vulnerabilidad grave, existen múltiples mecanismos de protección que se han probado hasta ahora.
- Uso del método POST en lugar de GET: existe la idea errónea de que solo el método GET es vulnerable a los ataques CSRF. Es posible enviar un enlace de formulario HTML controlado por JavaScript a un usuario que, cuando se abre, se envía automáticamente al sitio web de destino utilizando el método POST usando JavaScript. Entonces, el método no es una protección viable contra el ataque CSRF.
- Token anti-CSRF: para cada enlace generado por un sitio web, el sitio también agrega un token Anti-CSRF en el parámetro de solicitud o en los encabezados de solicitud. Este debe ser un hash criptográfico fuerte que un atacante no debe poder predecir o manipular. El sitio también estableció este hash en su cookie de respuesta. Solo si el parámetro que contiene el token CSRF coincide con la cookie CSRF, la solicitud podrá continuar. De lo contrario, la solicitud es fallida. Esta cookie CSRF puede generarse una vez por sesión o una vez por cada solicitud y debe invalidarse inmediatamente. El atacante que elabora y le envía la solicitud no tendría idea de cuál es la cookie CSRF para la sesión/solicitud actual. Por lo tanto, todas las acciones de cambio de estado con la protección de cookies CSRF arruinarán los intentos de ataque CSRF.
Atributo del mismo sitio
Para cada cookie asociada con cualquier sitio web, es posible establecer un atributo denominado SameSite. Esto se introduce para proteger un sitio web contra ataques CSRF. Sin usar una cookie separada para proteger un sitio web contra el ataque CSRF, el atributo SameSite se puede configurar como una cookie de sesión de un sitio web que indica si la cookie que autoriza a un usuario a ingresar a un sitio web debe enviarse o no solo cuando el enlace proviene del mismo sitio web. , sitio web de terceros, etc., este atributo controla este comportamiento de paso de cookies.
Resolviendo problemas de CSRF con la cookie de SameSite
Dado que es un problema común para todos los sitios web y cada sitio web debe mantener un mecanismo para generar, pasar e invalidar el token CSRF, Chrome ahora presenta la cookie SameSite que básicamente tiene como objetivo la protección CSRF.
Casi todos los sitios utilizan un mecanismo de autenticación de usuario basado en cookies. Una vez que un usuario inicia sesión en un sitio web con sus credenciales, el sitio web establece una cookie en la sesión del navegador. Esto se utiliza para responder a más requests del usuario a este sitio en particular sin tener que iniciar sesión nuevamente. Esta cookie se denomina cookie de sesión. Usando uno de los siguientes valores en el atributo SameSite de una cookie de sesión, un sitio web puede protegerse del ataque CSRF.
Todas las cookies configuradas en un dominio pueden tener asociado un valor de atributo de cookie de SameSite. La cookie de SameSite puede tomar uno de los siguientes valores,
SameSite : strict
Cookies configuradas con SameSite: estricto deshabilitará el envío de cookies a todos los sitios web de terceros. Las cookies se enviarán solo si el dominio es el mismo que la ruta para la que se configuró la cookie.
SameSite : none
Cookies configuradas con SameSite: ninguna deshabilitará la protección basada en SameSite. El sitio web puede utilizar sus propios mecanismos de protección CSRF.
SameSite : Lax
Cookies configuradas con SameSite: Lax permitirá que se envíen cookies solo para la navegación de nivel superior. Cuando no agregó el atributo SameSite, Lax se considera como un comportamiento predeterminado.
Por lo tanto, si configura una cookie de sesión con SameSite: estricto, incluso en ausencia de una cookie CSRF dedicada, los enlaces generados a su sitio web desde sitios web de terceros no tendrán cookies de sesión. Por lo tanto, no es posible realizar ataques CSRF en ellos.
Se está volviendo cada vez más común ya que todos los navegadores modernos están considerando implementar este comportamiento para proteger a sus usuarios de los ataques CSRF.