* Vous travaillez dans une **entreprise de cybersécurité** ? Vous souhaitez voir votre **entreprise annoncée dans HackTricks** ? ou souhaitez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Cette vulnérabilité se produit lorsqu'une **désynchronisation** entre les **proxys frontaux** et le **serveur back-end** permet à un **attaquant** d'envoyer une **requête HTTP** qui sera **interprétée** comme une **seule requête** par les **proxys frontaux** (équilibrage de charge/reverse-proxy) et **comme 2 requêtes** par le **serveur back-end**.\
Cela permet à un utilisateur de **modifier la prochaine requête qui arrive au serveur back-end après la sienne**.
Le **proxy frontal** (un équilibrage de charge / reverse-proxy) **traite** l'en-tête _**content-length**_ ou l'en-tête _**transfer-encoding**_ et le **serveur back-end****traite l'autre** en provoquant une **désynchronisation** entre les 2 systèmes.\
Cela peut être très critique car **un attaquant pourra envoyer une requête** au proxy inverse 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 **venait du client suivant** et la **requête réelle** de ce client fera **partie** de la **requête injectée**.
* **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 par le 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 **prochain fragment**. Le **fragment** 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 **fragment 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 de la requête Smuggling.
Ainsi, les attaques de requête smuggling consistent à placer à la fois l'en-tête `Content-Length` et l'en-tête `Transfer-Encoding` dans une seule requête HTTP et à les manipuler de manière à ce que les serveurs frontal et back-end traitent la requête différemment. La manière exacte dont cela est fait dépend du comportement des deux serveurs :
* **TE.TE** : les serveurs frontal et back-end prennent tous deux en charge l'en-tête `Transfer-Encoding`, mais l'un des serveurs peut être amené à ne pas le traiter en obfusquant l'en-tête d'une manière ou d'une autre.
Ici, le serveur frontal utilise l'en-tête **`Content-Length`** et le serveur back-end utilise l'en-tête **`Transfer-Encoding`**. Nous pouvons effectuer une attaque simple de requête smuggling HTTP de la manière suivante :
Notez comment `Content-Length` indique que la longueur de la requête est de **30 octets** (_rappelez-vous que HTTP utilise une nouvelle ligne, donc 2 octets pour chaque nouvelle ligne_), donc le proxy inverse **enverra la requête complète** au serveur back-end, et le serveur back-end traitera l'en-tête `Transfer-Encoding`, laissant `GET /404 HTTP/1.1` comme le **début de la prochaine requête** (au fait, la prochaine requête sera ajoutée à `Foo:x<La prochaine requête commence ici>`).
Ici, le serveur frontal utilise l'en-tête `Transfer-Encoding` et le serveur arrière utilise l'en-tête `Content-Length`. Nous pouvons effectuer une attaque simple de détournement de requête HTTP comme suit :
Dans ce cas, le **reverse-proxy** va **envoyer la requête complète** vers l'**arrière-plan** comme l'indique l'en-tête **`Transfer-Encoding`**. Cependant, l'**arrière-plan** va traiter uniquement les **`7b`** (4 octets) comme indiqué dans `Content-Length`. Par conséquent, la requête suivante sera celle qui commence par `GET /404 HTTP/1.1`.
Notez que même si l'attaque doit se terminer par un `0`, la requête suivante sera ajoutée en tant que valeurs supplémentaires du paramètre **x**.\
Notez également que la longueur du contenu de la requête intégrée indiquera la longueur de la prochaine requête qui sera ajoutée au paramètre **x**. Si elle est trop petite, seuls quelques octets seront ajoutés, et si elle est trop grande (plus grande que la longueur de la prochaine requête), une erreur sera générée pour la requête suivante.
### Vulnérabilités TE.TE
Ici, les serveurs frontal et arrière prennent en charge tous deux l'en-tête `Transfer-Encoding`, mais l'un des serveurs peut être amené à ne pas le traiter en obfusquant l'en-tête d'une certaine manière.\
Il existe potentiellement d'innombrables façons d'obfusquer l'en-tête `Transfer-Encoding`. Par exemple :
Selon le serveur (reverse-proxy ou arrière-plan) qui **arrête de traiter** l'en-tête **TE**, vous trouverez une vulnérabilité **CL.TE** ou une vulnérabilité **TE.CL**.
## Découverte de la détournement de requête HTTP
### Découverte des vulnérabilités CL.TE en utilisant des techniques de temporisation
Si une application est vulnérable à la variante CL.TE du détournement de requête, l'envoi d'une requête comme celle-ci provoquera souvent un délai :
Étant donné que le serveur frontal utilise l'en-tête `Content-Length`, il ne transmettra qu'une partie de cette requête, en omettant le `0`. Le serveur arrière utilise l'en-tête `Transfer-Encoding`, traite le premier fragment, puis attend l'arrivée du fragment suivant. Cela entraînera un retard observable.
Parfois, au lieu d'obtenir un délai d'expiration, vous recevez une erreur 400 mauvaise requête de l'hôte final, comme dans le scénario suivant, où une charge utile CL.TE est envoyée :
Si une application est vulnérable à la variante TE.CL de l'attaque de détournement de requête, l'envoi d'une requête comme celle-ci provoquera souvent un retard :
Depuis que le serveur frontal utilise l'en-tête `Transfer-Encoding`, il ne transmettra qu'une partie de cette requête, en omettant le `X`. Le serveur arrière utilise l'en-tête `Content-Length`, attend plus de contenu dans le corps du message et attend l'arrivée du contenu restant. Cela entraînera un retard observable.
Une fois que vous avez constaté que les **techniques de synchronisation fonctionnent**, vous devez **sonder** si vous pouvez **modifier les requêtes des autres clients**.\
La manière la plus simple de le faire est d'essayer de corrompre vos propres requêtes, par exemple en faisant une demande pour `/` qui renvoie un code 404.\
Dans les [Exemples de base](./#basic-examples), nous avons déjà vu des exemples de `CL.TE` et `TE.CL` qui montrent comment corrompre une requête de client pour demander `/404`, provoquant une réponse 404 lorsque le client demande une autre ressource.
Certaines considérations importantes doivent être prises en compte lors de la tentative de confirmation des vulnérabilités de l'attaque de requête en interférant avec d'autres requêtes :
* La requête "d'attaque" et la requête "normale" doivent être envoyées au serveur en utilisant des connexions réseau différentes. L'envoi des deux requêtes via la même connexion ne prouvera pas l'existence de la vulnérabilité.
* La requête "d'attaque" et la requête "normale" doivent utiliser la même URL et les mêmes noms de paramètres, dans la mesure du possible. Cela est dû au fait que de nombreuses applications modernes routent les requêtes frontales vers différents serveurs back-end en fonction de l'URL et des paramètres. Utiliser la même URL et les mêmes paramètres augmente les chances que les requêtes soient traitées par le même serveur back-end, ce qui est essentiel pour que l'attaque fonctionne.
* Lors du test de la requête "normale" pour détecter toute interférence de la requête "d'attaque", vous êtes en concurrence avec toutes les autres requêtes que l'application reçoit en même temps, y compris celles des autres utilisateurs. Vous devez envoyer la requête "normale" immédiatement après la requête "d'attaque". Si l'application est occupée, vous devrez peut-être effectuer plusieurs tentatives pour confirmer la vulnérabilité.
* Dans certaines applications, le serveur frontal fonctionne comme un répartiteur de charge et transfère les requêtes vers différents systèmes back-end selon un algorithme de répartition de charge. Si vos requêtes "d'attaque" et "normale" sont transférées vers des systèmes back-end différents, l'attaque échouera. C'est une raison supplémentaire pour laquelle vous devrez peut-être essayer plusieurs fois avant de confirmer une vulnérabilité.
* Si votre attaque réussit à interférer avec une requête ultérieure, mais que ce n'était pas la requête "normale" que vous avez envoyée pour détecter l'interférence, cela signifie qu'un autre utilisateur de l'application a été affecté par votre attaque. Si vous continuez le test, cela pourrait avoir un effet perturbateur sur les autres utilisateurs, et vous devez faire preuve de prudence.
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 afin de permettre une attaque de requête HTTP Smuggling**.
Parfois, les **proxys en frontal effectuent des vérifications de sécurité**. Vous pouvez les contourner en abusant de la manipulation des requêtes HTTP, car vous serez en mesure de **contourner les protections**. Par exemple, dans cet exemple, vous **ne pouvez pas accéder à `/admin` depuis l'extérieur** et le proxy en frontal vérifie cela, mais ce **proxy ne vérifie pas la requête intégrée** :
Dans de nombreuses applications, le **serveur frontal effectue une réécriture des requêtes** avant de les transmettre au serveur en arrière-plan, généralement en ajoutant des en-têtes de requête supplémentaires.\
Une chose courante à faire est d'**ajouter à la requête l'en-tête** `X-Forwarded-For: <IP du client>` ou un en-tête similaire pour que le serveur en arrière-plan connaisse l'IP du client.\
Parfois, si vous pouvez **trouver les nouvelles valeurs ajoutées** à la requête, vous pourriez être en mesure de **contourner les protections** et d'**accéder à des informations/endpoints cachés**.
Pour découvrir comment le proxy réécrit la requête, vous devez **trouver un paramètre POST dont la valeur sera reflétée** dans la réponse. Ensuite, utilisez ce paramètre en dernier et utilisez une exploitation comme celle-ci :
Dans ce cas, la requête suivante sera ajoutée après `search=`, qui est également **le paramètre dont la valeur sera reflétée** dans la réponse, il va donc **refléter les en-têtes de la prochaine requête**.
Notez que **seule la longueur indiquée dans l'en-tête `Content-Length` de la requête intégrée sera reflétée**. Si vous utilisez un nombre faible, seuls quelques octets seront reflétés, si vous utilisez un nombre plus grand que la longueur de tous les en-têtes, alors la requête intégrée générera une erreur. Vous devriez donc **commencer** par un **nombre faible** et **l'augmenter** jusqu'à ce que vous voyiez tout ce que vous voulez voir.\
Notez également que cette **technique est également exploitable avec une vulnérabilité TE.CL**, mais la requête doit se terminer par `search=\r\n0`. Cependant, indépendamment des caractères de nouvelle ligne, les valeurs seront ajoutées au paramètre de recherche.
Enfin, notez que dans cette attaque, nous nous attaquons toujours à nous-mêmes pour apprendre comment le proxy frontal réécrit la requête.
### Capturer les requêtes d'autres utilisateurs <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
Si vous pouvez trouver une requête POST qui va enregistrer le contenu d'un des paramètres, vous pouvez ajouter la requête suivante en tant que valeur de ce paramètre afin de stocker la requête du prochain client :
Dans ce cas, la valeur du **paramètre comment** va être **enregistrée dans un commentaire** d'un article sur la page qui est **publiquement accessible**, donc un **commentaire apparaîtra avec le contenu de la prochaine requête**.
_Une limitation de cette technique est qu'elle ne capture généralement que les données jusqu'au délimiteur de paramètre applicable à la requête détournée. Pour les soumissions de formulaires encodés en URL, il s'agit du caractère `&`, ce qui signifie que le contenu stocké à partir de la requête de l'utilisateur victime se terminera au premier `&`, qui pourrait même apparaître dans la chaîne de requête._
Notez également que cette **technique est également exploitable avec une vulnérabilité TE.CL**, mais la requête doit se terminer par `search=\r\n0`. Cependant, indépendamment des caractères de nouvelle ligne, les valeurs seront ajoutées au paramètre de recherche.
### Utilisation de la contrebande de requêtes HTTP pour exploiter le XSS réfléchi
Si la page web est également **vulnérable au XSS réfléchi**, vous pouvez exploiter la contrebande de requêtes HTTP pour attaquer les clients du site web. L'exploitation du XSS réfléchi à partir de la contrebande de requêtes HTTP présente certains avantages :
* **Elle ne nécessite aucune interaction avec les utilisateurs victimes**
* Elle peut être utilisée pour **exploiter** le comportement XSS dans des parties de la requête qui **ne peuvent pas être facilement contrôlées dans une attaque XSS réfléchie normale**, comme les en-têtes de requête HTTP.
Si un site web est vulnérable au XSS réfléchi dans l'en-tête User-Agent, vous pouvez utiliser cette charge utile pour l'exploiter :
### Utilisation de la contrebande de requêtes HTTP pour transformer une redirection sur site en une redirection ouverte <a href="#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect" id="using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect"></a>
De nombreuses applications effectuent des redirections sur site d'une URL vers une autre et placent le nom d'hôte de l'en-tête `Host` de la requête dans l'URL de redirection. Un exemple de cela est le comportement par défaut des serveurs web Apache et IIS, où une requête pour un dossier sans barre oblique finale reçoit une redirection vers le même dossier incluant la barre oblique finale :
`GET /home HTTP/1.1`\
`Host: normal-website.com`\
\`\`\
`HTTP/1.1 301 Moved Permanently`\
`Location: https://normal-website.com/home/`
Ce comportement est généralement considéré comme inoffensif, mais il peut être exploité dans une attaque de contrebande de requêtes pour rediriger d'autres utilisateurs vers un domaine 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`
La requête contrebandée déclenchera une redirection vers le site web de l'attaquant, ce qui affectera la requête de l'utilisateur suivant qui est traitée par le serveur back-end. Par exemple :
`GET /home HTTP/1.1`\
`Host: attacker-website.com`\
`Foo: XGET /scripts/include.js HTTP/1.1`\
`Host: vulnerable-website.com`\
\`\`\
`HTTP/1.1 301 Moved Permanently`\
`Location: https://attacker-website.com/home/`
Ici, la requête de l'utilisateur était destinée à un fichier JavaScript qui était importé par une page du site web. L'attaquant peut compromettre complètement l'utilisateur victime en renvoyant son propre JavaScript dans la réponse.
### Utilisation de la contrebande de requêtes HTTP pour effectuer un empoisonnement du cache web <a href="#using-http-request-smuggling-to-perform-web-cache-poisoning" id="using-http-request-smuggling-to-perform-web-cache-poisoning"></a>
Si une partie de l'**infrastructure frontale effectue une mise en cache du contenu** (généralement pour des raisons de performance), il est possible de contaminer cette mise en cache en modifiant la réponse du serveur.
Nous avons déjà vu comment modifier la valeur de retour attendue du serveur en une erreur 404 (dans les [Exemples de base](./#basic-examples)), de manière similaire, vous pourriez faire en sorte que le serveur renvoie le contenu de /index.html lorsque la requête empoisonnée demande `/static/include.js`. Ainsi, le contenu de `/static/include.js` sera mis en cache avec le contenu de `/index.html`, rendant `/static/include.js` inaccessible aux clients (DoS ?).
Remarquez que cela est encore plus intéressant si vous trouvez une **Redirection ouverte** ou une **redirection sur site vers une redirection ouverte** (dernière section). En effet, vous pourriez être en mesure de **modifier les valeurs du cache** de `/static/include.js` avec celles d'un script contrôlé par vous (réalisation d'un **XSS généralisé à tous les clients** qui tentent de télécharger la nouvelle version de `/static/include.js`).
Dans cet exemple, il sera démontré comment vous pouvez exploiter un **empoisonnement du cache + une redirection sur site vers une redirection ouverte** pour modifier le contenu du cache de `/static/include.js` afin de **servir du code JS contrôlé** par l'attaquant :
Remarquez comment la requête intégrée demande `/post/next?postId=3`. Cette requête sera redirigée vers `/post?postId=4` et **utilisera la valeur de l'en-tête Host** pour indiquer le domaine. Par conséquent, vous pouvez **modifier l'en-tête Host** pour pointer vers le serveur de l'attaquant et la redirection utilisera ce domaine (**redirection sur site vers une redirection ouverte**).
Ensuite, **après avoir empoisonné le socket**, vous devez envoyer une **requête GET** vers \*\*`/static/include.js`\*\*cette requête sera **empoisonnée** par la requête **redirection sur site vers une redirection ouverte** et **récupérera le contenu du script contrôlé par l'attaquant**.
La prochaine fois que quelqu'un demandera `/static/include.js`, les contenus mis en cache du script de l'attaquant seront servis (XSS généralisé).
### Utilisation de la contrebande de requêtes HTTP pour effectuer une tromperie de cache web <a href="#utilisation-de-la-contrebande-de-requetes-http-pour-effectuer-une-tromperie-de-cache-web" id="utilisation-de-la-contrebande-de-requetes-http-pour-effectuer-une-tromperie-de-cache-web"></a>
> **Quelle est la différence entre l'empoisonnement de cache web et la tromperie de cache web ?**
>
> * Dans l'**empoisonnement de cache web**, l'attaquant fait en sorte que l'application stocke un contenu malveillant dans le cache, et ce contenu est servi depuis le cache aux autres utilisateurs de l'application.
> * Dans la **tromperie de cache web**, l'attaquant fait en sorte que l'application stocke un contenu sensible appartenant à un autre utilisateur dans le cache, puis l'attaquant récupère ce contenu depuis le cache.
Dans cette variante, l'attaquant fait passer une requête qui renvoie un contenu sensible spécifique à l'utilisateur. Par exemple :
Si le **poison atteint un client qui accédait à un contenu statique** tel que `/someimage.png` qui allait être **mis en cache**. Le contenu de `/private/messages` de la victime sera mis en cache dans `/someimage.png` et l'attaquant pourra les voler.\
Notez que l'**attaquant ne sait pas quel contenu statique la victime essayait d'accéder**, il est donc probablement préférable de tester cela en effectuant l'attaque, d'attendre quelques secondes et de **charger tous** les contenus statiques et de **rechercher les données privées**.
### Armer la contrebande de requêtes HTTP avec la désynchronisation des réponses HTTP
Vous avez trouvé une vulnérabilité de contrebande de requêtes HTTP et vous ne savez pas comment l'exploiter. Essayez cette autre méthode d'exploitation :
* [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Cet outil est un Fuzzer HTTP basé sur une grammaire utile pour trouver des divergences étranges dans les requêtes de smuggling.
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
