Attaques de désynchronisation : exploiter le request smuggling et la connexion

Comprendre le côté obscur des vulnérabilités d’analyse HTTP

Les attaques de désynchronisation HTTP représentent l’une des classes de vulnérabilités web les plus sophistiquées et dangereuses découvertes ces dernières années. Alors que le request smuggling traditionnel est connu depuis le début des années 2000, les attaques de désync modernes ont évolué pour devenir une menace bien plus complexe et pernicieuse, exploitant des ambiguïtés subtiles dans les implémentations du protocole HTTP pour contourner les contrôles de sécurité, détourner des sessions utilisateur et empoisonner les caches web.

Qu’est-ce qu’une attaque de désynchronisation HTTP ?

La désynchronisation HTTP, communément appelée request smuggling, se produit lorsque le serveur frontal et le serveur arrière ne s’accordent pas sur la fin d’une requête HTTP et le début d’une autre. Cette divergence fondamentale dans l’analyseur crée une vulnérabilité critique que les attaquants peuvent exploiter pour injecter des requêtes malveillantes dans les flux de connexion, « smuggling » ainsi des commandes non autorisées en contournant les mécanismes de sécurité.

La cause principale de la désynchronisation HTTP est une divergence dans l’analyseur, une incompatibilité dans la façon dont différents systèmes interprètent les requêtes HTTP en raison de variations dans leur logique d’analyse. Lorsqu’un attaquant envoie une requête soigneusement conçue contenant des marqueurs de limite ambigus, différents serveurs dans une chaîne proxy peuvent la traiter différemment, créant ainsi des opportunités de request smuggling.

Contrairement au request smuggling traditionnel nécessitant des requêtes malveillantes spécialement conçues, les attaques de désync modernes ont évolué pour inclure des techniques pilotées par le navigateur utilisant des requêtes HTTP/1.1 tout à fait légitimes. Cela ouvre de nouvelles possibilités pour des attaques de request smuggling côté serveur et fait des attaques de désynchronisation côté client une toute nouvelle classe de menace.

La faille fatale du HTTP/1.1

La spécification du protocole HTTP/1.1 contient une faiblesse fondamentale qui rend possibles les attaques de désync : elle fournit deux méthodes différentes pour spécifier les limites de message.

Content-Length vs Transfer-Encoding

La vulnérabilité provient de deux mécanismes d’en-tête concurrents :

En-tête Content-Length : indique la taille exacte du corps du message en octets. Lorsqu’il est présent, le serveur lit exactement ce nombre d’octets et considère la requête comme terminée.

Transfer-Encoding: chunked : permet d’envoyer le corps du message en plusieurs morceaux, chacun précédé de sa taille en hexadécimal. Le message se termine par un chunk de taille zéro.

Les vulnérabilités de request smuggling apparaissent lorsque le serveur frontal et le serveur arrière utilisent des mécanismes différents pour déterminer les limites entre les requêtes. Lorsqu’ils sont tous deux présents dans une même requête, différentes implémentations peuvent privilégier l’un ou l’autre, créant des incohérences exploitables.

Trois principaux vecteurs d’attaque

1. CL.TE (Content-Length / Transfer-Encoding)

Dans cette variante, le serveur frontal traite l’en-tête Content-Length tandis que le serveur arrière utilise l’en-tête Transfer-Encoding. L’attaquant conçoit une requête où :

Le frontal lit un nombre spécifique d’octets basé sur Content-Length
Le backend interprète les mêmes données comme encodage chunked
Les octets restants sont traités comme le début d’une nouvelle requête

POST / HTTP/1.1
Host: site-vulnerable.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

L’en-tête Transfer-Encoding est traité par le serveur backend, qui considère le corps comme encodé en chunks et traite le premier chunk, qui est supposé de taille zéro. Les octets « SMUGGLED » restent non traités et sont interprétés comme une nouvelle requête.

2. TE.CL (Transfer-Encoding / Content-Length)

Cette variante inverse l’ordre de traitement :

Le frontal utilise Transfer-Encoding et traite les chunks
Le backend utilise Content-Length et lit un nombre fixe d’octets
L’attaquant peut smuggler des requêtes supplémentaires dans le « reste » du chunk

POST / HTTP/1.1
Host: site-vulnerable.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

Le frontal traite complètement les deux chunks, mais le serveur backend examine l’en-tête Content-Length et trouve que le corps fait 3 octets, laissant les octets suivants non traités et interprétés comme le début de la requête suivante.

