<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert en équipe rouge AWS de HackTricks)</strong></a><strong>!</strong></summary>
- Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
- Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
- **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
- **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
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/proxy inverse) et **comme 2 requêtes** par le **serveur back-end**.\
Le **Front-End** (un équilibreur de charge / Proxy Inverse) **traite** 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 pourrait ê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 prochain client** et la **vraie requête** 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 chunk**. 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 de Smuggling de requête.
Ainsi, les attaques de smuggling de requête impliquent de placer à la fois l'en-tête `Content-Length` et l'en-tête `Transfer-Encoding` dans une seule requête HTTP et de les manipuler de manière à ce que les serveurs frontaux et back-end traitent la requête différemment. La manière exacte dont cela est fait dépend du comportement des deux serveurs :
- **CL.TE** : le serveur frontal utilise l'en-tête `Content-Length` et le serveur back-end utilise l'en-tête `Transfer-Encoding`.
- **TE.CL** : le serveur frontal utilise l'en-tête `Transfer-Encoding` et le serveur back-end utilise l'en-tête `Content-Length`.
- **TE.TE** : les serveurs frontal et back-end 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 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 de Smuggling de requête HTTP simple comme suit :
Remarquez comment `Content-Length` indique que la **longueur de la requête est de 30 octets** (_rappelez-vous qu'en HTTP, une nouvelle ligne est de 2 octets_), donc le proxy inverse **enverra la requête complète** au back-end, et le back-end traitera l'en-tête `Transfer-Encoding` laissant `GET /404 HTTP/1.1` comme **début de la prochaine requête** (au fait, la prochaine requête sera ajoutée à `Foo:x<Début de la prochaine requête>`).
Ici, le serveur frontal utilise l'en-tête `Transfer-Encoding` et le serveur back-end utilise l'en-tête `Content-Length`. Nous pouvons effectuer une attaque de Smuggling de requête HTTP simple comme suit :
Dans ce cas, le **proxy inverse** enverra **toute la requête** au **back-end** comme indiqué par le **`Transfer-encoding`**. Mais, le **back-end** va **traiter** seulement le **`7b`** (4 octets) comme indiqué dans le `Content-Length`. Par conséquent, la prochaine requête sera celle commençant par `GET /404 HTTP/1.1`
_Notez également que le Content-Length 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 prochaine requête._
Ici, les serveurs frontal et back-end 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 manière ou d'une autre.\
Il existe potentiellement d'innombrables façons d'obfusquer l'en-tête `Transfer-Encoding`. Par exemple :
En fonction du serveur (proxy inverse ou de sauvegarde) qui **arrête de traiter** l'en-tête **TE**, vous trouverez une **vulnérabilité CL.TE** ou une **vulnérabilité TE.CL**.
Si une application est vulnérable à la variante CL.TE du smuggling de requête, alors l'envoi d'une requête comme celle-ci provoquera souvent un retard de temps :
Depuis 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 mauvaise demande 400 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 du détournement de requête, l'envoi d'une requête comme celle-ci provoquera souvent un retard temporel :
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, **faire une requête pour `/` renvoyer par exemple un code 404**.\
Dans les [Exemples de base](./#basic-examples), nous avons déjà vu des exemples `CL.TE` et `TE.CL` de comment corrompre une requête de client pour demander `/404` provoquant une réponse 404 lorsque le client demandait une autre ressource.
Quelques considérations importantes doivent être prises en compte lors de la tentative de confirmation des vulnérabilités de la requête de smuggling via l'interférence 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. Envoyer les deux requêtes via la même connexion ne prouvera pas que la vulnérabilité existe.
* La requête "d'attaque" et la requête "normale" doivent utiliser la même URL et les mêmes noms de paramètres, autant que 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 la chance que les requêtes soient traitées par le même serveur back-end, ce qui est essentiel pour que l'attaque fonctionne.
* Lors de la vérification de la requête "normale" pour détecter toute interférence de la requête "d'attaque", vous êtes en concurrence avec d'autres requêtes que l'application reçoit en même temps, y compris celles d'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 pourriez avoir besoin de plusieurs tentatives pour confirmer la vulnérabilité.
* Dans certaines applications, le serveur frontal fonctionne comme un équilibreur de charge et transfère les requêtes vers différents systèmes back-end selon un algorithme d'équilibrage de charge. Si vos requêtes "d'attaque" et "normale" sont transférées vers différents systèmes back-end, alors l'attaque échouera. C'est une raison supplémentaire pour laquelle vous pourriez avoir besoin d'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 d'autres utilisateurs, et vous devriez faire preuve de prudence.
En abusant des en-têtes hop-by-hop, vous pourriez indiquer au proxy de **supprimer l'en-tête Content-Length ou Transfer-Encoding pour qu'une requête HTTP smuggling soit possible à exploiter**.
Parfois, les **proxys côté front-end effectueront des vérifications de sécurité**. Vous pouvez les éviter en abusant de la manipulation des requêtes HTTP car vous pourrez **contourner les protections**. Par exemple, dans cet exemple, vous **ne pouvez pas accéder à `/admin` depuis l'extérieur** et le proxy côté front-end vérifie cela, mais ce **proxy ne vérifie pas la requête intégrée** :
Dans de nombreuses applications, le **serveur côté front-end effectue une réécriture des requêtes** avant de les transmettre au serveur côté back-end, généralement en ajoutant quelques 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 back-end connaisse l'IP du client.\
Parfois, si vous pouvez **trouver quelles nouvelles valeurs sont ajoutées** à la requête, vous pourriez être en mesure de **contourner les protections** et **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 que le back-end reflétera sa valeur** dans la réponse. Ensuite, utilisez ce paramètre en dernier et utilisez une exploitation comme celle-ci :
Dans ce cas, la prochaine requête sera ajoutée après `search=`, qui est également **le paramètre dont la valeur va être reflétée** dans la réponse, donc elle va **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 va être reflétée**. Si vous utilisez un petit nombre, 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 renverra une erreur. Ensuite, vous devriez **commencer** par un **petit nombre** et **l'augmenter** jusqu'à ce que vous voyiez tout ce que vous vouliez 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.
Si vous trouvez une requête POST qui va enregistrer le contenu de l'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 commentaire** va être **enregistrée dans un commentaire** d'un post sur la page qui est **publiquement disponible**, donc un **commentaire apparaîtra avec le contenu de la prochaine requête**.
_Une limitation de cette technique est qu'elle capture généralement des données jusqu'au délimiteur de paramètre applicable pour la requête trafiquée. Pour les soumissions de formulaires encodées en URL, ce sera le caractère `&`, ce qui signifie que le contenu stocké 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.
Si la page web est également **vulnérable aux XSS réfléchis**, vous pouvez abuser de la manipulation des requêtes HTTP pour attaquer les clients du web. L'exploitation des XSS réfléchis à partir de la manipulation des 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 contrôlées de manière triviale dans une attaque XSS réfléchie normale**, comme les en-têtes de requête HTTP.
### Utilisation de la manipulation des 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 à 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 :
Ce comportement est généralement considéré comme inoffensif, mais il peut être exploité dans une attaque de manipulation des requêtes pour rediriger d'autres utilisateurs vers un domaine externe. Par exemple :
La requête trafiquée déclenchera une redirection vers le site web de l'attaquant, ce qui affectera la requête du prochain utilisateur traitée par le serveur côté back-end. Par exemple :
Ici, la requête de l'utilisateur était pour 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 manipulation des requêtes HTTP pour effectuer un empoisonnement de 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 côté front-end effectue la mise en cache du contenu** (généralement pour des raisons de performance), il **pourrait être possible de polluer cette cache en modifiant la réponse du serveur**.
Nous avons déjà vu comment modifier la valeur renvoyée attendue par le serveur vers un 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`. De cette manière, 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 c'est encore plus intéressant si vous trouvez une **Redirection Ouverte** ou une **redirection sur site vers une redirection ouverte** (dernière section). Parce que, vous pourriez être en mesure de **changer les valeurs de cache** de `/static/include.js` avec celles d'un script contrôlé par vous (créant un **XSS général pour tous les clients** qui essaient de télécharger la nouvelle version de `/static/include.js`).
Dans cet exemple, il sera montré comment vous pouvez exploiter un **empoisonnement de cache + une redirection sur site vers une redirection ouverte** pour modifier le contenu du cache de `/static/include.js` pour **servir du code JS contrôlé** par l'attaquant :
Notez 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** à \*\*`/static/include.js`\*\*cette requête sera **empoisonnée** par la requête **de redirection sur site vers une redirection ouverte** et **récupérera le contenu du script contrôlé par l'attaquant**.
### Utilisation de la manipulation des requêtes HTTP pour effectuer une duperie de cache web <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
> * 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 à partir du cache à d'autres utilisateurs de l'application.
> * Dans la **duperie 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 du cache.
Si le **poison atteint un client qui accédait à un contenu statique** comme `/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** donc probablement la meilleure façon de tester cela est de réaliser l'attaque, d'attendre quelques secondes et de **charger tous** les contenus statiques et de **rechercher les données privées**.
Avez-vous trouvé une vulnérabilité de manipulation des 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 la grammaire utile pour trouver des incohérences étranges de trafic de requêtes.
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
