Bypass des contrôles d’accès via le tunneling HTTP/2
Bypassing access controls via HTTP/2 request tunnelling
Description du laboratoire
Ce laboratoire est vulnérable au request smuggling car le serveur frontal rétrograde les requêtes HTTP/2 en HTTP/1 tout en assainissant mal les noms d’en-têtes entrants. Pour résoudre le labo, il faut accéder au panneau d’administration situé à /admin en tant qu’administrateur, puis supprimer l’utilisateur carlos.
Le serveur frontal ne réutilise pas la connexion avec le serveur interne : il n’est donc pas vulnérable aux attaques classiques de request smuggling. En revanche, il reste exposé au tunneling HTTP/2.
Étude du comportement du serveur
On commence par insérer un en-tête personnalisé, par exemple :
Le serveur renvoie alors une erreur, indiquant que l’en-tête est injectable.
Ensuite, si l’on place dans le moteur de recherche quelque chose comme :
le serveur frontal se retrouve confus à cause de cet en-tête supplémentaire. En augmentant le Content-Length à environ 150, on observe que le serveur renvoie des en-têtes internes :
Construction de la requête tunnelisée
On injecte maintenant une nouvelle séquence d’en-têtes :
Pour permettre au tunneling de fonctionner correctement, on place la bonne méthode (HEAD ou GET selon le cas) ainsi que la route souhaitée.
On accède alors au panneau d’administration, où apparaissent les utilisateurs wiener et carlos.
Suppression de l’utilisateur
La suppression se fait en envoyant une requête tunnelisée similaire :
Mis à jour
Ce contenu vous a-t-il été utile ?