HTTP/2 Desync : la prochaine génération d’attaques de Request Smuggling

Découvrez comment le framing binaire de HTTP/2 introduit de nouveaux vecteurs de smuggling qui contournent les défenses traditionnelles. Du smuggling H2C à l’abus des noms d’en-tête, ces attaques fonctionnent lorsque les protections HTTP/1.1 ne s’appliquent pas.

Introduction : La fausse promesse de la sécurité HTTP/2

Le request smuggling en HTTP a sévi sur les applications web depuis 2005, exploitant les incohérences dans l’interprétation des frontières de requête par les serveurs. Avec l’émergence de HTTP/2 et son protocole de framing binaire, beaucoup pensaient que ces vulnérabilités disparaîtraient. Après tout, HTTP/2 utilise des champs de longueur explicites pour chaque trame, éliminant l’ambiguïté présente dans HTTP/1.1 avec Content-Length et Transfer-Encoding.

Malheureusement, cet optimisme s’est avéré prématuré. La rétrogradation de HTTP/2 — où un serveur frontal parle en HTTP/2 avec les clients mais réécrit les requêtes en HTTP/1.1 avant de les transmettre aux serveurs back-end — permet une gamme d’attaques, notamment le request smuggling. Cette traduction de protocole crée un vide dangereux où les garanties de sécurité de HTTP/2 s’évaporent, laissant les attaquants sophistiqués exploiter les joints entre protocoles.

Cet article explore l’évolution du request smuggling à l’ère de HTTP/2, en examinant comment les attaquants tirent parti du smuggling H2C, de l’injection CRLF, et de la manipulation des en-têtes pour contourner les contrôles de sécurité modernes.

Comprendre les fondamentaux du HTTP/2 Request Smuggling

Pourquoi HTTP/2 était censé être à l’abri

Les requêtes HTTP/2 ne sont pas envoyées sous forme de messages en texte clair mais converties en format binaire. La requête est représentée sous forme de “frames”, chaque frame ayant un champ de longueur explicite indiquant au serveur combien de bytes lire. Cette architecture élimine l’ambiguïté entre Content-Length et Transfer-Encoding qui rendait HTTP/1.1 vulnérable.

Le request smuggling n’est pas vraiment une vulnérabilité du protocole HTTP/1.1 en soi, mais l’existence de deux manières différentes de spécifier la fin d’une requête (Content-Length et Transfer-Encoding) laisse la place à des implémentations de proxy HTTP mal conçues. La mécanique de longueur unique et non ambiguë de HTTP/2 devrait théoriquement prévenir ces attaques.

Le problème de la rétrogradation

En réalité, les environnements purement HTTP/2 restent relativement rares. Bien que HTTP/2 soit largement utilisé, certains serveurs back-end legacy utilisent encore HTTP/1.1, car le protocole plus récent est encore récent dans les déploiements en entreprise. Cela crée des environnements mixtes où des front-ends HTTP/2 communiquent avec des back-ends HTTP/1.1.

La spécification HTTP/2 recommande que toute requête contenant l’en-tête Transfer-Encoding soit soit supprimée, soit bloquée par le serveur frontal. Mais si ce dernier ignore cette recommandation et laisse passer la requête avec l’en-tête, il rétrograde la requête en HTTP/1.1 et la transmet à un serveur back-end supportant le chunked encoding. C’est ici que les vulnérabilités de request smuggling réémergent.

Vecteurs d’attaque : désynchronisation H2.CL et H2.TE

Attaques HTTP/2 vers Content-Length (H2.CL)

Dans les attaques H2.CL, le serveur HTTP/2 frontal transmet un en-tête Content-Length qui ne devrait pas exister dans le contexte HTTP/2. Lors de la rétrogradation en HTTP/1.1, le serveur back-end utilise cet en-tête pour déterminer les frontières de la requête, créant des opportunités de smuggling.

