Web Security Academy
HTTP request smuggling - Lab : Confirming a CL.TE vulnerability via differential responses
Énoncé et objectif :
Ce lab inclut un serveur front-end et back-end. Le serveur front-end ne supporte pas l'entête Transfer-Encoding. L'objectif est de faire passer une requête au serveur back-end, de sorte que celui-ci renvoie une erreur 404 pour une prochaine requête légitime envoyée.
Solution :
On lance le lab et on se retrouve dans un blog.
On recharge la page en interceptant la requête envoyée au serveur :
Pour savoir si les serveurs sont vulnérables à une attaque de type HTTP request smuggling, on va modifier la méthode de la requête en POST et ajouter les entêtes Content-length et Transfer-Encoding. Pour les données POST, on ajoute un chunk vide et on écrit une nouvelle requête à la suite vers une URL inconnu. Ce qui donne :
Le but est que le serveur back-end prenne seulement en compte le header Transfer-Encoding et donc va consider les données après le caractère "0" comme une nouvelle requête qu'il va concaténer à la prochaine requête reçue.
Après avoir envoyé cette requête contenant le payload, on en renvoie une autre valide et le serveur nous répond de la manière suivante :
En effet, l'adresse "/xxxxxx" écrite dans les données POST n'existe pas. Elle est inaccessible. Donc on reçoit une erreur de type 404. Ce qui confirme que les serveurs sont vulnérables à une attaque de type "HTTP request sumggling".
Le lab est désormais validé.
