¿Qué es la falsificación de solicitud entre sitios?

¿Qué es la falsificación de solicitud entre sitios (CSRF)?

Un ataque de falsificación de solicitud entre sitios es un tipo de ciberataque de falsificación* por solicitud que engaña a un usuario para que use accidentalmente sus credenciales para invocar una actividad de cambio de estado, como transferir fondos de su cuenta, cambiar su dirección de correo electrónico y contraseña, o cualquier otra acción no deseada.

Mientras que el impacto potencial que puede tener contra un usuario normal es importante, un ataque CSRF exitoso contra una cuenta administrativa puede poner en riesgo un servidor entero, llegando a provocar potencialmente la toma completa de una aplicación web, API u otro servicio.

¿Cómo funciona la falsificación de solicitud entre sitios?

Este ataque se centra en las solicitudes de cambio de estado, que hace referencia al tipo de solicitud que hace que los datos cambien de un valor a otro. Por ejemplo, una solicitud orientada podría realizar una compra o cambiar un valor en una cuenta. Curiosamente, se trata de un "ataque ciego", y no devuelve datos al atacante, lo que lo convierte en una mala opción para el robo de datos.

A continuación, se muestra un ejemplo de los 4 pasos de un ataque de falsificación de solicitud entre sitios:

1. Un atacante crea una solicitud falsificada que, al ejecutarse, transferirá 10 000 $ de un banco concreto a la cuenta del atacante.
2. El atacante incrusta la solicitud falsificada en un hipervínculo y la envía en correos electrónicos masivos, y también la incrusta en sitios web.
3. Una víctima hace clic en un correo electrónico o en un enlace de un sitio web puesto por el atacante, lo que hace que la víctima solicite al banco una transferencia de 10 000 dólares $.
4. El servidor del banco recibe la solicitud y, como la víctima está debidamente autorizada, trata la solicitud como legítima y transfiere los fondos.

Los ataques CSRF varían en su metodología, pero suelen tener las siguientes características:

1. Se aprovechan de los sitios web que dependen de la identidad del usuario
2. Engañan al navegador del usuario para que envíe solicitudes HTTP al sitio atacado
3. Implican el uso de solicitudes HTTP que tienen efectos secundarios y no cuentan con las protecciones CSRF adecuadas

Los diferentes verbos HTTP tienen una vulnerabilidad variable a los ataques CSRF, lo que da lugar a estrategias de protección variables. Esto se debe a que los navegadores web manejan los verbos de forma diferente.

Las peticiones HTTP GET tienen parámetros incrustados, como los que hay dentro de las etiquetas de imagen, que se pueden manipular y aprovechar. Normalmente, las peticiones GET no modifican el estado, lo que las hace ineficaces como objetivos de CSRF para una aplicación web u otro recurso correctamente implementado.

El HTTP POST se utiliza para cambiar de estado, lo que aumenta la necesidad de protección. Con este fin, los navegadores web implementan medidas de seguridad denominadas política de mismo origen (SOP) e intercambio de recursos de origen cruzado (CORS), que incluye la política de seguridad de origen cruzado. La SOP solo permite las solicitudes del mismo origen y la CORS que ciertos tipos de solicitudes provengan de un origen diferente. La combinación de estas implementaciones ayuda a prevenir los ataques CSRF (entre otros) al limitar la capacidad de una solicitud o página web para interactuar con un origen diferente.

Otros verbos HTTP, como PUT y DELETE, solo pueden ejecutarse mediante SOP y CORS, lo que mitiga muchos ataques entre sitios.

Aunque no es habitual, algunos sitios web desactivan explícitamente estas medidas de seguridad, y también es posible desactivarlas en un navegador web.

¿Cómo se puede mitigar la falsificación de solicitude entre sitios?

La metodología más común para mitigar los ataques CSRF implica el uso de tokens Anti-CSRF utilizando uno de dos métodos. Aunque las implementaciones de los tokens son ligeramente diferentes, el principio subyacente sigue siendo el mismo; al crear y luego comparar una cadena de tokens generada aleatoriamente, es menos probable que un atacante pueda realizar un ataque sin una suposición extremadamente improbable.

Patrón de token de sincronización:

Cuando un usuario visita una página web, como la del banco que permite la transferencia de fondos, el sitio web del banco incorpora un token aleatorio en el formulario. Cuando el usuario envía el formulario, se devuelve el token aleatorio y el banco puede comprobar si los dos tokens coinciden. Si los tokens coinciden, se produce la transferencia. El atacante no tiene forma de acceder al valor del token aleatorio creado en la página web, y si solicita la página, la misma política de origen impediría al atacante leer la respuesta.

El inconveniente de este método de mitigación es que aumenta la carga del lado del servidor para comprobar la validez de los tokens con cada solicitud. También puede crear problemas si un usuario tiene varias ventanas del navegador u otras condiciones que impliquen que un software diferente realice la solicitud. Al ampliar el alcance del token para que sea por sesión en lugar de por solicitud, se puede evitar parte de esta dificultad.

Token de cookie a encabezado:

Otro método consiste en enviar una cookie al navegador del visitante que contenga un token aleatorio. El JavaScript que opera en el lado del cliente leerá el valor del token en la cookie y lo copiará en un encabezado HTTP que se enviará con cada solicitud. Si el usuario envía una solicitud auténtica, el servidor podrá verificar el valor del encabezado. Cualquier otra instancia fallará, lo que mitigará un ataque exitoso.

Mediante el uso de reglas personalizadas a través de un WAF, los usuarios pueden ayudar a prevenir ciertos ataques CSRF. Explorar el Firewall de aplicaciones web de Cloudflare.

*Problema de falsificación por solicitud

Una falsificación por solicitud hace referencia a un programa informático al que se le engaña que haga un mal uso de su autoridad. El riesgo asociado a este tipo de vulnerabilidad es la razón por la que la seguridad basada en las capacidades ayuda a reducir los riesgos asociados al uso indebido. Por ejemplo, cuando se instala un software, la mayoría de los ordenadores actuales requieren que el usuario inicie sesión. Esto ayuda a evitar que se ejecute código involuntariamente cuando el usuario utiliza accidentalmente su autoridad para autorizar una instalación.