CSRF vulnerability with no defenses – PortSwigger Write Up
En este post vamos a estar resolviendo el laboratorio de PortSwigger: “CSRF vulnerability with no defenses.”
En este caso, el laboratorio nos indica que hay un CSRF en la funcionalidad de cambio de email. Para resolver el laboratorio, debemos crear una página HTML que se aproveche del CSRF para cambiar el email de quien visite nuestra web. Por último, se nos proporciona unas credenciales para acceder a una cuenta.
Sabiendo todo esto, iniciamos el laboratorio y nos dirigimos a “My account” para iniciar sesión:
Una vez hemos iniciado sesión, se nos redirige por así decirlo a nuestro perfil:
Aquí, como mencionaba el enunciado, encontramos una funcionalidad para cambiar el email de nuestra cuenta, por lo que preparamos el burp suite para interceptar la petición del cambio:
Con el burp suite preparado, colocamos un email aleatorio y le damos a “Update email”:
Al momento de darle, burp suite recibe la petición:
Y como podemos observar, el único parámetro que se envía en el cuerpo de la petición es “email”. No hay ningún parámetro más cuyo valor sea aleatorio e imposible de predecir, por lo que es posible crear una plantilla maliciosa que cree una petición como la que se puede ver arriba, teniendo en cuenta, que las cookies de un sitio son incluidas en cualquier petición que el navegador haga a ese sitio.
Si dejamos que esta petición se envíe, el email cambiará sin problemas:
Ya sabemos toda la información necesaria y todo funciona como se espera, por lo que desactivamos el proxy y nos dirigimos al servidor del exploit:
Una vez dentro tenemos los siguientes campos:
Es aquí donde creamos la plantilla HTML maliciosa que generará la petición que veíamos arriba cuando la víctima visite la página:
Sí, le damos a ver exploit. nosotros mismos visitaremos la página maliciosa.
Como tenemos la sesión guardada en el navegador con las cookies, al visitarla, la petición se genera correctamente y el email es cambiado, todo a partir de solo visitar la web maliciosa.
Entonces, lo que ha ocurrido es:
- La web maliciosa genera una petición especialmente diseñada cuando se visita.
- Si el usuario está logueado en la web vulnerable (este caso), el navegador incluirá automáticamente la cookie de sesión en la petición (suponiendo que la el atributo SameSite de la cookie no está habilitado, que no es este caso)
- La web maliciosa procesará la petición, ya que es imposible diferenciar si la ha hecho la propio víctima o no, por lo que la procesará sin problemas y se cambiará la dirección de email. Como hemos observado que el exploit funciona perfectamente, simplemente podemos enviarlo a la víctima:
Y de esta manera, resolvemos el laboratorio:
¡Un saludo y espero que os sirva de apoyo!