CSRF - XSRF

web hacking

CSRF, o Falsificación de Solicitudes entre Sitios, es un tipo de ciberataque que induce a un usuario autenticado a ejecutar acciones no deseadas en una aplicación web. Un atacante engaña a la víctima para que visite una página maliciosa, que a su vez envía una solicitud no autorizada a un sitio web en el que el usuario ya está conectado, haciendo que la aplicación ejecute la acción (como transferir dinero o cambiar la contraseña) en nombre del usuario sin su consentimiento.

Formas de CSRF

la formula general del ataque consiste en engañar a la victima para que haga clic en un enlace malicioso, la pagina dentro del enlace contiene una solicitud HTTP la cual realiza o ejecuta una accion no deseada en el sitio web legitimo en contra de la victima (si esta autenticada).

para entenderlo mejor, supongamos que en un usuario inicia sesión en su cuenta bancaria, posterior a eso el usuario visita una pagina web maliciosa la cual envía un formulario HTTP al sitio del banco online para transferir los fondos de la victima a la cuenta del atacante. El ataque de CSRF abre puertas a una amplia variedad de acciones en contra de los usuarios autenticados.

la forma mas básica de CSRF es convertir la petición de la accion deseada a GET (change request method), remueve de la URL parámetros adicionales que puedan no permitir establecer los cambios de forma universal (por ejemplo tokens) y así solo enviar la URL a la victima para que cuando acceda, se ejecuten automáticamente los cambios mediante los parámetros especificados, por ejemplo:

# Cambio de email por POST
email=[e-mail]&token=XXXX

# Desde burpsuite damos click derecho y luego a change request method, los datos ahora se deberian enviar por un parametro en la URL por ejemplo
https://example.com/configuracion?email=[e-mail]&token=XXXX

# Removemos el parametro token ya que es una medida de seguridad que podria frustrar el ataque
https://example.com/configuracion?email=[e-mail]

# si la pagina es vulnerable y el usuario esta autenticado, se ejerce el cambio de correo

la siguiente forma (y la que estaremos utilizando) emplea un servidor a control del atacante donde se encuentra un código HTML parecido al siguiente:

<form id="csrfForm" method="POST" action="https://example.com/endpoint">
  <input type="hidden" name="param1" value="valor1">
  <input type="hidden" name="param2" value="valor2">
  <!-- Añadir más campos si el sitio los requiere -->
</form>
<script>
  document.getElementById("csrfForm").submit();
</script>

Este código HTML envía por POST datos por parámetros al dominio junto al PATH que hayamos especificado, usaremos este bloque de código como base para todas las técnicas que veremos, pues es solo cuestión de modificar los datos y parámetros que estamos enviando hacia el servidor victima. Si quieres encontrar que parámetros se usan al enviar una petición por POST, solo intercéptala por burpsuite y analízala. Es cuestión de editar el formulario acorde a cada situación dependiendo de la cantidad de parámetros que estamos enviando.

Vamos a analizar un ejemplo de como haríamos un CSRF básico mediante el HTML base que estamos utilizando: supongamos que la web victima tiene el endpoint /mi-cuenta/cambiar-correo para como su nombre lo dice, actualizar el correo de la cuenta. Al interceptar la solicitud descubrimos que esta enviando por POST el correo electrónico especificado, por lo que así modificaríamos el HTML base:

<form id="csrfForm" method="POST" action="https://example.com/mi-cuenta/cambiar-correo">
  <input type="hidden" name="email" value="[e-mail]">

</form>
<script>
  document.getElementById("csrfForm").submit();
</script>

cuando la victima acceda a nuestro servidor malicioso, se ejecuta de manera oculta la solicitud hacia la web objetivo, si esta es vulnerable y el usuario esta autenticado el cambio del correo se vera reflejado.

con este ejemplo, ya tenemos una idea de como modificar acorde a lo que necesitamos el HTML base.

• Un token CSRF es un valor único, secreto e impredecible que se genera en el servidor y se comparte con el cliente para proteger las aplicaciones web contra ataques de falsificación de solicitudes entre sitios (CSRF). Este token actúa como una medida de seguridad, donde el servidor verifica su presencia y validez en cada solicitud que realiza cambios de estado en la aplicación, como envío de formularios. Si el token no coincide o falta, la solicitud se rechaza, evitando que acciones no deseadas se ejecuten en nombre del usuario.

