HTTP Request Smuggling : CL.TE, TE.CL et Attaques par Rétrogradation HTTP/2

Le HTTP Request Smuggling (ou contrebande de requêtes HTTP) constitue l'une des classes de vulnérabilités les plus dévastatrices et complexes de la sécurité des applications web modernes. Initialement documentée en 2005 par les chercheurs de Watchfire puis remise sur le devant de la scène par les travaux de recherche majeurs de James Kettle, cette faille exploite les divergences d'interprétation des limites de requêtes HTTP entre les proxys inverses frontaux (load balancers, CDN, passerelles WAF) et les serveurs d'applications en backend.

Lorsqu'un attaquant parvient à provoquer une désynchronisation de flux, il peut injecter une requête HTTP arbitraire directement dans la connexion TCP persistante partagée entre le proxy et le serveur d'origine. Cette requête "dissimulée" patiente dans le tampon du socket jusqu'à l'arrivée de la requête d'un utilisateur légitime suivant, qui se retrouve alors concaténée au fragment injecté. Les répercussions vont du contournement intégral de l'authentification et de la prise de contrôle administrative au vol d'identifiants entre utilisateurs, à l'empoisonnement furtif du cache et à la compromission persistante de l'infrastructure.

Ce guide technique approfondi détaille l'architecture réseau rendant le request smuggling possible, décortique les mécanismes classiques de désynchronisation CL.TE et TE.CL, explore les attaques modernes par rétrogradation HTTP/2 (H2.CL et H2.TE), illustre des scénarios d'exploitation concrets et expose les mesures de durcissement indispensables pour sécuriser les architectures modernes.

---

1. L'Architecture du HTTP Request Smuggling

Les infrastructures web contemporaines exposent rarement les serveurs d'applications directement sur l'Internet public. Au contraire, les architectures à fort trafic routent les flux à travers des proxys inverses et des réseaux de diffusion de contenu (CDN) tels que Cloudflare, AWS Application Load Balancers (ALB), Fastly, Nginx, HAProxy ou Envoy. Ces équipements en périphérie assurent des fonctions capitales : terminaison TLS, répartition de charge, mise en cache statique, limitation de débit et inspection par pare-feu applicatif (WAF).

Afin de maximiser les performances réseau et de réduire la latence globale, les proxys frontaux regroupent (pooling) et multiplexent les requêtes entrantes des clients au sein de connexions TCP persistantes vers les serveurs backend. L'établissement d'une connexion TCP requiert une poignée de main en trois temps (handshake), l'allocation de sockets et une négociation TLS. Le maintien de connexions persistantes (HTTP/1.1 Keep-Alive) permet au frontal de faire transiter des centaines de requêtes émanant de clients distincts sur une seule connexion TCP durable, sans renégociation perpétuelle.

+------------------+        HTTP/1.1 ou HTTP/2
|  Client A (User) | -------------------------\
+------------------+                           \   +----------------------+   TCP Persistant Partagé  +-----------------------+
                                                ==>|  Proxy Front-End     |==========================>|  Serveur Back-End     |
+------------------+                           /   |  (Cloudflare / ALB)  |   (Requêtes Pipelinées)   |  (Node.js / Tomcat)   |
| Attaquant        | -------------------------/    +----------------------+                           +-----------------------+
+------------------+

Cette optimisation repose impérativement sur un invariant fondamental : le proxy frontal et le serveur backend doivent convenir de manière absolument identique de l'endroit exact où une requête HTTP s'achève et où la suivante commence.

Étant donné que le protocole HTTP/1.1 est un flux de texte brut, l'analyseur (parser) syntaxique doit impérativement se fier aux métadonnées des en-têtes pour déterminer la longueur du corps de la requête. Si le proxy frontal et le serveur backend divergent dans l'interprétation de ces métadonnées, une désynchronisation se produit. Le frontal transmet ce qu'il interprète comme une requête unique, mais le backend découpe la séquence d'octets en deux requêtes distinctes. Les octets excédentaires demeurent dans le tampon de lecture du socket backend et viennent se greffer au début de la prochaine requête arrivant sur la connexion.

---

2. Le Conflit RFC 7230 : Content-Length vs. Transfer-Encoding

Dans la spécification HTTP/1.1, il existe deux mécanismes standardisés permettant d'indiquer la taille et la délimitation d'un corps de requête :