En redirigeant des inclusions JavaScript, des attaquants pourraient exécuter du JavaScript malveillant pour compromettre des comptes utilisateurs et voler mots de passe et numéros de carte bancaire. En répétant cette attaque en boucle, ils pourraient progressivement compromettre tous les utilisateurs actifs du site, sans interaction utilisateur. Netflix a connu cette vulnérabilité, tracée via leur proxy Zuul jusqu’à Netty, aboutissant à la CVE-2021-21295 et une prime maximale de 20 000 $.

Attaques HTTP/2 vers Transfer-Encoding (H2.TE)

Le RFC stipule que tout message contenant des champs d’en-tête spécifiques à la connexion doit être considéré comme malformé. Un de ces champs est Transfer-Encoding. Le Load Balancer d’Amazon Web Services a échoué à respecter cette règle et a accepté des requêtes contenant Transfer-Encoding, permettant l’exploitation de presque tous les sites utilisant cette vulnérabilité via un désync H2.TE.

Ces attaques montrent comment même de grands fournisseurs cloud peuvent mal implémenter HTTP/2, laissant des millions de sites vulnérables.

Smuggling H2C : la technique d’upgrade de connexion en clair

Qu’est-ce que le H2C Smuggling ?

Le smuggling H2C représente l’une des techniques d’attaque HTTP/2 les plus innovantes découvertes récemment. Dévoilée par des chercheurs Bishop Fox en septembre 2020, la technique d’abus du H2C en clair permet aux front-ends non compatibles H2C de créer un tunnel vers les systèmes back-end, permettant aux attaquants de contourner les règles de réécriture front-end et d’exploiter les en-têtes HTTP internes.

L’upgrade des connexions HTTP/1.1 vers HTTP/2 moins connu (h2c) peut permettre de contourner les contrôles d’accès des edge-proxy. Cette technique a été reconnue comme la principale technique de hacking web de 2020 par le vote annuel de la communauté de sécurité PortSwigger.

Fonctionnement de l’attaque

L’attaque exploite la capacité d’upgrader une connexion HTTP/1.1 en HTTP/2. Le smuggling h2c permet aux attaquants de contourner les contrôles proxy en transmettant des requêtes d’upgrade HTTP/1.1 via TLS, qui vont directement aux serveurs back-end. Les upgrades h2c effectués via TLS violent en réalité la spécification du protocole, mais de nombreux serveurs les acceptent quand même.

h2cSmuggler fait passer le trafic HTTP en contournant les configurations proxy_pass non sécurisées en établissant des communications HTTP/2 en clair avec des back-ends compatibles h2c, permettant de contourner les règles de proxy et contrôles d’accès.

Impact réel

Après investigation de l’impact du H2C smuggling sur diverses cibles de bug bounty, des chercheurs ont découvert divers contournements d’authentification, de routage, et de WAF sur plusieurs fournisseurs cloud. Même ceux initialement supposés immunisés se sont révélés vulnérables lorsque la technique a été appliquée plus en profondeur.

Avec ce type de request smuggling, il est possible d’envoyer autant de requêtes que souhaité via multiplexage HTTP/2. Le request smuggling permet une large gamme d’attaques, notamment la falsification d’en-têtes internes, l’accès à des endpoints administratifs restreints, et parfois le SSRF sur l’en-tête Host, permettant une progression dans le réseau.

Injection CRLF dans les en-têtes HTTP/2

La faille du protocole binaire

La nature binaire de HTTP/2 devrait empêcher les attaques CRLF (Carriage Return Line Feed) qui affectent HTTP/1.1. Cependant, en raison de cette nature binaire, il existe plusieurs moyens de contourner ces protections. L’injection CRLF permettant de faire du header smuggling en HTTP/2 est un vecteur principal.

La spécification HTTP/2 pour les valeurs d’en-tête indique qu’un champ ne doit pas contenir le caractère nul (ASCII NUL, 0x00), le saut de ligne (ASCII LF, 0x0a), ou le retour chariot (ASCII CR, 0x0d). Si ces caractères sont présents dans une valeur d’en-tête, la requête doit être considérée comme malformée et traitée ou rejetée. Beaucoup de serveurs ne font pas respecter cette règle.