CSRF sin validación de token

como vemos el CSRF token es una medida de seguridad bastante útil, pero si no se implementa correctamente se convierte en algo deficiente, en muchas páginas web donde se utiliza esta medida de seguridad entre solicitudes solo es cuestión de enviar la solicitud sin el token incluido (borrarlo), ya que si esta mal implementado el servidor solo verifica si es correcto, pero no si esta presente realmente.

Encontrar un fallo lógico como este nos abre las puertas a construir un ataque CSRF básico al no tener que incluir el token.

Validación vulnerable a method tampering

El method Tampering consiste en cambiar el método HTTP para evadir controles o activar rutas/funcionalidades no pensadas para el cliente.

Para hacer este método de forma POST > GET (post a get) podemos hacerlo de la forma que vimos al principio mediante burpsuite (click derecho y change request method en la solicitud interceptada) o cambiar el formulario HTML base de CSRF:

<form id="csrfForm" method="GET" action="https://example.com/mi-cuenta/cambiar-correo">
  <input type="hidden" name="email" value="[e-mail]">

</form>
<script>
  document.getElementById("csrfForm").submit();
</script>

usamos el mismo ejemplo donde intentamos modificar el email del usuario que accede al servidor atacante.

Tokens CSRF no vinculados al usuario en sesión

hay webs que implementan tokens CSRF los cuales no están ligados a la sesión del usuario, esto significa que cualquier token que pueda ser generado puede ser utilizado por cualquier usuario

Iniciamos sesión con un usuario y capturamos un token CSRF desde la funcionalidad de cambio de correo electrónico (por ejemplo).

• Luego, iniciamos sesión con otro usuario y utilizamos ese token previamente obtenido para enviar una solicitud de cambio de correo.

• El servidor acepta el token aunque no pertenezca a esa sesión, lo que permite realizar el ataque CSRF.

<form id="csrfForm" method="POST" action="https://example.com/mi-cuenta/cambiar-correo">
  <input type="hidden" name="email" value="[e-mail]">
  <input type="hidden" name="csrf" value="token_generado_aqui">
  
</form>
<script>
  document.getElementById("csrfForm").submit();
</script>

como podemos ver aparte del parámetro para el email a actualizar, hemos implementado el token generado por nosotros en una cuenta nuestra. el cual deberia ser correcto acorde a esta vulnerabilidad.

---

SameSite bypass CSRF

• SameSite es un atributo que se puede agregar a las cookies HTTP para ayudar a proteger contra ataques de falsificación de solicitudes entre sitios (CSRF). Permite a los desarrolladores controlar si las cookies deben enviarse en solicitudes entre sitios, mejorando así la seguridad de las aplicaciones web.

  • El atributo SameSite indica al navegador cómo debe tratar las cookies en solicitudes entre sitios. Puede tener los siguientes valores:

    • Strict: Las cookies solo se envían en solicitudes desde el mismo sitio web donde se crearon.

    • Lax: Las cookies se envían en solicitudes GET desde otros sitios, pero no en solicitudes POST ni otras solicitudes que no sean GET desde sitios externos.

    • None: Las cookies se envían en solicitudes de cualquier sitio, pero deben estar marcadas como Secure (es decir, solo se pueden enviar a través de HTTPS).

Si las medidas de SameSite se implementan de forma errónea o insegura, siguen siendo vulnerables a ciertas técnicas de CSRF.

CSRF bypasseando SameSite Lax por Override

• SameSite Lax es un atributo de seguridad para cookies que indica al navegador cómo debe manejarlas en solicitudes entre sitios. Cuando se establece en "Lax", la cookie se envía en solicitudes del mismo sitio y en solicitudes GET de otros sitios, pero no en solicitudes POST o PUT de otros sitios, lo que ayuda a prevenir ataques de falsificación de solicitudes entre sitios (CSRF). También puede ser en viceversa permitiendo solo GET.

para burlar esta medida, se utiliza una técnica conocida como method override consiste en enviar un parámetro especial (_method=POST) en la query para que el servidor trate una petición GET como si fuera POST. por lo que, podemos bypassear errores de "method not allowed" (método no permitido).

en la practica se vería algo asi:

https://example.com
GET /mi-cuenta/cambiar-correo?email=[e-mail]&_method=POST 

primero hay que cambiar el request method de POST a GET desde burpsuite al interceptar la solicitud.