Déception du cache web via request smuggling
Exploiting HTTP request smuggling to perform web cache deception
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 :
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 :
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 :
Mis à jour
Ce contenu vous a-t-il été utile ?