CSRF where token validation depends on request method
Laboratorio de Portswigger sobre CSRF
Certificaciones
- eWPT
- eWPTXv2
- OSWE
- BSCP
Descripción
Este laboratorio es vulnerable a un ataque CSRF en la funcionalidad de cambio de correo electrónico. La web intenta bloquear los ataques CSRF, pero solo aplica contramedidas a ciertos tipos de solicitudes. Para resolver este laboratorio, debemos usar nuestro servidor de explotación para alojar una página HTML que lleve a cabo un ataque CSRF para cambiar la dirección de correo electrónico del usuario que visualice el mensaje. Podemos iniciar sesión en nuestra propia 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
Si capturamos la petición de cambiar email con Burpsuite, vemos esto
La forma en que se transmiten los tokens tiene un impacto significativo en la seguridad de un mecanismo en su conjunto. En algunos casos, las 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. Si hacemos click derecho > Change request method, podemos cambiar el método por el que se envía la petición
Al enviar la petición, vemos que nos la toma como válida
Si nos dirigimos a nuestro perfil, vemos que nos ha cambiado el email correctamente
Una vez hemos comprobado que acepta el método GET, tenemos que ver si podemos saltarnos la validación del token CSRF si enviamos la petición usando este método
Mandamos la petición y es aceptada, por lo tanto, podemos confirmar que no se está validando el token CSRF si la petición la mandamos por el método GET
Confirmamos que ha sido tramitada exitosamente accediendo a nuestro perfil
Si inspeccionamos el código, vemos cómo se envía el formulario. Podemos usar este formulario como modelo para construir nuestro propio payload
Si contamos Burpsuite Professional podemos capturar una petición y pulsar click derecho > Engagement tools > Generate CSRF PoC para que nos genere un payload
Se nos genera este payload, aunque es funcional, en la mayoría de ocasiones vamos a tener que retocarlo un poco para mejorar su desempeño
En mi caso prefiero construir el payload de forma manual, como la solicitud va por GET, no tenemos que añadir el atributo method=GET porque es el método de envío por defecto. Una vez creado, debemos pegar el paylod en el Exploit server
1
2
3
4
5
6
7
8
9
10
<html>
<body>
<form action="https://0aef003a04fed832802f26d100f900ee.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="pwned@gmail.com">
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
Una vez hecho esto pulsamos sobre View exploit para ver si nos cambia el email a nosotros y efectivamente nos lo cambia. Independientemente de como generemos el payload, para completar el laboratorio debemos pegarlo 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
