Confirmation d’une vulnérabilité CL.TE par réponses différentielles
HTTP request smuggling, confirming a CL.TE vulnerability via differential responses
Ce laboratoire utilise un serveur frontal et un serveur interne. Le serveur frontal ne gère pas l’encodage chunked. L’objectif est de smuggler une requête vers le back-end afin que la requête suivante vers / déclenche une réponse 404 Not Found.
Note : Même si le labo accepte HTTP/2, la méthode requise n’est exploitable qu’en HTTP/1. Astuce : Le plugin HTTP Request Smuggler de Burp aide à recalculer automatiquement les longueurs.
Observation initiale
Le front-end interprète Content-Length, tandis que le back-end se base sur Transfer-Encoding. En envoyant une requête minimale :
Puis en ajoutant un paramètre, la longueur passe logiquement à 9 :
Pour éviter que la longueur soit recalculée automatiquement, on introduit un nouvel en-tête.
Ajout de Transfer-Encoding
Si l’on ajoute :
le serveur retourne une erreur de désynchronisation :
HTTP/1.1 500 Internal Server Error
En revanche, en envoyant une charge chunked valide :
la réponse revient en 200 OK.
On peut également tester :
Injection d’une requête vers le back-end
Pour obtenir un 404, il faut forcer le back-end à traiter une requête additionnelle. Si l’on ajoute :
et que le back-end interprète correctement la requête smuggled, il exécute bien le GET /error.
Exemple complet :
La première réponse revient en 200, mais la requête suivante envoyée par le navigateur déclenche alors un 404, preuve de la désynchronisation.
Variation : exécuter une autre page
Si l’on veut que le back-end exécute une autre ressource, par exemple :
alors la page principale affichera le contenu correspondant au post 4, confirmant que la requête smuggled a été traitée par le back-end.
Mis à jour
Ce contenu vous a-t-il été utile ?