HTTP Request Smuggling : Parler deux langues pour contourner la sécurité 🗣️

La demande HTTP smuggling représente l’une des vulnérabilités de sécurité web les plus sophistiquées et dangereuses dans les infrastructures d’applications modernes. Cette technique d’attaque exploite des désaccords fondamentaux entre les proxies web et les serveurs backend sur l’endroit où une requête HTTP se termine et une autre commence, permettant aux attaquants d’injecter des requêtes malveillantes, de contourner les contrôles de sécurité, de poisonner les caches, et même de détourner des sessions utilisateur légitimes.

Comprendre la base : comment HTTP définit les limites des requêtes

Pour comprendre le HTTP request smuggling, il faut d’abord saisir comment HTTP communique la longueur d’une requête. Le protocole HTTP offre deux mécanismes principaux pour spécifier la fin du corps d’une requête : l’en-tête Content-Length et l’en-tête Transfer-Encoding.

L’en-tête Content-Length déclare explicitement la taille du corps du message en octets. Par exemple, un en-tête indiquant “Content-Length: 15” indique au serveur de réception de lire exactement 15 octets de données après les en-têtes.

L’en-tête Transfer-Encoding, en particulier lorsqu’il est réglé sur “chunked”, indique que le corps du message est envoyé en plusieurs morceaux, chacun précédé de sa taille en hexadécimal. Une taille de chunk zéro signale la fin du message.

Selon les spécifications HTTP, lorsque ces deux en-têtes apparaissent dans la même requête, les serveurs doivent la rejeter ou privilégier Transfer-Encoding. Cependant, dans la pratique, les implémentations dévient souvent de ces standards, créant des incohérences exploitables.

La vulnérabilité principale : quand les systèmes ne sont pas d’accord

Les vulnérabilités de HTTP request smuggling apparaissent lorsque les serveurs front-end (comme les équilibrages de charge, proxies inverses ou CDN) et les serveurs d’application back-end interprètent différemment la même requête HTTP. Les architectures web modernes enchaînent généralement plusieurs composants de traitement HTTP, chacun devant analyser indépendamment les requêtes entrantes.

Lorsque le front-end et le back-end ne s’accordent pas sur les limites de la requête, un attaquant peut créer des requêtes ambiguës qui apparaissent comme une seule requête complète pour le front-end mais comme deux requêtes distinctes pour le back-end. Ce désynchronisation crée une fenêtre où du contenu malveillant peut être “smuggled” en passant outre les contrôles de sécurité.

Des vulnérabilités récentes ont montré que cette menace reste active et en évolution. En mars 2025, des chercheurs en sécurité ont découvert une vulnérabilité de request smuggling dans l’infrastructure d’Akamai impliquant des requêtes OPTIONS avec des en-têtes Expect et un pliage de ligne obsolète. De même, en avril 2025, Cloudflare a corrigé une vulnérabilité critique de smuggling dans leur composant proxy Pingora, qui pouvait permettre aux attaquants de modifier les en-têtes et URLs envoyés aux origines clients.

Variantes d’attaque : les différentes langues du smuggling

Les chercheurs en sécurité ont identifié plusieurs variantes principales de HTTP request smuggling, chacune exploitant des différences d’analyse :

CL.TE (Content-Length vers Transfer-Encoding)

Dans cette variante, le serveur front-end traite les requêtes en se basant sur l’en-tête Content-Length, tandis que le back-end privilégie Transfer-Encoding. Un attaquant envoie une requête avec les deux en-têtes, ce qui amène le front-end à transmettre ce qu’il croit être une requête complète. Le back-end, cependant, interprète seulement une partie de ces données comme la première requête et considère le reste comme le début d’une seconde requête.

TE.CL (Transfer-Encoding vers Content-Length)

Cette attaque inverse le scénario précédent. Le front-end traite Transfer-Encoding tandis que le back-end se fie à Content-Length. L’attaquant déclare un petit chunk que le front-end accepte comme complet, mais inclut un contenu supplémentaire que le back-end considère comme une requête séparée suivante.

TE.TE (Obfuscation par Transfer-Encoding)

Les deux serveurs supportent Transfer-Encoding, mais un attaquant peut induire un serveur à l’ignorer via des techniques d’obfuscation. Cela peut impliquer des espaces inhabituels, une capitalisation particulière ou des caractères cachés provoquant des incohérences d’analyse entre systèmes.

TE.0 et CL.0 (Variantes à longueur zéro)