Technique d’exploitation

L’injection de Transfer-Encoding doit être insérée dans la valeur d’un en-tête arbitraire avec une séquence CRLF, par exemple Foo: bar\r\nTransfer-Encoding: chunked. Un doublon de cet en-tête doit également être présent dans la requête.

Lors de la rétrogradation de la requête HTTP/2 en HTTP/1.1, le serveur interprète littéralement les caractères CRLF, créant de nouvelles lignes d’en-tête qui n’existaient pas dans la requête HTTP/2 originale. Le serveur back-end voit alors un en-tête Transfer-Encoding qui a contourné toutes les protections front-end.

Lors de l’exploitation du request smuggling HTTP/2 vers HTTP/1.1, l’injection CRLF est souvent nécessaire. Contrairement à HTTP/1.1, qui est basé sur du texte, HTTP/2 est un protocole binaire et n’utilise plus les mêmes délimiteurs pour structurer les requêtes. Lorsqu’un serveur frontal convertit une requête HTTP/2 en HTTP/1.1, il peut interpréter certains caractères binaires comme des sauts de ligne, permettant à un attaquant d’injecter des en-têtes supplémentaires et de manipuler la requête réécrite.

Empoisonnement de la file de réponses et détournement de session

Comprendre la désynchronisation des réponses

Une des conséquences les plus graves de la désynchronisation est l’empoisonnement de la file de réponses. Lorsqu’une désynchronisation se produit, cela peut entraîner la fuite de données sensibles, la contamination des sessions entre utilisateurs, et une compromission persistante jusqu’à la fermeture de la connexion.

Vol de session en pratique

En utilisant la désynchronisation de la file de réponses avec les techniques classiques de request smuggling HTTP/1.1, les attaquants peuvent capturer des requêtes de véritables utilisateurs, permettant la prise de contrôle de comptes et l’accès à des informations sensibles.

L’attaque se déroule ainsi : un attaquant envoie une requête soigneusement conçue qui provoque la désynchronisation, puis les requêtes légitimes suivantes de l’utilisateur deviennent ajoutées en préfixe contrôlé par l’attaquant. L’attaquant peut ainsi capturer des cookies de session, des tokens d’authentification, et d’autres données sensibles.

Désynchronisation côté client : une nouvelle frontière

Au-delà des attaques serveur-à-serveur

Une des avancées récentes majeures dans la recherche sur les attaques de désynchronisation est la découverte de la désynchronisation côté client (CSD). Une attaque CSD consiste à tromper le navigateur de la victime pour qu’il désynchronise sa connexion avec le site vulnérable, différente des attaques classiques de request smuggling qui désynchronisent la connexion entre un serveur frontal et un serveur back-end.

Cette évolution signifie que même des architectures conçues pour isoler les connexions utilisateur peuvent être vulnérables, car l’attaque cible la propre connexion du client plutôt que l’infrastructure partagée du serveur.

Techniques avancées : abus des noms d’en-tête et astuces d’encodage

Exploiter la validation faible des en-têtes

Cloudflare a appliqué une validation plus faible après le 100e en-tête avant de transmettre la requête à un serveur en amont. Si un serveur HTTP accepte et parse des en-têtes se terminant par une tabulation ou un espace, cela peut entraîner un désalignement de requête/réponse en HTTP/1.1 causé par la requête initiale de l’attaquant.

Bien que les deux-points, les sauts de ligne, et les caractères A-Z soient toujours interdits dans les en-têtes smuggled, les espaces et tabulations suffisent dans certains cas. Pour déclencher un désalignement HTTP dans des connexions keep-alive, un attaquant peut utiliser quelque chose comme “transfer-encoding : chunked” (avec un espace avant le deux-points).

