Web Security Academy
Cross-site request forgery - Lab : CSRF where token is duplicated in cookie
Objectif :
Réussir à changer l'adresse email d'une personne inscrite dans le site.
Solution :
On lance le lab et on se trouve sur la première page d'un blog avec une barre de recherche présente :
On se logue sur le site avec l'identifiant et le mot de passe d'un compte fourni dans l'énoncé ( carlos / montoya ) et l'onglet "Change email" apparaît :
On accède à cette section :
On va maintenant changer l'adresse mail par "Jean@hotmail.fr" pour observer la requête émise lorsqu'on clique sur "Update email" :
C'est une requête POST qui est construite avec deux paramètres : l'un nommé "email" ayant comme valeur "Jean@hotmail.fr" et l'autre représentant un token CSRF.
Un autre token identique est placé dans les cookies. On imagine que le serveur les compare lorsqu'il reçoit une requête liée au changement d'email.
Il va falloir inclure un token valide dans le paramètre POST et les cookies si on veut effectuer une action chez une victime dans le site. Pour celui présent dans le cookie, on va devoir modifier le comportement du navigateur de la victime afin qu'il inclut dans ses cookies les informations voulues.
On continue d'analyser les fonctionnalités du site.
On revient sur la page d'accueil et on essaie d'utiliser la barre de recherche pour inspecter les requêtes émises/reçues.
On recherche le mot "voiture" :
La réponse du serveur est la suivante :
On constate la présence du mot recherché dans l'en-tête "Set-Cookie".
Ayant le contrôle sur ce header, on teste si on peut créer notre propre en-tête "Set-Cookie" en utilisant un CRLF dans le paramètre GET de la requête envoyée de cette manière : /?search=voiture%0d%0aSet-Cookie:%20blabla.
On teste cette entrée et on examine la réponse du serveur :
Cela à fonctionner. Un en-tête "Set-Cookie" s'est placé avec la valeur inscrite. On peut insérer ce que l'on veut dans les cookies d'un navigateur à partir du site.
On a maintenant tous les éléments en main pour écrire le payload :
On doit inclure notre token CSRF ( généré en se connextion à notre compte ) dans le paramètre POST.
On doit l'inclure dans les cookies en exploitant le défaut d'implémentation dans la recherche d'un mot.
Dans le lab, une simulation d'envoi et d'exécution d'un payload sur une victime est implémentée. Il suffit de cliquer sur "Go to exploit serveur" et de simuler l'envoi d'une requête réponse vers une cible à partir duquel notre payload sera exécuté.
On accède à cette fonctionnalité et on simule l'exécution du code HTML suivant chez une victime :
<html>
<body>
<form action="https://ace81f4e1fcc5db1805a31c700180066.web-security-academy.net/email/change-email" method="POST">
<input type="hidden" name="email" value="zumolif@gmail.net" />
<input type="hidden" name="csrf" value="sfUqfLlfeGuAJGZNYPDJUAQjvYeRaaa"/>
</form>
<img src="https://ace81f4e1fcc5db1805a31c700180066.web-security-academy.net/?search=voitured%0d%0aSet-Cookie:%20csrf=sfUqfLlfeGuAJGZNYPDJUAQjvYeRaaa" onerror="document.forms[0].submit()"/>
</body>
</html>
On l'envoie chez la cible et ça marche ! Le lab se valide, le payload s'est bien exécuté chez la victime.