Des recherches en 2024 ont découvert de nouvelles variantes où le serveur back-end ignore complètement Transfer-Encoding ou Content-Length, traitant la longueur du corps du message comme zéro. Ces techniques se sont révélées efficaces contre de grands fournisseurs cloud, avec des chercheurs découvrant une vulnérabilité TE.0 affectant des milliers de sites hébergés sur Google Cloud.

Scénarios d’attaque dévastateurs

Contournement des contrôles de sécurité

Le HTTP request smuggling excelle à contourner les mesures de sécurité front-end. Les organisations mettent en place des contrôles d’accès, des vérifications d’authentification et des scans de sécurité au niveau du périmètre. Lorsqu’un attaquant smuggles une requête, celle-ci semble provenir de l’infrastructure front-end de confiance, contournant complètement ces mécanismes.

Considérez une application qui limite les fonctions administratives aux requêtes venant de localhost. Un attaquant peut smuggler une requête avec un en-tête Host modifié, faisant croire au back-end que la requête provient localement alors que le front-end l’a validée comme une requête légitime externe.

Attaques de poisoning de cache

Les mécanismes de cache web stockent les réponses pour améliorer la performance et réduire la charge serveur. Le HTTP request smuggling permet aux attaquants de poisonner ces caches avec du contenu malveillant, qui sera ensuite servi à tous les utilisateurs demandant la ressource affectée.

Dans un scénario typique de poisoning de cache, un attaquant smuggles une requête qui pousse le serveur à répondre avec un contenu inattendu — peut-être une redirection vers un site malveillant. Si le cache front-end interprète cette réponse comme appartenant à une ressource légitime en cache, comme un fichier JavaScript, il stocke la réponse malveillante. Chaque utilisateur suivant qui demande ce fichier JavaScript reçoit le contenu empoisonné, ce qui peut compromettre leurs sessions via des attaques de type cross-site scripting.

L’impact du poisoning de cache dépasse les utilisateurs individuels. Une fois le cache empoisonné, le contenu malveillant se propage à tous les utilisateurs accédant à l’URL affectée jusqu’à ce que le cache expire ou que les administrateurs le invalident manuellement. Cela en fait une vecteur de déni de service très puissant ou une méthode de distribution massive de payload.

Détournement de requêtes et vol de crédentials

Une des applications les plus dangereuses du HTTP request smuggling consiste à capturer les requêtes d’autres utilisateurs, y compris leurs cookies de session et identifiants d’authentification. Cette attaque exploite la réutilisation des connexions dans les infrastructures HTTP modernes.

De nombreux systèmes web maintiennent des connexions persistantes entre proxies front-end et serveurs back-end pour améliorer la performance. Lorsqu’un attaquant smuggles avec succès une requête partielle, celle-ci reste en file d’attente sur le serveur back-end. La requête légitime suivante qui arrive sur la même connexion est ajoutée à la requête smuggled comme son “corps”.

Les attaquants peuvent créer la requête smuggled pour inclure un champ de formulaire stockant ce contenu ajouté. Lorsqu’ils récupèrent ensuite ces données stockées, ils obtiennent la requête HTTP complète d’un autre utilisateur, y compris les tokens de session, en-têtes d’authentification, et potentiellement des données sensibles. Cela leur donne essentiellement la capacité d’usurper l’identité de n’importe quel utilisateur dont la requête est piégée.

Impact réel et découvertes récentes

La communauté de la sécurité continue de découvrir des vulnérabilités de HTTP request smuggling dans des composants d’infrastructure majeurs. Voici quelques exemples récents illustrant l’ampleur de cette menace :

En 2024, des chercheurs ont identifié des vulnérabilités de request smuggling dans des serveurs web populaires comme gunicorn et webrick, montrant que même des projets open-source largement utilisés restent vulnérables.

La découverte sur Google Cloud en 2024 a révélé que des milliers de sites utilisant le Load Balancer de Google étaient vulnérables à une nouvelle variante TE.0. Les chercheurs ont reçu une prime de 8 500 $ après que Google a confirmé avoir corrigé le problème suite à un rapport client.

Ces incidents soulignent une réalité importante : les vulnérabilités de HTTP request smuggling affectent souvent des composants d’infrastructure plutôt que le code applicatif. Cela signifie que plusieurs organisations deviennent vulnérables simultanément lorsqu’un proxy, un équilibrage de charge ou un CDN présente une incohérence d’analyse.

Stratégies de détection et de prévention

Pour les professionnels de la sécurité

La détection du HTTP request smuggling nécessite des techniques de test spécialisées. Les chercheurs en sécurité utilisent généralement des méthodes de détection basées sur le timing, en créant des requêtes ambiguës et en mesurant les délais de réponse. Lorsqu’un serveur connaît un timeout ou un délai inhabituel, cela indique souvent qu’il attend des données supplémentaires à cause d’un désalignement.

