Web Security Academy
HTTP request smuggling - Lab : obfuscating the TE header
Énoncé et objectif :
Ce lab inclut un serveur front-end et back-end. Les deux supportent l'entête Transfer-Encoding. L'objectif est de faire passer une requête au serveur back-end, de sorte que celui-ci semble utiliser la méthode "GPOST".
Solution :
On lance le lab et on se retrouve dans un blog.
On recharge la page d'accueil en interceptant la requête émise vers le serveur :
Pour découvrir si les serveurs sont vulnérables à une attaque de type HTTP request smuggling, on va modifier cette requête en changeant la méthode en POST et inclure un entête Content-length et un entête Transfer-Encoding "obfusqué" : on va définir deux fois ce header avec une valeur aléatoire sur le deuxième. Cette technique est utilisée lorsque le front-end et back-end supportent l'entête Transfer-Encoding. Le but est que le serveur front-end prenne en compte l'encodage chunked et que le serveur back-end prenne seulement en compte l'entête Content-length ( avec une valeur précisément définie jusqu'au payload ) car il est trompé par l'obfuscation.
On va ensuite définir le premier chunk en définissant une requête avec la méthode GPOST. Ce qui donne :
On redirige ensuite notre requête au serveur. On envoie une deuxième requête légitime, et on reçoit la réponse suivante :
En effet, le serveur back-end a traité une requête commençant par "GPOST" ( comme on l'a indiqué précédemment dans la requête du payload ) car les données du chunk ont été concaténées au début de la deuxième requête envoyée.
Donc ce serveur est en effet vulnérable à une attaque de type HTTP request sumggling.
Le lab est désormais validé.
