Applications, sites et API

Particuliers et entreprises

Désynchronisation de requêtes HTTP

HTTP request smuggling

Deux serveurs interprètent différemment les limites d’une même requête.

Révision éditoriale : 23 septembre 2026Comprendre : 2 min · Cas technique et détails : 5 min

Comprendre et agir

À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.

Une situation concrète

Deux équipements se relaient pour recevoir les demandes d’un site. Si l’un croit qu’une demande est terminée alors que l’autre continue de la lire, les échanges peuvent se décaler. Une partie du message d’un attaquant risque alors d’être traitée dans un contexte qui ne lui appartient pas.

Comment cela fonctionne

Le HTTP request smuggling exploite un désaccord sur les limites des requêtes entre des composants web. Il peut perturber le passage entre un proxy, un répartiteur et un serveur. Ce n’est pas simplement une page malveillante : le défaut se situe dans l’interprétation des échanges. Les conséquences varient, du contournement d’un contrôle à la confusion de réponses entre visiteurs.

Comment le piège fonctionne

Deux serveurs lisent un échange
Frontal puis application.
Ils ne découpent pas pareil
Les limites des demandes divergent.
Les échanges se mélangent
Contrôles ou réponses peuvent être détournés.

Ce que vous pouvez faire

Vos premiers réflexes

Si le site affiche la réponse ou le document d’un autre client, signalez l’heure et la page sans poursuivre la consultation. La correction concerne les serveurs du service.

Si vous êtes responsable du service ou de l’organisation

Exploitants : vérifiez ensemble le proxy, le serveur et les conversions HTTP. Rejetez les requêtes ambiguës et testez la chaîne complète dans un environnement isolé.

Le détail qui change toutUne idée reçue à corriger

Activer HTTP/2 sur le frontal ne garantit pas que les échanges vers le serveur utilisent les mêmes règles.

À vous de décider

Mettre à jour seulement l’application suffit-il si deux serveurs se relaient pour lire les demandes ?

Choisissez votre réponse et expliquez pourquoi avant de lire la correction.

Voir la réponse expliquée

Pas nécessairement. Le serveur placé à l’entrée et celui de l’application doivent interpréter les limites des demandes de la même façon. L’équipe technique doit vérifier toute la chaîne.

Analyser un cas technique

Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.

Étude de cas fictive

Deux serveurs ne s’accordent pas sur la fin d’une requête HTTP

Le request smuggling exploite une différence d’interprétation entre deux équipements HTTP. Le frontal pense avoir reçu une requête complète tandis que le serveur suivant voit des octets appartenant à une autre requête. Avec une connexion réutilisée, ce désaccord peut affecter la requête suivante, parfois celle d’un autre utilisateur.

Les en-têtes de longueur et de transfert sont un point classique de désaccord. La conversion entre HTTP/2 et HTTP/1.1 peut aussi introduire une ambiguïté. Le comportement dépend de la combinaison réelle du proxy, de son paramétrage et du serveur d’application ; tester un composant seul ne suffit pas.

Pour comprendre un incident, rapprocher les identifiants de connexion, l’ordre des requêtes et ce que chaque équipement a reçu. Les logs habituels peuvent montrer des requêtes séparées tout en cachant les octets qui ont provoqué le désaccord. Une capture autorisée et limitée sur un environnement de reproduction permet souvent d’établir le problème.

La correction doit conduire les équipements à rejeter les messages ambigus et à fermer les connexions qui ne peuvent plus être interprétées sûrement. Elle doit être vérifiée avec la même chaîne de proxies et les mêmes versions que le service concerné, sans envoyer ces essais au hasard sur un environnement partagé.

Le déroulement en schéma

Qui échange avec quiLisez les échanges de haut en bas. Le point marque le départ et la flèche l’arrivée. Les vérifications après correction ne sont pas la suite de l’attaque.

Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.

Étape

Client de testFlux HTTP

Frontal / WAFPremier parsing

BackendSecond parsing

Client témoinConnexion de test distincte

Action
Message aux limites ambiguës
Client de test vers Frontal / WAF
Trace Capture lab-9
Action
Transmission ou reconstruction
Frontal / WAF vers Backend
Trace Version du protocole
Action sur place
Fin de requête lue à une autre position
Backend
Trace Position 150 sur un serveur, 180 sur l’autre
Action
Requête suivante sur connexion réutilisée
Frontal / WAF vers Backend
Réponse
Association réponse/requête à vérifier
Backend vers Frontal / WAF
Trace Marqueur témoin
Réponse
Contrôler la réponse reçue
Frontal / WAF vers Client témoin
Refus / blocage
Après correction : ambiguïté refusée
Client de test vers Frontal / WAF
Trace Banc de qualification

