Lorsqu’un client accède à un site web, il communique avec le serveur via le protocole HTTP. Initialement textuel, ce protocole est devenu binaire avec HTTP/2, mais son fonctionnement repose toujours sur TCP.
Chaque échange commence par l’établissement d’une connexion entre le client et le serveur. Avec HTTP/1.0, cette connexion était fermée après chaque requête. Mais avec HTTP/1.1, le mode Keep-Alive est devenu la norme, permettant de maintenir la connexion ouverte pour plusieurs échanges successifs.
C’est aussi avec HTTP/1.1 qu’a été introduit l’en-tête Transfer-Encoding, utilisé pour indiquer comment le corps de la requête doit être interprété. Cette évolution, bien que bénéfique en termes de performances et d’efficacité, a également introduit de nouvelles vulnérabilités.
Parmi elles, le HTTP request smuggling, une attaque qui exploite les incohérences dans le traitement des requêtes HTTP par les serveurs et les proxys.
Dans cet article, nous allons explorer en détail son fonctionnement, ses différentes variantes et les stratégies pour s’en protéger.
Guide complet sur le HTTP Request Smuggling
En quoi consiste le HTTP Request Smuggling ?
Le HTTP request smuggling est une vulnérabilité qui permet à un attaquant de manipuler les requêtes échangées entre un client et un serveur intermédiaire, souvent un proxy ou un load balancer.
En jouant sur la manière dont ces systèmes interprètent les en-têtes Content-Length et Transfer-Encoding, il devient possible d’injecter des requêtes malveillantes, de contourner des contrôles de sécurité ou d’exécuter des actions à l’insu des utilisateurs légitimes.
Cette vulnérabilité exploite les différences d’interprétation des requêtes HTTP entre plusieurs serveurs d’une même infrastructure.
Pour qu’une attaque de request smuggling soit possible, deux conditions doivent être réunies :
- Le serveur cible doit être placé derrière un serveur intermédiaire (reverse proxy, load balancer, etc.).
- L’un des deux serveurs, ou les deux, doivent utiliser le protocole HTTP/1.1, car cette attaque n’est plus possible avec HTTP/2.
Principe de l’attaque HTTP Request Smuggling
L’objectif de l’attaque HTTP request smuggling est de désynchroniser la communication entre le serveur frontal (proxy ou load balancer) et le serveur backend. Cette désynchronisation survient lorsque ces deux serveurs interprètent différemment la taille du corps d’une requête HTTP.
Le problème vient principalement de la coexistence des en-têtes Content-Length et Transfer-Encoding. Normalement, un serveur utilise Content-Length pour définir la taille du contenu d’une requête. Cependant, si l’un des serveurs prend en charge Transfer-Encoding, mais pas l’autre, une ambiguïté peut apparaître.
En exploitant cette confusion, un attaquant peut :
- Injecter des requêtes malveillantes dans le flux de communication.
- Forcer d’autres utilisateurs à exécuter des requêtes à leur insu.
- Intercepter des réponses HTTP destinées à d’autres utilisateurs.
- Polluer la file de réponses d’un serveur, provoquant des dysfonctionnements proches d’une attaque DoS, tout en permettant le vol d’informations sensibles.
Comprendre la désynchronisation via Content-Length et Transfer-Encoding
Lorsqu’une requête HTTP contient à la fois les en-têtes Content-Length et Transfer-Encoding, elle devrait être rejetée avec une erreur 400 Bad Request. Cependant, si ce n’est pas le cas, et que le serveur destinataire prend en charge Transfer-Encoding, c’est cet en-tête qui sera utilisé pour déterminer la taille du corps de la requête.
Le problème apparaît lorsque les deux serveurs impliqués dans le traitement de la requête n’interprètent pas ces en-têtes de la même manière. Si seul l’un des deux serveurs reconnaît Transfer-Encoding, tandis que l’autre utilise Content-Length, une désynchronisation peut se produire.
Le serveur backend pourrait alors ne pas lire l’intégralité du corps de la requête, laissant une partie inutilisée qui sera interprétée comme le début d’une nouvelle requête lors du prochain échange, à condition que la connexion entre le frontend et le backend reste ouverte.
Plusieurs configurations peuvent conduire à une désynchronisation :
- CL.TE : Le serveur frontend ignore Transfer-Encoding, mais le backend l’interprète.
- TE.CL : Le frontend reconnaît Transfer-Encoding, mais le backend ne l’utilise pas.
- TE.TE : Les deux serveurs prennent en charge Transfer-Encoding, mais l’un d’eux ignore l’en-tête si sa syntaxe est malformée.
Le dernier cas (TE.TE) exploite une différence d’interprétation (parsing differential) entre le reverse proxy et le serveur backend. Une requête spécialement conçue peut ainsi provoquer une désynchronisation et permettre des attaques de request smuggling.
Dans l’ensemble, ces scénarios reposent sur le même principe : forcer les serveurs à interpréter différemment une requête HTTP, ouvrant ainsi la porte à des injections furtives et à des détournements de flux de communication.
Exploitation d’une vulnérabilité HTTP Request Smuggling
L’un des scénarios d’attaque les plus courants consiste à exploiter la désynchronisation pour injecter une requête interdite à travers le reverse proxy, sans qu’il ne la détecte.
En pratique, le reverse proxy analysera uniquement la première requête et la jugera conforme aux règles d’accès définies. Cependant, en arrière-plan, le serveur backend recevra en réalité deux requêtes distinctes :
- La première, légitime, qui respecte les restrictions imposées.
- La seconde, dissimulée, qui cible une ressource normalement inaccessible pour un utilisateur standard.
Cela permet à un attaquant de contourner les contrôles d’accès basés sur le reverse proxy et d’accéder à des chemins normalement protégés, exposant ainsi des données sensibles ou des fonctionnalités critiques.
Réponses initiale pour /admin :
On peut constater qu’on a contourné la restriction de route du reverse proxy.
Une fois la restriction du reverse proxy contournée, un attaquant peut exploiter la vulnérabilité à son propre avantage. Par exemple, il peut s’auto-cibler pour intercepter la réponse d’une requête qu’il a directement envoyée au serveur backend, sans que celle-ci ne soit filtrée par le proxy. Cela représente une menace majeure pour le contrôle d’accès d’une plateforme web.
Cependant, le request smuggling ne se limite pas à ce type d’attaque. Il peut également être utilisé pour :
- Forcer un utilisateur à exécuter une requête involontairement (l’utilisateur ciblé sera celui qui envoie la prochaine requête).
- Injecter du code malveillant (XSS reflected) pour compromettre d’autres utilisateurs.
- Désynchroniser la file des réponses HTTP (response queue poisoning), entraînant l’affichage de réponses erronées ou aléatoires aux utilisateurs suivants.
- Lancer une attaque DoS en perturbant le traitement des requêtes et des réponses sur la plateforme.
Ces scénarios montrent à quel point cette vulnérabilité peut être critique et difficile à détecter.
HTTP/2 Downgrading et Request Smuggling
Le protocole HTTP/2 a été conçu pour éliminer plusieurs failles du HTTP/1.1, notamment en cessant d’utiliser des headers pour déterminer la longueur des requêtes. Théoriquement, cela empêche toute exploitation du request smuggling.
Toutefois, si un serveur frontend utilise HTTP/2 mais qu’il réécrit les requêtes en HTTP/1.1 pour communiquer avec un backend, une faille peut apparaître.
Dans ce cas, l’attaquant peut exploiter cette conversion pour injecter des requêtes malveillantes et provoquer une désynchronisation similaire aux attaques classiques de request smuggling.
Injection CRLF et exploitation en http/2
Lorsque l’on tente d’exploiter un request smuggling en HTTP/2 vers HTTP/1.1, il est souvent nécessaire d’utiliser une CRLF injection (Carriage Return Line Feed).
Contrairement à HTTP/1.1, qui est textuel, HTTP/2 est un protocole binaire et n’utilise plus les mêmes délimiteurs pour structurer les requêtes. Lorsqu’un serveur frontend convertit une requête HTTP/2 en HTTP/1.1, il peut interpréter certains caractères binaires comme des sauts de ligne (\r\n ou %0D%0A), permettant à un attaquant d’injecter des headers supplémentaires et de manipuler la requête réécrite.
Un exemple typique d’exploitation consiste à injecter la séquence \r\n dans un header modifiable pour forcer l’ajout d’un header Transfer-Encoding non prévu, ce qui entraîne une désynchronisation entre le proxy et le serveur backend.
Ce type de requête, une fois corrompue par l’injection CRLF, est parfois qualifié de « Kettled », en référence aux recherches de James Kettle sur le sujet.
Autres Variantes du Request Smuggling
Bien que cet article se concentre sur les formes classiques de request smuggling, il existe de nombreuses variantes, notamment :
- Client-side desynchronization (Client Side Desync), qui exploite les différences de traitement côté client.
- HTTP/2 Request Smuggling, une attaque ciblant spécifiquement les failles de conversion entre HTTP/2 et HTTP/1.1.
- Pause-Based Request Smuggling, qui joue sur des délais de traitement pour forcer la désynchronisation.
Ces techniques avancées permettent aux attaquants d’exploiter les subtilités des communications entre serveurs, soulignant ainsi la complexité et l’évolution constante des attaques liées aux protocoles HTTP.
Outils pour identifier et exploiter des vulnérabilités liés au Request Smuggling
L’exploitation des vulnérabilités liées au request smuggling peut être complexe, notamment en raison des subtilités des désynchronisations entre le serveur frontend et le serveur backend.
Heureusement, plusieurs outils permettent d’automatiser la détection et l’exploitation de ces failles.
Smuggler.py
Smuggler.py est un scanner spécialisé conçu pour identifier les désynchronisations HTTP au sein d’un serveur ou d’une liste d’hôtes. Il automatise la recherche des trois principaux types de request smuggling :
- CL.TE (Content-Length vs Transfer-Encoding).
- TE.CL (Transfer-Encoding vs Content-Length).
- TE.TE (Variantes exploitant des erreurs de parsing du Transfer-Encoding).
L’outil permet également d’ajouter des mutations pour affiner les tests, en particulier pour les attaques TE.TE.
Bien qu’il ne soit plus activement maintenu, il reste un choix pertinent pour scanner de grands périmètres de tests et détecter des vulnérabilités.
HTTP Request Smuggler
L’extension HTTP Request Smuggler de Burp Suite simplifie l’exploitation des vulnérabilités de request smuggling.
Elle automatise certains ajustements critiques, comme le calcul des offsets nécessaires pour les attaques TE.CL. L’extension repose sur Turbo Intruder, un outil de fuzzing avancé, permettant de sonder le comportement du serveur et optimiser les attaques.
En combinant ces outils avec une compréhension approfondie du fonctionnement des serveurs HTTP et des proxies, il devient possible de détecter et exploiter efficacement des failles request smuggling, notamment dans des environnements où les différences de traitement des requêtes peuvent être manipulées à des fins malveillantes.
Comment se protéger du HTTP Request Smuggling ?
Le request smuggling repose sur une faiblesse propre au protocole HTTP/1.1. Si l’ensemble des serveurs d’une plateforme utilisent HTTP/2, cette attaque devient impossible, car les différences d’interprétation entre le frontend et le backend n’existent plus.
Cependant, migrer vers HTTP/2 n’est pas toujours une option immédiate. Dans ce cas, plusieurs mesures peuvent être mises en place pour se prémunir contre cette vulnérabilité :
- Rejeter les requêtes ambiguës contenant à la fois Content-Length et Transfer-Encoding, aussi bien au niveau du frontend que du backend.
- Éviter la réutilisation des connexions entre le serveur frontend et le backend afin d’empêcher la persistance de requêtes désynchronisées.
- Déployer un WAF configuré pour détecter et bloquer les tentatives d’exploitation de request smuggling.
- Harmoniser la stack technologique en utilisant le même serveur pour le frontend et le backend (comme Nginx), afin d’éviter des différences de parsing et d’interprétation des requêtes HTTP.
L’application stricte de ces bonnes pratiques permet de réduire considérablement les risques liés au HTTP request smuggling, et d’empêcher les attaquants d’exploiter cette vulnérabilité pour manipuler le trafic ou intercepter des requêtes.
Auteur : Titouan SALOU – Pentester @Vaadata