Variantes d’attaque émergentes

La recherche continue à découvrir de nouvelles techniques de désynchronisation : attaques 0.CL exploitant des Content-Length à longueur zéro, manipulation de l’en-tête Expect via le mécanisme 100-Continue, et chaînage de protocoles combinant HTTP/2, HTTP/1.1, et upgrades WebSocket. Ce sujet reste peu exploré, avec des professionnels de la sécurité découvrant constamment de nouvelles techniques d’exploitation.

Vulnérabilités récentes et exemples concrets

CVEs notables

Plusieurs vulnérabilités critiques illustrent la menace persistante :

CVE-2023-25690 affecte Apache HTTP Server où les règles de rewrite de mod_proxy pouvaient être chaînées pour du request splitting et smuggling, corrigé dans la version 2.4.56. CVE-2023-25950 concerne HAProxy 2.⁷⁄₂.6 où le parser HTX maltraitait les requêtes pipelined. CVE-2022-41721 affecte le MaxBytesHandler de Go, où des octets résiduels dans le corps étaient interprétés comme des trames HTTP/2, permettant du cross-protocol smuggling.

Les versions d’Apache HTTP Server jusqu’à 2.4.63 comportaient des vulnérabilités permettant à des attaquants man-in-the-middle de réaliser des attaques de désynchronisation HTTP et de détourner des sessions HTTP lors des upgrades TLS. La vulnérabilité CVE-2025-49812 a spécifiquement permis d’exploiter la fonctionnalité d’upgrade TLS pour réaliser des attaques de désynchronisation, montrant que même les connexions chiffrées peuvent être vulnérables.

Impact sur les bug bounty

En 2024, la résilience face aux vulnérabilités TE.0 et chunks funky est devenue critique, avec en 2025 la confirmation de l’immunité aux attaques Expect et 0.CL, avec des primes dépassant 350 000 $. Ces montants importants reflètent la gravité des vulnérabilités de désynchronisation HTTP/2.

Outils de détection et de test

Approches professionnelles

Les requêtes TRACE peuvent être très utiles pour analyser une vulnérabilité de smuggling. La réponse montre exactement ce qui est reçu par le back-end, donnant des informations sur les en-têtes modifiés ou ajoutés par le proxy, et même sur les modifications de protocole, comme la rétrogradation de HTTP/2 en HTTP/1.1, qui est à l’origine de nombreuses vulnérabilités de désynchronisation.

Plusieurs outils aident les professionnels de la sécurité à identifier ces vulnérabilités :

Burp Request Smuggler depuis v1.26 teste automatiquement H2.TE/H2.CL et le support ALPN caché — activez “HTTP/2 probing” dans les options de l’extension. h2cSmuggler est une preuve de concept en Python par Bishop Fox pour automatiser l’attaque d’upgrade en clair.

L’outil open-source http2smugl permet aux ingénieurs, DevOps, et équipes de sécurité de vérifier gratuitement leurs load balancers pour des vulnérabilités de request smuggling HTTP/2, utile aussi pour la recherche bug bounty et la découverte de nouvelles vulnérabilités.

Stratégies de prévention et de mitigation

Défense principale : HTTP/2 de bout en bout

Pour éviter le request smuggling, utilisez HTTP/2 de bout en bout et désactivez la rétrogradation si possible. HTTP/2 dispose d’un mécanisme robuste pour déterminer la longueur des requêtes et, lorsqu’il est utilisé de bout en bout, il est intrinsèquement protégé contre le request smuggling.

Assurez-vous d’utiliser des connexions HTTP/2 de bout en bout et de ne pas rétrograder. Si vous configurez ou gérez un serveur HTTP/2, surtout s’il supporte la rétrogradation, rejetez les requêtes avec des en-têtes excessifs spécifiant la taille du corps.

En cas d’impossibilité de rétrograder

Si la rétrogradation HTTP est inévitable, validez la requête réécrite selon la spécification HTTP/1.1. Des mesures supplémentaires incluent :