• Content-Length (CL) : Un en-tête indiquant la taille exacte du corps du message en octets sous forme de nombre décimal. L'analyseur lit rigoureusement ce nombre d'octets à la suite de la séquence de fin d'en-têtes CRLF double (\r\n\r\n).
• Transfer-Encoding: chunked (TE) : Un mécanisme par lequel le corps du message est fragmenté en plusieurs morceaux (chunks). Chaque morceau débute par sa taille exprimée en hexadécimal, suivie de \r\n, de la charge utile, puis d'un autre \r\n. Le flux se termine par un morceau final de longueur zéro : 0\r\n\r\n.

Que se produit-il lorsqu'une requête HTTP contient simultanément ces deux en-têtes ?

L'IETF avait expressément anticipé cette ambiguïté. La RFC 7230, Section 3.3.3 (Message Body Length) édicte la règle normative formelle :

« Si un message est reçu avec à la fois un champ d'en-tête Transfer-Encoding et un champ d'en-tête Content-Length, le Content-Length DOIT être supprimé ou ignoré ; le Transfer-Encoding a la priorité. »

Dans un monde strictement conforme, chaque composant logiciel accorderait la priorité absolue à Transfer-Encoding: chunked et éliminerait Content-Length. En pratique, les implémentations réelles souffrent d'incohérences notoires :

• Certains proxys historiques ou passerelles applicatives propriétaires ne gèrent pas le chunked encoding en entrée et se rabattent systématiquement sur Content-Length.
• Certains serveurs d'applications backend accordent la préséance à Content-Length dès lors qu'un format d'en-tête non standard ou malformé est rencontré.
• Certains pare-feux ou répartiteurs normalisent l'un des en-têtes sans toucher au second.

Dès l'instant où une architecture héberge deux analyseurs syntaxiques prenant des décisions opposées face à une requête ambiguë, le système devient directement exploitable par Request Smuggling.

---

3. Vulnérabilité CL.TE : Le Front-End utilise CL, le Back-End utilise TE

Dans un scénario de désynchronisation CL.TE, le proxy frontal traite le corps de la requête en se fondant sur l'en-tête Content-Length, tandis que le serveur backend applique l'en-tête Transfer-Encoding: chunked.

Anatomie d'une Charge Utile CL.TE

Examinons la requête HTTP brute transmise par un attaquant au proxy frontal :

POST / HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
Content-Length: 13\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\n
\r\n
SMUGGLED

Mécanisme d'Exécution Étape par Étape

1. Traitement par le Front-End : Le proxy frontal inspecte Content-Length: 13. Il compte exactement 13 octets à partir du début du corps :
   0\r\n (3 octets) + \r\n (2 octets) + SMUGGLED (8 octets) = 13 octets.
   Le proxy considère que la totalité du corps de la requête a été reçue. Faisant confiance à Content-Length, il achemine l'intégralité des 13 octets vers le serveur backend via la connexion TCP persistante partagée.
2. Traitement par le Back-End : Le serveur backend applique la RFC 7230 et donne la priorité à Transfer-Encoding: chunked. Il analyse le flux par blocs.
   Le premier bloc rencontré est 0\r\n suivi d'une ligne vide \r\n. Il s'agit du terminateur officiel de flux fragmenté.
   Le backend conclut immédiatement que le corps de la requête est achevé. Il exécute le gestionnaire de requête et renvoie sa réponse HTTP au frontal.
3. L'État du Socket Désynchronisé : Qu'advient-il des 8 octets restants (SMUGGLED) ?
   Le serveur backend ne les a jamais lus. Ils demeurent en attente dans le tampon de réception du socket TCP backend, prêts à être interprétés lors de la prochaine lecture.
4. Corruption de la Requête Victime : Un utilisateur légitime émet immédiatement une requête classique sur la même connexion TCP partagée :

   GET /profile HTTP/1.1\r\n
   Host: vulnerable-website.com\r\n
   User-Agent: Mozilla/5.0...\r\n
   ...

   Le serveur backend lit dans le tampon TCP et préfixe les 8 octets résiduels :

   SMUGGLEDGET /profile HTTP/1.1\r\n
   Host: vulnerable-website.com\r\n
   User-Agent: Mozilla/5.0...\r\n
   ...

   Le backend analyse SMUGGLEDGET comme une méthode HTTP non reconnue et renvoie une erreur 400 Bad Request ou 501 Not Implemented, ou traite une requête complète si l'attaquant a forgé un préfixe HTTP valide.

---

4. Vulnérabilité TE.CL : Le Front-End utilise TE, le Back-End utilise CL

Dans une désynchronisation TE.CL, les rôles sont inversés. Le proxy frontal interprète l'en-tête Transfer-Encoding: chunked, alors que le serveur d'origine en backend l'ignore ou ne le prend pas en charge, s'appuyant uniquement sur Content-Length.

