Falsificación de solicitud entre sitios (CSRF)
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 los ataques CSRF.
¿Qué es CSRF?
La falsificación de solicitudes entre sitios (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 tienen la intención de realizar. Permite que un atacante eluda parcialmente la misma política de origen, que está diseñada para evitar que diferentes sitios web interfieran entre sí.
Solicita una cotización del mejor escaner de vulnerabilidades de sitios web y aplicativos expuestos, con precios por anualidad e intercambio de targets, BURP SUITE ENTERPRISE es el único que lo ofrece, cambia YA!
¿Cuál es el impacto de un ataque CSRF?
En un ataque CSRF exitoso, el atacante hace que el usuario víctima realice una acción sin querer. Por ejemplo, esto podría ser cambiar la dirección de correo electrónico en su cuenta, cambiar su contraseña o realizar una transferencia de fondos. Según la naturaleza de la acción, el atacante podría obtener el control total de la cuenta del usuario. Si el usuario comprometido tiene un rol privilegiado dentro de la aplicación, entonces el atacante podría tomar el control total de todos los datos y la funcionalidad de la aplicación.
¿Cómo funciona CSRF?
Para que un ataque CSRF sea posible, deben darse tres condiciones clave:
- Una acción relevante. Hay una acción dentro de la aplicación que el atacante tiene una razón para inducir. Esto podría ser una acción privilegiada (como modificar los permisos de otros usuarios) o cualquier acción sobre datos específicos del usuario (como cambiar la contraseña del usuario).
- Manejo de sesión basado en cookies. Realizar la acción implica emitir una o más solicitudes HTTP, y la aplicación se basa únicamente en las cookies de sesión para identificar al usuario que realizó las solicitudes. No existe ningún otro mecanismo para realizar un seguimiento de las sesiones o validar las solicitudes de los usuarios.
- Sin parámetros de solicitud impredecibles. Las solicitudes que realizan la acción no contienen ningún parámetro cuyos valores el atacante no pueda determinar o adivinar. Por ejemplo, al hacer que un usuario cambie su contraseña, la función no es vulnerable si un atacante necesita saber el valor de la contraseña existente.
Por ejemplo, suponga que una aplicación contiene una función que le permite al usuario cambiar la dirección de correo electrónico en su cuenta. Cuando un usuario realiza esta acción, realiza una solicitud HTTP como la siguiente:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfEemail=wiener@normal-user.com
Esto cumple con las condiciones requeridas para CSRF:
- La acción de cambiar la dirección de correo electrónico en la cuenta de un usuario es de interés para un atacante. Después de esta acción, el atacante normalmente podrá activar un restablecimiento de contraseña y tomar el control total de la cuenta del usuario.
- La aplicación utiliza una cookie de sesión para identificar qué usuario emitió la solicitud. No existen otros tokens o mecanismos para rastrear las sesiones de los usuarios.
- El atacante puede determinar fácilmente los valores de los parámetros de solicitud que se necesitan para realizar la acción.
Con estas condiciones establecidas, el atacante puede construir una página web que contenga el siguiente HTML:
<html>
<body>
<form action="https://vulnerable-website.com/email/change" method="POST">
<input type="hidden" name="email" value="pwned@evil-user.net" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
Si un usuario víctima visita la página web del atacante, ocurrirá lo siguiente:
- La página del atacante activará una solicitud HTTP al sitio web vulnerable.
- Si el usuario ha iniciado sesión en el sitio web vulnerable, su navegador incluirá automáticamente su cookie de sesión en la solicitud (suponiendo que no se estén utilizando las cookies de SameSite ).
- El sitio web vulnerable procesará la solicitud de forma normal, la tratará como si la hubiera realizado el usuario víctima y cambiará su dirección de correo electrónico.
Cómo construir un ataque CSRF
La creación manual del código HTML necesario para un exploit CSRF puede ser engorrosa, especialmente cuando la solicitud deseada contiene una gran cantidad de parámetros o hay otras peculiaridades en la solicitud. La forma más fácil de construir un exploit CSRF es usar el generador CSRF PoC que está integrado en Burp Suite Professional:
- Seleccione una solicitud en cualquier parte de Burp Suite Professional que desee probar o explotar.
- En el menú contextual del botón derecho, seleccione Herramientas de participación / Generar PoC CSRF.
- Burp Suite generará algo de HTML que activará la solicitud seleccionada (menos las cookies, que el navegador de la víctima agregará automáticamente).
- Puede modificar varias opciones en el generador de PoC CSRF para ajustar aspectos del ataque. Es posible que deba hacer esto en algunas situaciones inusuales para lidiar con las características extravagantes de las solicitudes.
- Copie el HTML generado en una página web, visualícelo en un navegador que haya iniciado sesión en el sitio web vulnerable y pruebe si la solicitud prevista se emite correctamente y se produce la acción deseada.
Cómo entregar un exploit CSRF
Los mecanismos de entrega para los ataques de falsificación de solicitudes entre sitios son esencialmente los mismos que para el XSS reflejado . Por lo general, el atacante coloca el HTML malicioso en un sitio web que controla y luego induce a las víctimas a visitar ese sitio web. Esto se puede hacer alimentando al usuario con un enlace al sitio web, a través de un correo electrónico o un mensaje en las redes sociales. O si el ataque se coloca en un sitio web popular (por ejemplo, en un comentario de un usuario), es posible que simplemente esperen a que los usuarios visiten el sitio web.
Tenga en cuenta que algunos exploits CSRF simples emplean el método GET y pueden ser completamente autónomos con una sola URL en el sitio web vulnerable. En esta situación, es posible que el atacante no necesite emplear un sitio externo y puede enviar directamente a las víctimas una URL maliciosa en el dominio vulnerable. En el ejemplo anterior, si la solicitud para cambiar la dirección de correo electrónico se puede realizar con el método GET, entonces un ataque autónomo se vería así:
<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">
Prevención de ataques CSRF
La forma más sólida de defenderse contra los ataques CSRF es incluir un token CSRF dentro de las solicitudes relevantes. La ficha debe ser:
- Impredecible con alta entropía, como para tokens de sesión en general.
- Vinculado a la sesión del usuario.
- Estrictamente validado en todos los casos antes de ejecutar la acción correspondiente.
Una defensa adicional que es parcialmente efectiva contra CSRF y se puede usar junto con tokens CSRF son las cookies de SameSite.
Vulnerabilidades CSRF comunes
Las vulnerabilidades CSRF más interesantes surgen debido a errores cometidos en la validación de tokens CSRF.
En el ejemplo anterior, supongamos que la aplicación ahora incluye un token CSRF dentro de la solicitud para cambiar el correo electrónico del usuario:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLmcsrf=WfF1szMUHhiokx9AHFply5L2xAOfjRkE&email=wiener@normal-user.com
Esto debería evitar los ataques CSRF porque viola las condiciones necesarias para una vulnerabilidad CSRF: la aplicación ya no depende únicamente de las cookies para el manejo de la sesión y la solicitud contiene un parámetro cuyo valor un atacante no puede determinar. Sin embargo, hay varias formas en que se puede romper la defensa, lo que significa que la aplicación sigue siendo vulnerable a CSRF.
La validación del token CSRF depende del método de solicitud
Algunas aplicaciones validan correctamente el token cuando la solicitud utiliza el método POST, pero omiten la validación cuando se utiliza el método GET.
En esta situación, el atacante puede cambiar al método GET para eludir la validación y lanzar un ataque CSRF:
GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
La validación del token CSRF depende de la presencia del token
Algunas aplicaciones validan correctamente el token cuando está presente, pero omiten la validación si se omite el token.
En esta situación, el atacante puede eliminar todo el parámetro que contiene el token (no solo su valor) para eludir la validación y lanzar un ataque CSRF:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
email=pwned@evil-user.net
El token CSRF no está vinculado a la sesión del usuario
Algunas aplicaciones no validan que el token pertenezca a la misma sesión que el usuario que realiza la solicitud. En su lugar, la aplicación mantiene un grupo global de tokens que ha emitido y acepta cualquier token que aparezca en este grupo.
En esta situación, el atacante puede iniciar sesión en la aplicación con su propia cuenta, obtener un token válido y luego enviar ese token al usuario víctima en su ataque CSRF.
El token CSRF está vinculado a una cookie que no es de sesión
En una variación de la vulnerabilidad anterior, algunas aplicaciones vinculan el token CSRF a una cookie, pero no a la misma cookie que se usa para rastrear sesiones. Esto puede ocurrir fácilmente cuando una aplicación emplea dos marcos diferentes, uno para el manejo de sesiones y otro para la protección CSRF, que no están integrados entre sí:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXWF; csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv
csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tY&email=wiener@normal-user.com
Esta situación es más difícil de explotar, pero sigue siendo vulnerable. Si el sitio web contiene algún comportamiento que permite a un atacante establecer una cookie en el navegador de la víctima, entonces es posible un ataque. El atacante puede iniciar sesión en la aplicación con su propia cuenta, obtener un token válido y una cookie asociada, aprovechar el comportamiento de configuración de cookies para colocar su cookie en el navegador de la víctima y enviar su token a la víctima en su ataque CSRF.
Nota
El comportamiento de configuración de cookies ni siquiera necesita existir dentro de la misma aplicación web que la vulnerabilidad CSRF. Cualquier otra aplicación dentro del mismo dominio DNS general puede aprovecharse potencialmente para establecer cookies en la aplicación a la que se dirige, si la cookie que se controla tiene un alcance adecuado. Por ejemplo, staging.demo.normal-website.comse podría aprovechar una función de configuración de cookies para colocar una cookie que se envíe a secure.normal-website.com.
El token CSRF simplemente se duplica en una cookie
En otra variación de la vulnerabilidad anterior, algunas aplicaciones no mantienen ningún registro del lado del servidor de los tokens que se han emitido, sino que duplican cada token dentro de una cookie y un parámetro de solicitud. Cuando se valida la solicitud posterior, la aplicación simplemente verifica que el token enviado en el parámetro de solicitud coincida con el valor enviado en la cookie. Esto a veces se denomina defensa de «doble envío» contra CSRF, y se recomienda porque es simple de implementar y evita la necesidad de cualquier estado del lado del servidor:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa
csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa&email=wiener@normal-user.com
En esta situación, el atacante puede volver a realizar un ataque CSRF si el sitio web contiene alguna funcionalidad de configuración de cookies. Aquí, el atacante no necesita obtener un token válido propio. Simplemente inventan un token (quizás en el formato requerido, si se está verificando), aprovechan el comportamiento de configuración de cookies para colocar su cookie en el navegador de la víctima y alimentan su token a la víctima en su ataque CSRF.
Defensas basadas en referencias contra CSRF
Además de las defensas que emplean tokens CSRF, algunas aplicaciones utilizan el Refererencabezado HTTP para intentar defenderse de los ataques CSRF, normalmente al verificar que la solicitud se originó en el propio dominio de la aplicación. Este enfoque es generalmente menos eficaz y, a menudo, está sujeto a desviaciones.
Encabezado de referencia
El encabezado HTTP Referer (que sin darse cuenta está mal escrito en la especificación HTTP) es un encabezado de solicitud opcional que contiene la URL de la página web vinculada al recurso que se solicita. Por lo general, los navegadores lo agregan automáticamente cuando un usuario activa una solicitud HTTP, incluso al hacer clic en un enlace o enviar un formulario. Existen varios métodos que permiten que la página de enlace retenga o modifique el valor del Refererencabezado. Esto se hace a menudo por razones de privacidad.
La validación de Referer depende de que el encabezado esté presente
Algunas aplicaciones validan el Refererencabezado cuando está presente en las solicitudes, pero omiten la validación si se omite el encabezado.
En esta situación, un atacante puede crear su exploit CSRF de una manera que haga que el navegador del usuario de la víctima suelte el Refererencabezado en la solicitud resultante. Hay varias formas de lograr esto, pero la más fácil es usar una etiqueta META dentro de la página HTML que alberga el ataque CSRF:
Descubre todo tipo de Vulnerabilidades. Con el escáner para sitios y aplicaciones web habilitado para empresas. «BURP SUITE ENTERPRISE»
La validación de Referer se puede eludir
Algunas aplicaciones validan el Refererencabezado de una manera ingenua que se puede omitir. Por ejemplo, si la aplicación valida que el dominio en el Referercomienza con el valor esperado, entonces el atacante puede colocar esto como un subdominio de su propio dominio:
http://vulnerable-website.com.attacker-website.com/csrf-attack
Del mismo modo, si la aplicación simplemente valida que Referercontiene su propio nombre de dominio, el atacante puede colocar el valor requerido en otra parte de la URL:
http://attacker-website.com/csrf-attack?vulnerable-website.com
Nota
Aunque es posible que pueda identificar este comportamiento con Burp, a menudo encontrará que este enfoque ya no funciona cuando prueba su prueba de concepto en un navegador. En un intento por reducir el riesgo de que se filtren datos confidenciales de esta manera, muchos navegadores ahora eliminan la cadena de consulta del Refererencabezado de forma predeterminada.
Puede anular este comportamiento asegurándose de que la respuesta que contiene su exploit tenga el Referrer-Policy: unsafe-urlencabezado establecido (tenga en cuenta que Referrerestá escrito correctamente en este caso, ¡solo para asegurarse de que está prestando atención!). Esto garantiza que se enviará la URL completa, incluida la cadena de consulta.
Si te ha gustado, ¡compártelo con tus amigos!
