Applications, sites et API

Particuliers et entreprises

Désynchronisation de requêtes HTTP

HTTP request smuggling

Deux serveurs ne s’accordent pas sur l’endroit où une requête web se termine.

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

Comprendre et agir

Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.

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

Une requête web peut passer par plusieurs composants, comme un proxy, un répartiteur et un serveur. Si ces composants ne s’accordent pas sur l’endroit où une requête se termine, un attaquant peut exploiter ce décalage. C’est le HTTP request smuggling, ou désynchronisation de requêtes HTTP. Le défaut peut permettre de contourner un contrôle ou de mélanger les réponses envoyées aux visiteurs. Il se situe dans la lecture des échanges entre serveurs.

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

Examinez ensemble le proxy, le serveur et les conversions entre versions HTTP. Rejetez les requêtes ambiguës et testez tout le parcours dans un environnement isolé.

Un point à vérifierUne idée reçue à corriger

Même si le premier serveur accepte HTTP/2, les serveurs suivants peuvent lire les échanges avec d’autres règles.

À vous de décider

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

Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.

Voir la réponse expliquée

Pas forcément. Le serveur d’entrée et celui de l’application doivent s’accorder sur le début et la fin de chaque requête. L’équipe technique doit vérifier tous les composants du parcours.

Analyser un cas technique

Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».

Étude de cas fictive

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

Deux équipements HTTP ne lisent pas les limites d’une requête de la même façon. Le premier la considère comme complète ; le suivant interprète une partie des octets comme une autre requête. Si la connexion est réutilisée, le décalage peut perturber la demande suivante, y compris celle d’un autre utilisateur. C’est le request smuggling.

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.

Quelles informations comparer

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é.

Ce que ces indices ne permettent pas de conclure

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

L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.

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 ?

Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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

Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.

Lire les extraits commentés (reconstitution fictive)

Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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

Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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 comprendre votre situation et trouver de l’aide : 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