SameSite Strict bypass via client-side redirect
Laboratorio de Portswigger sobre CSRF
Certificaciones
- eWPT
- eWPTXv2
- OSWE
- BSCP
Descripción
Este laboratorio tiene una función de cambio de correo electrónico vulnerable a CSRF. Para resolver el laboratorio, debemos realizar un ataque CSRF que cambie la dirección de correo electrónico del víctima. Debemos utilizar el servidor de explotación proporcionado para alojar nuestro ataque. Podemos iniciar sesión en nuestra cuenta utilizando las credenciales wiener:peter
Guía de CSRF
Antes de completar este laboratorio es recomendable leerse esta guía de CSRF https://justice-reaper.github.io/posts/CSRF-Guide/
Resolución
Al acceder a la web vemos esto
Pulsamos sobre My account y nos logueamos con las credenciales wiener:peter
Vemos que hay un botón para cambiar el email
Podemos hacer comentarios en los posts
Si nos dirigimos a la extensión Logger ++ de Burpsuite vemos que al loguearnos se nos setea una cookie con el atributo SameSite=Strict
Si nos abrimos las herramientas de desarrollador vemos que la cookie tiene como atributo Strict. Si una cookie se establece con el atributo SameSite=Strict, los navegadores no la enviarán en ninguna solicitud entre sitios web. Esto significa que si el sitio objetivo de la solicitud no coincide con el sitio web que se muestra actualmente en la URL del navegador no se incluirá la cookie. Esto se recomienda cuando se configuran cookies que permiten al usuario modificar datos o realizar acciones sensibles, como acceder a páginas que solo están disponibles para usuarios autenticados
Sin embargo, es posible eludir esta limitación si conseguimos encontrar un gadget que genere una solicitud secundaria dentro del mismo sitio web. Un gadget es una redirección en el lado del cliente que construye dinámicamente el objetivo de la redirección utilizando una entrada controlada por el atacante, como los parámetros de la URL. Para más ejemplos, podemos consultar los materiales de Portswigger sobre DOM-based open redirection https://portswigger.net/web-security/dom-based/open-redirection
En cuanto a los navegadores, estas redirecciones en el lado del cliente no se consideran realmente redirecciones. La solicitud resultante se trata como una solicitud ordinaria e independiente. Lo más importante es que se trata de una solicitud dentro del mismo sitio web, así que incluirá todas las cookies relacionadas con el sitio web, sin importar las restricciones que estén en su lugar
Si conseguimos manipular este gadget para generar una solicitud secundaria maliciosa, esto nos permitirá eludir completamente las restricciones de las cookies SameSite. El gadget en este laboratorio lo podemos encontrar si miramos la peticiones que se hacen cuando comentamos en un post
Aquí podemos ver el archivo .js al que se está llamando
Vemos que no hay ningún tipo de sanitización por lo que podemos hacer un Path Traversal. Lo podemos comprobar accediendo https://0abf000e03b6d56382bab34000cd00ca.web-security-academy.net/post/comment/confirmation?postId=8, pasados tres segundos nos redirigirá a https://0abf000e03b6d56382bab34000cd00ca.web-security-academy.net/post/8, pero si accedemos a https://0abf000e03b6d56382bab34000cd00ca.web-security-academy.net/post/comment/confirmation?postId=8/../ nos redirige a https://0abf000e03b6d56382bab34000cd00ca.web-security-academy.net/post/comment/confirmation?postId=8/../. Una vez comprobado esto, el siguiente inspeccionar la forma en la que se envía el formulario para cambiar el correo electrónico
Comprobamos que podemos cambiar el correo electrónico a través del método GET, para ello capturamos la petición con Burpsuite y hacemos click derecho > Change request method
Podemos generar un CSRF PoC haciendo click derecho > Engagements tools > Generate CSRF PoC pero en este caso no va a ser funcional porque no podemos enviar ningún formulario debido a que el atributo de la cookie SameSite es Strict
En mi caso prefiero crear los payload manualmente así que nos dirigimos al Exploit server y nos crafteamos un payload
1
2
3
4
5
6
7
<html>
<body>
<script>
document.location = 'https://0abf000e03b6d56382bab34000cd00ca.web-security-academy.net/post/comment/confirmation?postId=8/../../my-account/change-email?email=testing%40gmail.com%26submit=1';
</script>
</body>
</html>
Si pulsamos en View exploit vemos como nos cambia el email, para completar el laboratorio debemos pegar el payload en el Exploit server y pulsar sobre Delivery exploit to victim. Debemos tener en cuenta que dos usuarios no pueden tener el mismo email, por lo tanto, debemos cambiar nuestro email o cambiar el email en el payload que enviamos
