Web cache poisoning via HTTP/2 request tunnelling
Web cache poisoning via HTTP/2 request tunnelling
Ce laboratoire est vulnérable au request smuggling car le serveur frontal rétrograde les requêtes HTTP/2 vers HTTP/1.1 et ne nettoie pas correctement certains en-têtes entrants.
L’objectif est d’empoisonner le cache pour que, lorsque la victime visite la page d’accueil, son navigateur exécute alert(1).
Un utilisateur victime accède automatiquement à la page toutes les 15 secondes.
Le serveur frontal ne réutilise pas les connexions vers le back-end. Les attaques classiques de smuggling ne fonctionnent donc pas, mais le request tunnelling reste exploitable.
On constate qu’un mécanisme de cache est présent sur la page d’accueil.
Forcer un downgrade vers HTTP/1.1
Dans les en-têtes, on peut imposer une interprétation HTTP/1.1 grâce à une construction du type :
Même si cela génère une erreur indiquant que l’en-tête Test n’existe pas, il montre bien que la requête est réinterprétée par le frontal.
Injection dans une ressource statique
En ciblant le fichier JavaScript du labo, on observe que l’ajout d’un paramètre semblable à du script est reflété dans la réponse
La ressource est donc sensible à un empoisonnement du cache.
Construction de la requête tunellisée
On envoie ensuite une requête supplémentaire en encapsulant une nouvelle requête HTTP/1.1 dans le corps :
Cette charge est réinterprétée par le serveur suite au tunnelling. Le contenu injecté est réécrit dans la réponse de la ressource JavaScript, permettant ainsi d’empoisonner le cache.
Lorsque la victime revisite la page d’accueil, son navigateur charge cette version empoisonnée et exécute le alert(1).
Mis à jour
Ce contenu vous a-t-il été utile ?