Anatomie d'une Charge Utile TE.CL

L'attaquant conçoit une requête dont le flux fragmenté s'étend bien au-delà de la longueur spécifiée par le Content-Length :

POST / HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
Content-Length: 3\r\n
Transfer-Encoding: chunked\r\n
\r\n
8\r\n
SMUGGLED\r\n
0\r\n
\r\n

Mécanisme d'Exécution Étape par Étape

1. Traitement par le Front-End : Le frontal applique Transfer-Encoding: chunked. Il lit la taille de bloc 8, consomme 8 octets de données (SMUGGLED), lit le \r\n, lit la taille 0 et consomme le \r\n final.
   Considérant le flux fragmenté comme parfaitement valide et clos, le frontal expédie la totalité de la requête sur le socket backend.
2. Traitement par le Back-End : Le serveur backend lit strictement en fonction de Content-Length: 3. Il lit seulement les 3 premiers octets du corps : 8\r\n.
   Le serveur d'origine estime que la requête est terminée, traite la commande et transmet sa réponse au frontal.
3. L'État du Socket Désynchronisé : Les octets subséquents dans le flux—SMUGGLED\r\n0\r\n\r\n—restent non lus dans la mémoire tampon TCP du backend.
4. Concaténation de la Requête Victime : Lorsqu'une nouvelle requête parvient au backend :

   GET /search?q=test HTTP/1.1\r\n
   Host: vulnerable-website.com\r\n
   ...

   Le serveur backend commence la lecture à partir des octets en attente :

   SMUGGLED\r\n
   0\r\n
   \r\n
   GET /search?q=test HTTP/1.1\r\n
   Host: vulnerable-website.com\r\n
   ...

   Si l'attaquant a remplacé SMUGGLED par une ligne de commande HTTP complète comme GET /admin HTTP/1.1\r\nHost: vulnerable-website.com\r\n..., le serveur backend exécute cette commande administrative avec les privilèges réseau internes.

Techniques d'Obfuscation TE.TE

Lorsque le frontal et le backend supportent tous deux l'en-tête Transfer-Encoding, l'attaquant peut encore induire une désynchronisation en incitant l'un des deux composants à ignorer l'en-tête via des anomalies syntaxiques ou des espaces blancs inhabituels :

Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: cow
Transfer-Encoding:[tab]chunked
X: X[\n]Transfer-Encoding: chunked

Si le frontal tolère l'obfuscation et traite la requête en chunked, tandis que le backend rejette l'en-tête non conforme et se replie sur Content-Length, l'attaquant recrée une vulnérabilité TE.CL opérationnelle.

---

5. Attaques par Rétrogradation HTTP/2 : H2.CL et H2.TE

L'arrivée massive du protocole HTTP/2 a laissé croire à de nombreux développeurs que le Request Smuggling appartenait définitivement au passé. Dans une architecture HTTP/2 native, les trames sont strictement binaires : chaque trame DATA contient un champ de longueur non ambigu sur 24 bits codé directement dans son en-tête de 9 octets. Les limites des messages étant fixées au niveau de la couche transport, aucune ambiguïté textuelle ne peut survenir.

Cependant, les architectures web ont introduit un défaut de conception structurel majeur : la rétrogradation HTTP/2 (Front-End HTTP/2 vers Back-End HTTP/1.1).