3. TE.TE (Obfuscation de Transfer-Encoding)

Dans ce type d’attaque de request smuggling, le frontal et le backend traitent tous deux la requête avec l’en-tête Transfer-Encoding, mais celui-ci peut être obfusqué de façon à ce qu’un serveur l’ignore alors que l’autre le traite.

Les attaquants exploitent des variations subtiles dans l’analyse des en-têtes :

Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked

Chaque variation représente une légère déviation de la conformité à la spécification HTTP stricte, et différentes implémentations serveur gèrent ces variations de manière incohérente.

Techniques d’exploitation de l’encodage chunked

Abus des extensions de chunk

Une nouvelle technique de request smuggling a été récemment découverte, où les attaquants profitent de comportements d’analyse incohérents entre serveurs proxy frontaux et serveurs applicatifs arrière en utilisant un format de requête ambigu.

HTTP/1.1 permet des extensions optionnelles après la taille du chunk. Ces extensions sont rarement utilisées en pratique, ce qui conduit de nombreuses implémentations à les traiter de manière lâche ou incorrecte. Les attaquants exploitent cela en :

Envoyant une ligne de taille de chunk se terminant par un point-virgule sans nom d’extension
L’analyseur frontal ignore l’extension malformée
L’analyseur backend interprète le saut de ligne après le point-virgule comme la fin de l’en-tête du chunk
L’attaquant insère une seconde requête HTTP après le chunk de taille zéro

POST / HTTP/1.1
Host: site-vulnerable.com
Transfer-Encoding: chunked

0;
GET /admin HTTP/1.1
Host: localhost

Le frontal voit toute la séquence comme une seule requête, tandis que le backend considère le GET /admin comme une requête distincte et valide.

Chunky Chunks et vulnérabilités TE.0

Des recherches récentes ont dévoilé des techniques avancées impliquant des encodages de chunks malformés. 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 basées sur Expect et 0.CL, avec des primes dépassant 350 000 $.

Ces attaques exploitent des cas limites dans le traitement des chunks où les serveurs peuvent : - Accepter des chunks mal formatés - Traiter incorrectement les extensions de chunks - Gérer de manière incohérente la terminaison des chunks

Désynchronisation côté client : attaques pilotées par le navigateur

Une des avancées majeures dans la recherche sur les attaques de désynchronisation est la découverte de la désynchronisation côté client (CSD). Une désynchronisation client est une attaque où le navigateur web de la victime est trompé pour désynchroniser 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 arrière.

Comment fonctionne la désynchronisation côté client

Elle se produit lorsque des serveurs web sont configurés ou mal configurés pour répondre immédiatement à une requête POST ou PUT sans vérifier d’abord le contenu du corps. La chaîne de vulnérabilité implique :

Un attaquant héberge du JavaScript malveillant sur son domaine
La victime visite la page de l’attaquant
Le JavaScript pousse le navigateur de la victime à envoyer une requête spécialement conçue
Le serveur répond immédiatement sans lire tout le corps
Le navigateur réutilise la même connexion pour les requêtes suivantes
Les données résiduelles de la première requête polluent la seconde

Ce type d’attaque est particulièrement dangereux car : - Il fonctionne contre des architectures à serveur unique (pas besoin de séparation front-end/back-end) - Il utilise des requêtes HTTP/1.1 entièrement compatibles navigateur - Il peut contourner les restrictions de politique de même origine - Il permet une attaque CSRF avec capture complète de la réponse

Attaques de désynchronisation basées sur la pause

Lorsque certains serveurs traitent une requête partielle interrompue avant sa réception complète, ils attendent un délai d’attente de 15 secondes avant de fermer la connexion. Au lieu de cela, ils la laissent ouverte pour réutilisation.

Les attaquants exploitent cela en : 1. Envoyant des en-têtes de requête indiquant qu’un corps va suivre 2. Faisant une pause pendant la durée du timeout 3. Envoyant le corps après le timeout 4. Le serveur considère le corps comme une nouvelle requête distincte

Cette technique est particulièrement efficace contre des serveurs de cache comme Varnish qui maintiennent des pools de connexions.

Exploitation des connexions Keep-Alive

Les connexions HTTP keep-alive, conçues pour améliorer la performance en réutilisant les connexions TCP, créent une surface d’attaque supplémentaire pour les vulnérabilités de désynchronisation. Leur utilisation entre serveurs HTTP et proxies est moins courante, mais lorsqu’elle est activée, elle pose un problème de request smuggling.

