Web Security Academy

Cross-site request forgery - Lab : CSRF where token is tied to non-session 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 disponible :

On se connecte avec l'identifiant et le mot de passe d'un compte fourni dans l'énoncé ( wiener / peter ) et l'onglet "Change email" apparaît :

On accède à cette section :

On essaye maintenant de changer l'adresse mail par "bob@hotmail.fr" et d'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 CSRF différent est placé dans les cookies.

Il va falloir inclure un couple de token valide si on veut effectuer une action chez une victime. 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 les caractères CRLF dans le paramètre GET de la requête liée à la recherche d'un mot 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 inclure notre cookie CSRF 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://acc21fd41eabef7880feaa7a00c300bc.web-security-academy.net/email/change-email" method="POST">

<input type="hidden" name="email" value="xxx@gmail.net" />

<input type="hidden" name="csrf" value="MSaVH3wfX6mOi8t2H7G2R7RhLWHbJwVM">

</form>


<img src="https://acc21fd41eabef7880feaa7a00c300bc.web-security-academy.net/?search=voiture%0d%0aSet-Cookie:%20csrfKey=aGfi3GLKgxcJKbd76QPdpZnyooxQ8RN3" 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.