CSRF where token is not tied to user session
Laboratorio de Portswigger sobre CSRF
Certificaciones
- eWPT
- eWPTXv2
- OSWE
- BSCP
Descripción
Este laboratorio es vulnerable a un ataque de CSRF en la funcionalidad de cambio de correo electrónico. Utiliza tokens para intentar prevenir ataques CSRF, pero estos no están integrados en el sistema de gestión de sesiones del sitio web. Para resolver el laboratorio, debemos utilizar nuestro servidor de explotación para alojar un documento HTML que lleve a cabo un ataque CSRF y cambie la dirección de correo electrónico de la cuenta del usuario víctima. Las credenciales para las dos cuentas en la aplicación son wiener:peter y carlos:montoya
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 inspeccionamos el código, vemos cómo se envía el formulario. Podemos usar este formulario como modelo para construir nuestro propio payload
Si capturamos la petición de cambiar email con Burpsuite, vemos que se está transmitiendo un token CSRF que es el mismo que aparece en la web
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 usando su propia cuenta, obtener un token válido y luego pasar ese token al usuario víctima en su ataque CSRF
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 los payloads de forma manual, para comprobar que funciona nos dirigimos al Exploit server y lo pegamos. Hay que tener en cuenta que mientras ningún usuario genere otro token CSRF, este token será válido
1
2
3
4
5
6
7
8
9
10
11
<html>
<body>
<form action="https://0a6500f904650a4680ddbca6009700a1.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="pwned@gmail.com">
<input type="hidden" name="csrf" value="lpY2pJrIdkX2jPz0XXskpWJor3B67YyS">
</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
