# HTTP Response Smuggling / Desync
Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!
Autres moyens de soutenir HackTricks :
* 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 [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
* **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 dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
## Désynchronisation de la file d'attente des requêtes HTTP
Tout d'abord, cette technique **exploite une vulnérabilité de HTTP Request Smuggling**, donc vous devez savoir ce que c'est :
La **principale différence** entre cette technique et un HTTP Request Smuggling classique est qu'**au lieu** d'**attaquer** la **requête** de la **victime en ajoutant un préfixe**, nous allons **fuir ou modifier la réponse que la victime reçoit**. Cela se fait en envoyant **2 requêtes complètes pour désynchroniser la file d'attente des réponses des proxies**.
Cela permet de **désynchroniser la file d'attente des réponses** afin que la **réponse** de la **requête légitime** de la **victime soit envoyée à l'attaquant**, ou en **injectant un contenu contrôlé par l'attaquant dans la réponse à la victime**.
### Désynchronisation de pipeline HTTP
HTTP/1.1 permet de demander **différentes ressources sans avoir à attendre les précédentes**. Par conséquent, s'il y a un **proxy** au **milieu**, c'est la tâche du proxy de **maintenir une correspondance synchronisée des requêtes envoyées au backend et des réponses provenant de celui-ci**.
Cependant, il y a un problème pour désynchroniser la file d'attente des réponses. Si un attaquant envoie une attaque de HTTP Response Smuggling et que les réponses à la **requête initiale et à la requête introduite sont immédiatement répondues**, la réponse introduite ne sera pas insérée dans la file d'attente de la réponse de la victime mais sera **simplement écartée comme une erreur**.
 (1) (1) (1).png>)
Il est donc nécessaire que la **requête introduite** **prenne plus de temps à être traitée** à l'intérieur du serveur backend. Ainsi, lorsque la requête introduite est traitée, la communication avec l'attaquant sera terminée.
Si dans cette situation spécifique une **victime a envoyé une requête** et que la **réponse à la requête introduite est donnée avant** la requête légitime, la **réponse introduite sera envoyée à la victime**. Par conséquent, l'attaquant **contrôlera la requête "effectuée" par la victime**.
De plus, si l'**attaquant effectue ensuite une requête** et que la **réponse légitime** à la **requête de la victime** est **répondue** **avant** la requête de l'attaquant. La **réponse à la victime va être envoyée à l'attaquant**, **volant** la réponse destinée à la victime (qui peut contenir par exemple l'en-tête **Set-Cookie**).
 (1).png>)
 (1) (1) (1).png>)
### Injections multiples imbriquées
Une **autre différence intéressante** avec le HTTP Request Smuggling classique est que, dans une attaque de smuggling classique, l'**objectif** est de **modifier le début de la requête de la victime** pour qu'elle effectue une action inattendue. Dans une **attaque de HTTP Response Smuggling**, comme vous **envoyez des requêtes complètes**, vous pouvez **injecter dans une seule charge utile des dizaines de réponses** qui vont **désynchroniser des dizaines d'utilisateurs** qui vont **recevoir** les **réponses injectées**.
En plus de pouvoir **distribuer plus facilement des dizaines d'exploits** parmi les utilisateurs légitimes, cela pourrait également être utilisé pour provoquer un **DoS** sur le serveur.
### Organisation de l'exploit
Comme expliqué précédemment, pour abuser de cette technique, il est nécessaire que le **premier message introduit** dans le serveur **nécessite beaucoup de temps pour être traité**.
Cette **requête chronophage est suffisante** si nous voulons juste **essayer de voler la réponse de la victime.** Mais si vous voulez réaliser un exploit plus complexe, voici une structure commune pour l'exploit.
Tout d'abord la **requête initiale** abusant du **HTTP Request Smuggling**, puis la **requête chronophage** et ensuite **1 ou plusieurs requêtes de charge utile** dont les réponses seront envoyées aux victimes.
## Exploitation de la désynchronisation de la file d'attente des réponses HTTP
### Capturer les requêtes d'autres utilisateurs
Comme avec les charges utiles connues de HTTP Request Smuggling, vous pouvez **voler la requête de la victime** avec une différence importante : dans ce cas, vous avez juste besoin d'**envoyer du contenu pour qu'il soit reflété dans la réponse**, **aucun stockage persistant** n'est nécessaire.
D'abord, l'attaquant envoie une charge utile contenant une **requête POST finale avec le paramètre reflété** à la fin et une grande Content-Length
.png>)
Ensuite, une fois la **requête initiale** (bleue) **traitée** et **pendant** que celle **endormie** est en cours de traitement (jaune), la **prochaine requête qui arrive d'une victime** va être **ajoutée dans la file d'attente juste après le paramètre reflété** :
 (1).png>)