Des outils automatisés comme l’extension HTTP Request Smuggler de Burp Suite peuvent tester systématiquement ces vulnérabilités en envoyant des requêtes de sonde et en analysant les réponses. Cependant, les tests manuels restent précieux pour découvrir de nouvelles variantes que les outils automatisés pourraient manquer.

Pour les développeurs et équipes opérationnelles

Prévenir le HTTP request smuggling nécessite de traiter les incohérences fondamentales d’analyse entre systèmes :

Normaliser la gestion des requêtes : Configurer tous les composants d’infrastructure pour interpréter les en-têtes HTTP de manière cohérente. C’est la prévention la plus efficace, mais souvent difficile dans des environnements hétérogènes avec des équilibreurs de charge matériels et des serveurs applicatifs logiciels.

Désactiver les fonctionnalités HTTP/1.1 : Si Transfer-Encoding et les connexions persistantes ne sont pas nécessaires, leur désactivation élimine toute une classe d’attaques de smuggling. Cependant, cela peut impacter les optimisations de performance.

Utiliser HTTP/2 de bout en bout : HTTP/2 utilise un mécanisme de trame binaire qui élimine les ambiguïtés inhérentes à l’analyse des requêtes HTTP/1.1. Lorsque front-end et back-end communiquent exclusivement via HTTP/2, la plupart des techniques classiques de smuggling deviennent impossibles.

Mettre en place une validation stricte des requêtes : Configurer les serveurs front-end pour rejeter les requêtes contenant à la fois Content-Length et Transfer-Encoding, ou toute requête avec une mise en forme inhabituelle des en-têtes.

Désactiver la réutilisation des connexions : Si techniquement faisable, empêcher le back-end de réutiliser les connexions entre différents clients élimine complètement le détournement de requêtes, bien que cela sacrifie les bénéfices de performance.

L’évolution du paysage de la menace

La recherche sur le HTTP request smuggling continue d’évoluer, avec des professionnels de la sécurité découvrant régulièrement de nouvelles variantes et techniques. La découverte en 2024 du smuggling TE.0, initialement remise en question par certains, montre que la surface d’attaque reste partiellement cartographiée.

La complexité des architectures web modernes — avec plusieurs couches de proxies, équilibrages de charge, CDN et dispositifs de sécurité — crée de nombreuses opportunités pour des incohérences d’analyse. À mesure que les organisations adoptent des architectures microservices et le calcul sans serveur, le nombre de composants de traitement HTTP dans un chemin de requête continue de croître, potentiellement en élargissant la surface d’attaque.

Les fournisseurs cloud sont devenus des cibles particulièrement importantes pour la recherche en smuggling. Une seule vulnérabilité dans l’infrastructure d’une plateforme cloud peut affecter simultanément des milliers d’applications clientes, rendant ces découvertes particulièrement précieuses pour les attaquants et chercheurs.

Conclusion

Le HTTP request smuggling illustre les défis de sécurité issus de l’ambiguïté du protocole et de la diversité des implémentations. En exploitant des désaccords subtils entre systèmes sur des opérations fondamentales du protocole, les attaquants peuvent contourner même des contrôles de sécurité sophistiqués.

La complexité nécessaire pour découvrir et exploiter ces vulnérabilités explique qu’elles aient historiquement reçu moins d’attention que des vecteurs d’attaque plus évidents. Cependant, comme l’a souligné le chercheur en sécurité James Kettle, le HTTP request smuggling est “partout et largement sous-étudié.” Les découvertes récentes dans de grandes plateformes cloud confirment cette évaluation.

Les organisations doivent reconnaître que les vulnérabilités de HTTP request smuggling résident généralement dans les composants d’infrastructure plutôt que dans le code applicatif. Cela déplace la responsabilité de la détection et de la mitigation vers les équipes d’exploitation et de sécurité qui gèrent ces systèmes. Des évaluations de sécurité régulières doivent inclure des tests spécialisés pour détecter ces vulnérabilités, notamment après le déploiement de nouveaux composants ou la mise à jour de ceux existants.

À mesure que les architectures web évoluent, la communauté de la sécurité doit rester vigilante face aux incohérences d’analyse et aux ambiguïtés du protocole. La prochaine grande variante de HTTP request smuggling existe probablement déjà, en attente qu’un chercheur créatif découvre comment deux systèmes peuvent ne pas s’accorder sur quelque chose d’aussi fondamental que la fin d’une requête et le début d’une autre.