CSRF o XSRF (falsificación de solicitudes entre sitios) es otro tipo de ataque web que se suele llevar a cabo con estafas en internet.
Un atacante se aprovecha de una sesión válida de un usuario para poder realizar el ataque a través de peticiones HTTP.
Vamos, para que nos entendamos, es una técnica para falsificar solicitudes en nombre de un usuario legítimo.
Imagen "cedida amablemente" por la gente de Portswigger
Seguro que todos/as habeis leído el típico caso del banco en el que un usuario inicia sesión y puede realizar una transferencia desde un "formulario" de la web. El atacante es capaz de manipular esa petición para que en lugar de que Paco haga la transferencia a Javier, Paco se la haga al atacante.
Pero vamos a intentar ilustrarlo mejor con el lab de la gente de portswigger haciendo uso de su ejemplo.
Supongamos que una aplicación tiene una función que deja a Paco cambiar la dirección de su mail. Cuando Paco hace eso, se envía una petición al servidor como esta:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
email=wiener@normal-user.com
El atacante crea una web con el siguiente código HTML:
<html>
<body>
<form action="https://vulnerable-website.com/email/change" method="POST">
<input type="hidden" name="email" value="pwned@evil-user.net" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
Por lo que si Paco visita esa web creada por el atacante, la página del atacante envía una petición HTTP a la web vulnerable. Si Paco tiene la sesión iniciada, el navegador incluye de manera automática la cookie de sesión -si no se usa el SameSite en las cookies- (recordemos que el atributo SameSite permite declarar si la cookie debe restringirse a un contexto propio o del mimo sitio). Por otro lado, la web procesa la solicitud tratándolo como si Paco hubiese hecho la petición y por lo tanto, cambiará el mail de este.
Esto no siempre es así, también funciona si la web tiene una autenticación básica, no necesariamente tiene que ser con sesiones basadas en cookies (aunque es más habitual).
Vamos con el ejemplo.
En el caso que nos ocupa (el lab de portswigger), nos piden que hagamos login con usuario carlos y contraseña montoya (tu mataste a mi padre... :D), y nos dicen que para resolver el lab, hay que explotar esta vulnerabilidad a través de la URL de modificar correo.
Hacemos el login y vamos a la parte de change email. Ya en el cuadro habilitado a tal efecto, ponemos el mail que queremos modificar (recordemos que ahora tenemos el rol de atacante) y paramos la petición con Burp. Acto seguido, le damos al botón derecho y pinchamos en engagement tools -> generate CSRF. Esto nos abre la venta y en ella podemos modificar el valor del email como se muestra a continuación.
En el caso del lab, una vez que hemos abierto la ventana, debemos ir arriba a la derecha a options y seleccionar la opción auto-submit script y le damos a regenerate.
Hecho esto, en la ventana del lab, debemos ir a go to exploit server.
Una vez allí, en la parte del body pegamos el resultado de burp que hemos generado, le damos a stored y ya nos dice que hemos pasado el reto.
OJO, esto es solo para el caso del lab de portswigger, en la vida real, NO vamos a encontrar esta última parte en la web que ataquemos :D.
Vale, pero ¿qué ocurre cuando hay un token de por medio? porque no siempre nos vamos a encontrar con el primer escenario (más sencillo pero no tan habitual).
Hay varios encenarios en la web con los que podemos jugar, veamos otro ejemplo sencillo en el que el token entra en juego.
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
email=pwned@evil-user.net
Bien, al entrar en el lab, nos dice que el caso es el mismo. Hay que cambiar el mail de Carlos Montoya y las credenciales son las mismas.
Si ahora cambiamos el correo y nos fijamos en la petición, podemos observar que aparece el token.
Y ¿qué pasa si ese token cambia o es manipulado? Pues que nos dice que nos peinemos.
Pues nada, eliminamos el token y vemos que ahora si que se lo come.
A partir de aquí, generamos el PoC del CSRF con burp como vimos en el primer ejemplo.
E igualmente, vamos la parte de go to exploit server, y pegamos el código generado en la parte del body.
Una vez hecho, (y dando a stored) nos vuelve a decir que hemos pasado el reto.
Os recomiendo que realiceis el resto de laboratorios, que van subiendo progresivamente el nivel y ayuda para saber como saltarse el token en distintos escenarios.
Nos vemos en la siguiente.
0 comentarios:
Publicar un comentario