Détournement de session via Keep-Alive

Lorsque le keep-alive est activé : - Plusieurs requêtes partagent la même connexion TCP - L’état de la connexion persiste entre les requêtes - La désynchronisation de l’analyseur affecte toutes les requêtes suivantes sur cette connexion

Les attaquants peuvent exploiter cela en :

Injection de requête : Smuggler une requête malveillante qui sera exécutée dans le contexte de la requête suivante de l’utilisateur
Poisoning de la file d’attente de réponses : Faire en sorte que la file de réponses du serveur soit désalignée, livrant des réponses destinées à un utilisateur à un autre
Vol d’identifiants : Capturer des tokens d’authentification dans les requêtes légitimes suivantes sur la connexion hijackée

L’astuce consiste à injecter une requête partielle dans le flux et attendre une requête utilisateur normale sur la même connexion backend.

Détournement de session via réutilisation de connexion

Les identifiants utilisés dans une seconde requête sont volés ou hijackés pour une requête smuggled, avec des conséquences très graves : un attaquant peut faire effectuer à un utilisateur des actions POST non désirées avec ses propres droits.

Le flux de l’attaque : 1. L’attaquant envoie une requête incomplète avec un préfixe smuggled 2. La requête légitime de la victime arrive sur la même connexion 3. Les en-têtes (cookies, tokens d’authentification) de la victime sont ajoutés à la requête smuggled 4. L’attaquant accède à la session authentifiée de la victime

Attaques de downgrade HTTP/2

Les infrastructures web modernes utilisent souvent HTTP/2 pour la communication client-serveur, mais rétrogradent vers HTTP/1.1 pour la communication backend. L’encodage chunked est incompatible avec HTTP/2, et la spécification recommande de supprimer ou bloquer toute injection d’en-tête transfer-encoding: chunked.

Attaques H2.CL et H2.TE

Si le serveur frontal ne supprime pas ou ne valide pas correctement les en-têtes lors de la traduction HTTP/2 vers HTTP/1.1, les attaquants peuvent :

Injecter des en-têtes interdits qui survivent à la rétrogradation du protocole
Exploiter l’injection CRLF via le format binaire HTTP/2
Smuggler des requêtes par manipulation de pseudo-en-têtes

Les messages HTTP/2 sont binaires plutôt que textuels, donc les limites de chaque en-tête sont basées sur des décalages explicites plutôt que sur des délimiteurs. Cela signifie que des séquences CRLF peuvent être incluses dans la valeur sans diviser l’en-tête.

Lors de la rétrogradation en HTTP/1.1, ces séquences CRLF intégrées sont à nouveau interprétées comme délimiteurs d’en-tête, permettant l’injection d’en-têtes et le request smuggling.

Impact réel et études de cas

Vulnérabilités majeures révélées

Des recherches récentes ont exposé des vulnérabilités critiques chez de grands fournisseurs de CDN et d’infrastructures web :

De nouvelles classes d’attaques révélées lors de Black Hat ont mis en danger des dizaines de millions de sites web via des vulnérabilités critiques dans les infrastructures CDN majeures, exploitant la faiblesse du HTTP/1.1 sur les limites de requête et la multiplicité des méthodes de longueur.

Ces attaques permettent : - Prise de contrôle du site : compromission totale des applications web - Détournement de session : vol de tokens d’authentification et cookies - Poisoning du cache : injection persistante de contenu malveillant dans les caches CDN

L’incident PayPal

Un chercheur a découvert des vulnérabilités affectant PayPal en utilisant des en-têtes à ligne enveloppée qui rendaient l’en-tête Transfer-Encoding invisible pour le CDN d’Akamai, donnant le contrôle de la page de connexion PayPal et aboutissant à une prime de 20 000 $.

L’attaque utilisait :

Transfer-Encoding:
 chunked

Le wrapping de ligne a conduit Akamai à traiter l’en-tête comme invalide et à l’ignorer, tandis que le serveur backend l’a accepté, créant une désynchronisation CL.TE.

Vulnérabilités du serveur Apache HTTP

Les versions d’Apache HTTP Server jusqu’à 2.4.63 comportaient des vulnérabilités permettant à des attaquants de type man-in-the-middle de réaliser des attaques de désynchronisation HTTP et de détourner des sessions HTTP lors de la mise à niveau TLS.