Rejeter les requêtes ambiguës contenant à la fois Content-Length et Transfer-Encoding, côté frontal et back-end. Éviter de réutiliser les connexions entre le serveur frontal et le back-end pour empêcher la persistance de requêtes désynchronisées. Déployer un WAF capable de détecter et bloquer les tentatives de request smuggling. Harmoniser la stack technologique en utilisant le même serveur pour le front et le back pour éviter les différences d’analyse.

Mitigations spécifiques pour H2C

La mitigation pour le H2C est simple — supprimer ou coder en dur l’en-tête Upgrade au niveau du edge, sauf pour WebSockets.

Maintenir une stratégie de défense en profondeur, réduire l’impact des en-têtes smuggled dans votre architecture, et être prêt à rejeter les requêtes suspectes côté back-end aidera à réduire l’impact des nouvelles techniques d’attaque.

Prévention de l’injection CRLF

Une autre stratégie consiste à bloquer tout en-tête contenant des séquences spécifiques, comme CRLF. Les serveurs doivent appliquer strictement la règle du protocole HTTP/2 interdisant les caractères de retour chariot et saut de ligne dans les valeurs d’en-tête.

Perspectives futures et tendances émergentes

La persistance de HTTP/1.1

HTTP/1.1 reste particulièrement vulnérable au request smuggling car ses délimitations de message peuvent être exprimées de plusieurs façons. Les RFC définissent des règles strictes, mais en pratique, de nombreux serveurs ont été construits à différentes époques avec des interprétations variées. Pour rester compatibles avec les clients réels, les implémentations acceptent souvent des requêtes légèrement malformées plutôt que de les rejeter.

Le request smuggling demeure courant car beaucoup d’applications modernes s’appuient encore sur des stacks HTTP/1.1 legacy plutôt que sur le successeur actuel, HTTP/2. De plus, la correction est souvent difficile en raison du support incohérent du protocole HTTP dans différents environnements serveur.

Recherche continue

Les attaques de smuggling, y compris la désynchronisation, sont des menaces majeures pour le web moderne et restent pertinentes pour HTTP/1.1 et HTTP/2. À mesure que les chercheurs étudient l’interaction entre protocoles, de nouvelles voies d’attaque émergeront probablement.

Conclusion

Les attaques de désynchronisation HTTP/2 représentent une évolution sophistiquée du request smuggling exploitant l’écart entre les versions de protocole. Bien que le framing binaire de HTTP/2 ait été conçu pour éliminer l’ambiguïté qui permettait les attaques classiques, la pratique répandue de rétrograder les requêtes en HTTP/1.1 pour la communication back-end réintroduit ces vulnérabilités.

Les organisations doivent comprendre qu’adopter simplement HTTP/2 en périphérie ne garantit pas une protection complète. Une sécurité réelle nécessite une implémentation end-to-end de HTTP/2, une validation stricte des en-têtes, une gestion prudente des upgrades de protocole, et une vigilance continue face aux nouvelles variantes d’attaque.

À mesure que l’infrastructure web évolue, l’interaction entre différentes versions de protocoles restera une cible privilégiée pour les attaquants. Les équipes de sécurité doivent prioriser l’élimination des rétrogradations HTTP quand cela est possible, mettre en œuvre une validation robuste des en-têtes, et suivre l’actualité des recherches dans ce domaine en rapide développement.

Points clés :

La rétrogradation HTTP/2 réintroduit des vulnérabilités de request smuggling que HTTP/2 pur aurait empêchées
Le H2C smuggling contourne les contrôles proxy en exploitant les mécanismes d’upgrade en clair
L’injection CRLF dans les en-têtes HTTP/2 peut smuggler des en-têtes supplémentaires en contournant la validation front-end
La solution la plus efficace est une implémentation end-to-end de HTTP/2
La recherche continue à découvrir de nouvelles techniques d’exploitation dans l’interaction des protocoles