+------------------+      HTTP/2 (Trames Binaires)   +----------------------+      HTTP/1.1 (Flux Texte Brut)       +-----------------------+
| Client Attaquant | ===============================>|  Proxy Front-End     | =====================================> |  Serveur Back-End     |
| (Burp Suite /    |   - Longueurs de trame explicites|  (Traduction de H2   |   - Analyse de CL ou TE en texte brut  |  (Serveur d'Origine)  |
|  h2load)         |   - Métadonnées d'en-têtes      |   vers H1.1 sur TCP) |   - Vulnérable à la désynchronisation  |                       |
+------------------+                                 +----------------------+                                        +-----------------------+

Les proxys terminent les connexions des clients en HTTP/2 pour des raisons d'optimisation mobile, mais reconvertissent les requêtes en HTTP/1.1 lorsqu'ils communiquent avec les microservices en arrière-plan. Les recherches de James Kettle ont démontré que ce processus de conversion engendre des vulnérabilités critiques.

H2.CL (HTTP/2 avec Content-Length Injecté)

En HTTP/2 natif, l'en-tête content-length est superflu puisque les limites des trames DATA sont connues. Cependant, la RFC 7540 autorise l'envoi d'un en-tête content-length sous réserve qu'il corresponde à la longueur réelle de la charge utile.

Si le proxy frontal omet de vérifier la concordance entre la valeur déclarée dans le content-length et la longueur effective des trames HTTP/2, l'attaquant peut envoyer une requête HTTP/2 spécifiant une longueur délibérément fausse :

:method: POST
:path: /
:authority: target.com
content-length: 0

CORPS DE REQUETE CONTREBANDE

Lors de la conversion en HTTP/1.1, le frontal sérialise le message suivant :

POST / HTTP/1.1\r\n
Host: target.com\r\n
Content-Length: 0\r\n
\r\n
CORPS DE REQUETE CONTREBANDE

Le backend HTTP/1.1 lit Content-Length: 0, clôt immédiatement le traitement de la première requête et laisse les octets excédentaires dans le tampon socket pour la requête suivante.

H2.TE (HTTP/2 avec Transfer-Encoding Injecté)

La section 8.1.2.2 de la RFC 7540 interdit explicitement les en-têtes liés à la connexion en HTTP/2, en particulier Transfer-Encoding. Toute requête HTTP/2 comportant cet en-tête DOIT être rejetée avec une erreur de flux de type PROTOCOL_ERROR.

Pourtant, de multiples équipements en production continuent de transmettre les en-têtes transfer-encoding: chunked lors de la conversion vers HTTP/1.1. Le backend interprète le corps comme fragmenté et bascule instantanément en mode désynchronisé.

Injection CRLF en HTTP/2 (Header Smuggling)

Les en-têtes HTTP/2 étant encodés sous forme de paires clé-valeur binaires via HPACK et non de texte séparé par \r\n, les valeurs d'en-têtes peuvent comporter des sauts de ligne littéraux sans corrompre la trame binaire.

Si le proxy ne filtre pas rigoureusement ces caractères lors de la rétrogradation en HTTP/1.1, l'attaquant peut injecter des en-têtes HTTP additionnels ou un corps de requête entier directement à l'intérieur d'une valeur d'en-tête :

Nom d'en-tête  : foo
Valeur d'en-tête : bar\r\n\r\nGET /admin HTTP/1.1\r\nHost: target.com\r\n\r\n

Lors de la réécriture en HTTP/1.1, les retours à la ligne sont émis tels quels, scindant la requête et injectant le contenu directement dans la liaison backend.

---

6. Scénarios d'Exploitation dans le Monde Réel

Le HTTP Request Smuggling constitue un démultiplicateur d'impact permettant de concrétiser des attaques à haut niveau de sévérité.

Scénario A : Contournement des Contrôles d'Accès Frontaux

Les proxys d'extrémité restreignent souvent les routes administratives sensibles (telles que /admin) à des adresses IP d'entreprise spécifiques ou exigent des certificats mTLS.

En dissimulant une requête derrière une route publique licite (telle que POST /search), la commande GET /admin HTTP/1.1 échappe totalement aux filtres de routage du frontal. Le backend la reçoit directement sur la liaison interne de confiance et l'exécute sans opposition. De surcroît, l'attaquant peut injecter des en-têtes de confiance interne comme X-Forwarded-For: 127.0.0.1 ou X-Admin-Role: true directement dans la charge utile dissimulée.

Scénario B : Détournement de Requêtes et Vol d'Identifiants

Un attaquant peut injecter une requête incomplète formulée pour capturer la transmission du prochain utilisateur :

POST /submit-comment HTTP/1.1\r\n
Host: target.com\r\n
Content-Length: 1000\r\n
Cookie: attacker_session=xyz\r\n
\r\n
comment=

Lorsqu'un utilisateur émet sa requête suivante :

GET /mon-compte HTTP/1.1\r\n
Host: target.com\r\n
Authorization: Bearer secret_jwt_token_ici\r\n
Cookie: session=session_active_de_la_victime\r\n
\r\n

Le serveur backend concatène la requête de la victime à l'intérieur de la valeur du paramètre comment= jusqu'à concurrence des 1000 octets spécifiés. Les jetons de session, clés JWT et en-têtes d'autorisation de la victime se retrouvent enregistrés dans la base de données et affichés sur l'espace commentaire de l'attaquant.

Scénario C : Empoisonnement du Cache Web

Si le frontal dispose d'une couche de mise en cache HTTP, le request smuggling autorise un empoisonnement persistant du cache affectant l'ensemble des visiteurs.

L'attaquant dissimule une requête provoquant une redirection vers un serveur malveillant juste avant qu'une ressource statique très consultée (comme /static/bundle.js) ne soit réclamée. Le frontal associe la réponse de redirection à la clé de cache du fichier JavaScript légitime. Durant toute la durée de validité du cache (TTL), chaque utilisateur téléchargeant le script applicatif reçoit la charge hostile de l'attaquant, aboutissant à une exécution XSS généralisée.

Scénario D : Amplification de Failles XSS Réfléchies (Zéro-Clic)

Les vulnérabilités XSS réfléchies requièrent ordinairement d'amener la cible à cliquer sur un lien spécialement forgé. Grâce au request smuggling, la faille devient une attaque zéro-clic indétectable.

L'attaquant injecte une requête contenant la charge XSS. Dès qu'un utilisateur quelconque charge n'importe quelle page du site, sa requête est fusionnée avec le fragment d'attaque, et le serveur lui renvoie directement la page avec le script malveillant injecté. La victime est compromise de manière totalement transparente.

---

7. Mesures d'Ingénierie Défensive et Remédiations

La neutralisation pérenne du HTTP Request Smuggling impose des durcissements coordonnés sur l'ensemble de la chaîne de distribution.

1. Déploiement de HTTP/2 ou HTTP/3 de Bout en Bout

La mesure d'architecture la plus radicale consiste à supprimer la conversion de protocole. Configurez vos proxys frontaux pour communiquer en HTTP/2 ou HTTP/3 natif jusqu'aux serveurs d'origine. Dès lors que le tramage binaire est conservé de bout en bout, toute ambiguïté de délimitation de flux disparaît.

2. Application Stricte de la Norme RFC 9112

La spécification RFC 9112 Section 6.1 précise sans équivoque :

• Si une requête comporte simultanément les en-têtes Content-Length et Transfer-Encoding, le composant réseau DOIT rejeter immédiatement la requête avec un code d'erreur 400 Bad Request.
• Ne tentez jamais de réécrire ou de privilégier un en-tête au détriment de l'autre lorsque les deux coexistent. Le rejet précoce met un terme immédiat à toute tentative de désynchronisation.

3. Durcissement des Serveurs Web et Répartiteurs de Charge

Nginx : Utilisez des versions récentes (1.21.1+) qui interdisent les requêtes ambigües et configurez les directives de conformité stricte :

# Validation rigoureuse des en-tetes HTTP
ignore_invalid_headers on;
underscores_in_headers off;

# Configuration du reverse proxy
proxy_http_version 1.1;
proxy_set_header Connection "";

AWS Application Load Balancer (ALB) : Dans les attributs de votre ALB, configurez le mode HTTP Desync Mitigation Mode sur Defensive ou Strictest :

• Monitor : Consigne les anomalies sans les bloquer (vulnérable).
• Defensive : Autorise les flux conformes et bloque les requêtes non standard ou ambigües.
• Strictest : Applique une rigueur absolue vis-à-vis des RFC 7230 et 9112 en rejetant toute requête déviante.

4. Désactivation de la Réutilisation des Connexions Backend

Si des serveurs backend existants ne peuvent pas être mis à jour immédiatement pour éliminer les anomalies d'analyse, désactivez le pooling de connexions TCP persistantes entre le frontal et le backend. L'ouverture d'un socket TCP dédié par requête client supprime physiquement le tampon partagé, rendant le request smuggling impossible entre utilisateurs.

5. Règles Avancées pour Pare-Feu Applicatif (WAF)

Configurez le WAF en périphérie pour rejeter systématiquement :

• Les requêtes où Transfer-Encoding contient des valeurs autres que chunked.
• Les requêtes comportant des espaces ou tabulations avant le caractère deux-points dans les en-têtes.
• Les requêtes avec des en-têtes dupliqués ou contradictoires.
• Les requêtes HTTP/2 véhiculant des en-têtes de connexion proscrits (transfer-encoding, connection, keep-alive).

---

Conclusion

Le HTTP Request Smuggling met en lumière les risques inhérents à l'empilement de protocoles et d'analyseurs syntaxiques hétérogènes au sein d'architectures distribuées. À l'heure où les technologies évoluent vers HTTP/2 et HTTP/3 tout en conservant des microservices backend plus anciens, les frontières de conversion protocolaire constituent un terrain d'attaque privilégié. La mise en conformité stricte avec la RFC 9112, l'adoption de HTTP/2 de bout en bout et des audits réguliers de l'infrastructure réseau sont indispensables pour préserver l'intégrité de vos flux applicatifs.