La vulnérabilité CVE-2025-49812 permettait notamment d’exploiter la fonctionnalité de mise à niveau TLS pour effectuer des attaques de désync, montrant que même les connexions chiffrées peuvent être vulnérables.

Techniques avancées d’exploitation

Poisoning de la file de réponses

Une des conséquences les plus graves du request smuggling est le poisoning de la file de réponses. Lorsqu’une désynchronisation se produit :

La requête smuggled génère une réponse
Cette réponse est mise en file mais livrée au mauvais client
Les réponses suivantes deviennent désalignées
Tous les utilisateurs futurs sur cette connexion reçoivent des réponses destinées à d’autres

Cela peut entraîner : - Exposition de données sensibles - Contamination de sessions entre utilisateurs - Compromission persistante jusqu’à la fermeture de la connexion

Poisoning du cache web via désynchronisation

En utilisant la concaténation de réponses, il est possible de choisir une réponse contenant des en-têtes Content-Length et Cache-Control qui forcent la réponse à être stockée dans le cache.

Les attaquants peuvent : 1. Smuggler une requête HEAD produisant uniquement des en-têtes de réponse 2. L’en-tête Content-Length indique la taille d’une réponse GET complète 3. Le proxy concatène la réponse suivante (d’une requête d’un autre utilisateur) 4. La réponse concaténée est mise en cache avec le contenu injecté 5. Tous les utilisateurs suivants reçoivent la réponse empoisonnée du cache

Exploitation de la méthode TRACE

La méthode TRACE nécessite une réponse du serveur, et bien qu’elle semble peu utilisée en production, le smuggling peut contourner les règles de pare-feu et envoyer un message TRACE directement au backend même si la méthode est interdite.

L’attaque permet un XSS réfléchi via désync :

POST / HTTP/1.1
Host: vulnérable.com
Content-Length: 6
Transfer-Encoding: chunked

0

TRACE / HTTP/1.1
Host: vulnérable.com
SomeHeader: scriptalert(1)/script

La réponse TRACE reflète le script injecté, qui est ensuite livré à l’utilisateur suivant sur cette connexion.

Détection et identification

Techniques de détection manuelle

Le moyen le plus simple de tester le comportement de désynchronisation côté client est d’envoyer une requête où le Content-Length spécifié est supérieur à la taille réelle du corps. Si la requête bloque ou expire, le serveur attend les octets restants. Si vous obtenez une réponse immédiate, vous avez potentiellement un vecteur CSD.

Workflow de détection : 1. Identifier les connexions réutilisables : rechercher des serveurs supportant HTTP keep-alive 2. Tester l’analyse des limites : envoyer des requêtes avec des en-têtes conflictuels 3. Observer les différences de timing : des réponses retardées indiquent un potentiel de désynchronisation 4. Vérifier la concaténation de requêtes : surveiller si des parties d’une requête apparaissent dans une autre

Outils automatisés et scans

Plusieurs outils peuvent aider à identifier les vulnérabilités de désynchronisation :

Extension Burp Suite HTTP Request Smuggler : détection automatisée des vulnérabilités CL.TE, TE.CL, et TE.TE
smuggler.py : outil en ligne de commande pour scanner en masse
Burp Scanner : inclut des capacités de détection de désynchronisation

Les deux, Burp Scanner et l’extension Request Smuggler, peuvent automatiser une grande partie du processus, mais connaître la méthode manuelle permet de mieux comprendre le fonctionnement.

Tests via navigateur

Pour tester la désynchronisation côté client :

Utilisez un navigateur sans proxy Burp Suite, Chrome étant recommandé pour ses outils de développement utiles, notamment l’option Preserve log et la colonne Connection ID pour suivre les connexions.

Exemple avec Fetch API :

fetch('https://site-vulnerable.com', {
    method: 'POST',
    body: 'POST /internal HTTP/1.1\r\nHost: site-vulnerable.com\r\n\r\n',
    headers: {
        'Content-Length': '200'
    }
});

Stratégies de défense et mitigations

Solutions architecturales

1. HTTP/2 de bout en bout

Pour éviter les vulnérabilités de request smuggling, utilisez HTTP/2 en fin de chaîne et désactivez la rétrogradation si possible, car HTTP/2 utilise un mécanisme robuste pour déterminer la longueur des requêtes et est intrinsèquement protégé contre le request smuggling.

HTTP/2 élimine les vulnérabilités de désync en : - Utilisant un encodage binaire plutôt que l’analyse textuelle - Supprimant l’ambiguïté sur les limites de message - Éliminant les en-têtes Content-Length et Transfer-Encoding - Imposant des règles strictes de multiplexage

