Confirmation d’une vulnérabilité TE.CL par réponses différentiellescls
HTTP request smuggling, confirming a TE.CL vulnerability via differential responses
Dans ce laboratoire d’HTTP request smuggling, le serveur front-end accepte le découpage en chunked encoding, tandis que le back-end ne le prend pas en charge. L’objectif est d’injecter une requête masquée vers le serveur interne, puis d’envoyer une requête adressée à / afin de provoquer une réponse 404 Not Found, confirmant ainsi la désynchronisation.
Bien que l’application permette l’usage d’HTTP/2, la technique exploitable repose exclusivement sur des comportements propres à HTTP/1, ce qui impose de changer manuellement de protocole dans Burp Repeater.
Principe de la désynchronisation TE.CL
Pour tester la présence d’une vulnérabilité TE.CL, on manipule les champs liés à la longueur. En définissant volontairement un Content-Length supérieur à la taille réelle du corps, on force un décalage interprété différemment par les deux serveurs. Par exemple, un corps chunked réellement long de 13 octets peut être déclaré comme :
Cela suffit à provoquer une désynchronisation.
Encodage hexadécimal du chunk
On commence par calculer en hexadécimal la taille du fragment suivant :
Une première tentative consiste à n’envoyer que la taille du chunk (4 octets) :
Cette version n’est cependant pas traitée comme deux requêtes distinctes par les serveurs, ce qui empêche l’exploitation correcte.
Pour obtenir un comportement fiable, il faut que le back-end interprète la requête injectée comme une requête HTTP valide. On « gonfle » alors le champ Content-Length, tout en envoyant un chunk plus volumineux :
En envoyant cette requête à deux reprises, la désynchronisation se produit et l’attaque fonctionne comme prévu.
Mis à jour
Ce contenu vous a-t-il été utile ?