Comment repérer cette attaque

Indices à rechercher

Des erreurs de protocole apparaissent entre frontal et serveur.
Des réponses semblent associées à la mauvaise demande.
Les journaux de deux composants ne décrivent pas les mêmes limites de requête.

Chercher les divergences entre les requêtes comptées par le frontal et celles traitées par le backend sur une même connexion, les erreurs de lecture HTTP et les réponses attribuées au mauvais échange.

Éléments à croiser

Comparer ce que chaque intermédiaire considère comme une requête complète sur une même connexion. Si les journaux ne gardent pas ce détail, documenter les versions puis confirmer seulement dans un banc d’essai autorisé et isolé.

Limites de l’interprétation

Deux requêtes proches dans le temps ou un HTTP 400 ne démontrent pas une désynchronisation. Ne pas rejouer une requête ambiguë sur un service partagé : elle pourrait toucher un autre utilisateur.

Comment réagir

Mettre à jour ou reconfigurer chaque composant qui interprète les requêtes selon les recommandations du fournisseur. Purger les caches susceptibles de contenir des réponses attribuées au mauvais client. Examiner les sessions et données exposées, puis vérifier à nouveau les connexions persistantes et les conversions de protocoles.

Vérifier la correction

Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.

Les messages ambigus doivent être rejetés par la chaîne complète de proxies et de serveurs.
La fermeture d’une connexion en erreur ne doit pas laisser ses octets réutilisables pour une autre requête.
Les conversions HTTP/2 vers HTTP/1.1 doivent faire partie de la vérification.

À vous de raisonner

Le serveur d’application passe le test seul. Pourquoi faut-il encore vérifier le frontal et la conversion HTTP/2 vers HTTP/1.1 ?

Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.

Comparer avec le raisonnement expliqué

Le défaut vient du désaccord entre composants et peut apparaître lors de la conversion ou de la réutilisation d’une connexion. Vérifiez la chaîne réelle dans un environnement isolé : les messages ambigus doivent être rejetés et une connexion en erreur ne doit pas transmettre ses octets restants à la requête suivante.

Consulter les détails techniques

Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.

Lire les extraits commentés — reconstitution fictive

Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.

start: Position d’octet reconstruite dans le laboratoire fictif, absente d’un access.log nginx ordinaire.
end: La différence de frontière entre frontal et serveur aval explique le cas ; ce n’est pas un champ qu’un outil unique fournit automatiquement.

Lecture comparée de deux parseurs

Journal

Trace synthétique de laboratoire. Les offsets sont des positions dans un flux capturé, pas des champs standards d’un journal nginx.

conn=lab-9 layer=edge    request_index=1 start=0 end=180 framing=content-length
conn=lab-9 layer=backend request_index=1 start=0 end=150 framing=transfer-encoding
conn=lab-9 layer=backend request_index=2 start=150 end=210
conn=lab-9 layer=edge    request_index=2 start=180 end=260
result=boundary_mismatch first_divergence=150

Préparer une collecte dans votre environnement

Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.

nginx — journal d’accès HTTP
Où les trouver
Sur le frontal, dans le fichier désigné par access_log ; son contenu dépend de log_format. L’hébergeur peut devoir fournir cet export.
Quoi relever
Sur le frontal, conserver la version et la configuration HTTP, puis les requêtes, statuts et identifiants de connexion si le format les enregistre. Le journal standard ne donne pas les frontières d’octets interprétées.
Accès et prérequis
Lecture des journaux serveur. Vérifier que la route est journalisée : les temps de réponse et identifiants de requête ne figurent pas forcément dans le format configuré.
Documentation : nginx — journal d’accès HTTP
Service concerné — audit et historique à vérifier
Où les trouver
Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
Quoi relever
Sur le serveur en aval, retrouver l’ordre des requêtes reçues sur la connexion et les réponses associées. Demander les traces du proxy ou serveur HTTP utilisé, pas seulement celles du contrôleur métier.
Accès et prérequis
Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Documentation : Service concerné — audit et historique à vérifier

Si vous pensez être concerné

Si vous utilisez le service

Si le site affiche la réponse ou le document d’un autre client, signalez l’heure et la page sans poursuivre la consultation. La correction concerne les serveurs du service.

Pour l’équipe qui exploite le service

Faites analyser la chaîne complète par l’équipe d’exploitation.
Réduisez les chemins de protocole vulnérables selon les recommandations des fournisseurs.
Examinez les réponses, caches et sessions potentiellement mélangés.

Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.

Sources et repères pour approfondir

OWASP WSTG — HTTP Request Smuggling — owasp.github.io
IETF — RFC 9112, HTTP/1.1 — www.rfc-editor.org