2. Architecture d’analyse unifiée

Fastly élimine la désynchronisation HTTP par une uniformité architecturale en utilisant une seule implémentation d’analyse dans toute la pile, évitant ainsi les incohérences.

Principes clés : - Utiliser un seul parseur HTTP dans toute la stack - Éviter de mélanger différentes versions de serveurs - Valider strictement chaque requête à chaque étape - Rejeter immédiatement les requêtes ambiguës

Bonnes pratiques de configuration

Désactiver la réutilisation des connexions

Pour le backend : - Ne pas réutiliser les connexions entre front-end et back-end - Établir des connexions fraîches pour chaque requête - Fermer immédiatement après réponse

Validation stricte des en-têtes

Rejeter les requêtes contenant à la fois Content-Length et Transfer-Encoding
Respecter strictement la RFC
Bloquer les variations d’en-têtes obfusqués
Normaliser les requêtes avant transfert

Renforcement du serveur

Configuration Apache :

# Rejeter les requêtes ambiguës
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

# Limiter le keep-alive
MaxKeepAliveRequests 100
KeepAliveTimeout 5

# Application stricte du protocole
HttpProtocolOptions Strict

Configuration Nginx :

# Désactiver les vecteurs de request smuggling
ignore_invalid_headers on;
client_body_buffer_size 1k;
client_header_buffer_size 1k;
client_max_body_size 1k;

Règles de WAF

Mettre en place des règles WAF pour : - Détecter et bloquer les en-têtes en double - Identifier les anomalies d’encodage chunked - Surveiller les motifs d’en-têtes suspects - Alerter sur des tailles de requêtes inhabituelles

Suite à une divulgation responsable, des correctifs de sécurité complets ont été déployés, assurant une protection complète contre les vulnérabilités de request smuggling.

Surveillance et détection

Mettre en place une surveillance pour : - Les schémas de connexion inhabituels - Les requêtes avec des longueurs conflictuelles - Les séquences d’encodage chunk anormales - Le désalignement de la file de réponses - Les anomalies de comportement du cache

L’avenir des attaques de désynchronisation

Nouvelles techniques d’attaque

La recherche continue à découvrir de nouvelles techniques :

Attaques 0.CL : exploitant les en-têtes Content-Length de longueur zéro
Manipulation de l’en-tête Expect : utilisant le mécanisme 100-Continue
Chaînage de protocoles : combinant HTTP/2, HTTP/1.1 et WebSocket

Ce sujet reste peu étudié, et les chercheurs espèrent que cette publication inspirera de nouvelles techniques et exploits dans les années à venir.

Réponse de l’industrie

Les grands fournisseurs d’infrastructures prennent des mesures :

Implémentation d’une logique d’analyse plus stricte
Déploiement d’architectures d’analyse unifiée
Amélioration des scans automatisés de vulnérabilités
Augmentation des primes bug bounty pour la découverte de désynchronisations

Alors que certains load balancers ne sont pas encore corrigés ou que nginx ne possède pas de protection 0.CL, l’application de normes strictes élimine toute classe d’attaque.

Conclusion

Les attaques de désynchronisation HTTP représentent une évolution sophistiquée du request smuggling exploitant des ambiguïtés fondamentales du protocole HTTP/1.1. Par la manipulation de l’encodage chunked, l’exploitation des connexions keep-alive et des techniques pilotées par le navigateur, les attaquants peuvent contourner la sécurité, détourner des sessions et compromettre des applications web à grande échelle.

Ces attaques sont particulièrement dangereuses car : - Elles ciblent l’infrastructure plutôt que la logique applicative - Elles contournent les mécanismes de sécurité traditionnels - Elles permettent une compromission persistante via l’empoisonnement du cache - Elles peuvent toucher des applications bien sécurisées

Les organisations doivent adopter une approche de défense en profondeur combinant changements architecturaux (adoption de HTTP/2), application stricte des règles d’analyse, isolation des connexions et surveillance continue pour se protéger contre cette menace en évolution.

Alors que l’infrastructure web continue d’évoluer, il est crucial de rester informé des dernières recherches sur la désynchronisation et de maintenir des systèmes à jour, bien configurés, pour préserver la sécurité des applications. La communauté de recherche continue à découvrir de nouvelles variantes d’attaque, rendant la vigilance constante et la défense proactive essentielles dans toute stratégie de sécurité.