Ensuite, la **victime** **recevra** la **réponse à la requête endormie** et si entre-temps l'**attaquant** **envoie** **une autre** **requête**, la **réponse du contenu reflété sera envoyée à lui**.
## Désynchronisation des réponses
Jusqu'à présent, nous avons appris à exploiter les attaques de HTTP Request Smuggling pour **contrôler** la **requête** **dont** la **réponse** va être **reçue** par un **client** et comment vous pouvez ensuite **voler la réponse qui était destinée à la victime**.
Mais il est encore possible de **désynchroniser encore plus** les réponses.
Il existe des requêtes intéressantes comme la requête **HEAD** qui sont spécifiées pour ne pas avoir **de contenu à l'intérieur du corps des réponses** et qui doivent (doivent) **contenir le Content-Length** de la requête comme **si c'était une requête GET**.
Par conséquent, si un attaquant **injecte** une **requête HEAD**, comme dans ces images :
.png>)
Ensuite, **une fois que la bleue est répondue à l'attaquant**, la prochaine requête de la victime va être introduite dans la file d'attente :
 (1) (1) (1) (1) (1) (1).png>)
Ensuite, la **victime** **recevra** la **réponse** de la **requête HEAD**, qui va **contenir un Content-Length mais pas de contenu du tout**. Par conséquent, le proxy **n'enverra pas cette réponse** à la victime, mais **attendra** un **contenu**, qui en réalité va être **la réponse à la requête jaune** (également injectée par l'attaquant) :
 (1).png>)
### Confusion de contenu
Suivant l'exemple précédent, sachant que vous pouvez **contrôler le corps** de la requête dont la réponse va être reçue par la victime et qu'une **réponse HEAD** contient habituellement dans ses en-têtes le **Content-Type et le Content-Length**, vous pouvez **envoyer une requête comme la suivante** pour **provoquer un XSS** chez la victime sans que la page soit vulnérable au XSS :
 (1) (1) (1) (1).png>)
### Empoisonnement du cache
En abusant de l'attaque de désynchronisation de réponse et de confusion de contenu précédemment commentée, **si le cache stocke la réponse à la requête effectuée par la victime et que cette réponse est une réponse injectée provoquant un XSS, alors le cache est empoisonné**.
Requête malveillante contenant la charge utile XSS :
 (1).png>)
Réponse malveillante à la victime qui contient l'en-tête indiquant au cache de stocker la réponse :
 (1).png>)
{% hint style="warning" %}
Notez que dans ce cas, si le **"victime" est l'attaquant**, il peut maintenant effectuer **l'empoisonnement du cache sur des URL arbitraires** car il peut **contrôler l'URL qui va être mise en cache** avec la réponse malveillante.
{% endhint %}
### Tromperie du cache Web
Cette attaque est similaire à la précédente, mais **au lieu d'injecter une charge utile dans le cache, l'attaquant va mettre en cache des informations de la victime à l'intérieur du cache** :
 (1) (1).png>)
### Séparation de réponse
L'**objectif** de cette attaque est d'abuser à nouveau de la **désynchronisation des réponses** afin de **faire envoyer par le proxy une réponse générée à 100% par l'attaquant**.
Pour y parvenir, l'attaquant doit trouver un point de terminaison de l'application web qui **reflète certaines valeurs à l'intérieur de la réponse** et **connaître la longueur du contenu de la réponse HEAD**.
Il enverra un **exploit** comme :
 (1) (1) (1).png>)
Après que la première requête soit résolue et renvoyée à l'attaquant, la **requête de la victime est ajoutée dans la file d'attente** :
 (1) (1) (1).png>)
La victime recevra comme réponse la **réponse HEAD + le contenu de la réponse de la deuxième requête (contenant une partie des données reflétées) :**
 (1).png>)
Cependant, notez comment les **données reflétées avaient une taille selon le Content-Length** de la **réponse HEAD** qui **a généré une réponse HTTP valide dans la file d'attente des réponses**.
Par conséquent, la **prochaine requête de la deuxième victime** va **recevoir** comme **réponse quelque chose complètement fabriqué par l'attaquant**. Comme la réponse est complètement fabriquée par l'attaquant, il peut aussi **faire en sorte que le proxy mette la réponse en cache**.
## Références
* N'oubliez pas de regarder cette vidéo expliquant toutes ces techniques très bien : [https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!
Autres moyens de soutenir HackTricks :
* 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 [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
* **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 dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).