<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 [**NFT**](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** nous sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **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.
**La technique de ce post a été tirée de la vidéo : [https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)**
La **principale****différence** entre cette technique et un Smuggling de Requêtes HTTP classique est que **au lieu d'attaquer la requête de la victime en lui ajoutant un préfixe**, nous allons **dévoiler ou modifier la réponse que la victime reçoit**. Cela se fait en envoyant non pas 1 requête et demie pour abuser du Smuggling de Requêtes HTTP, mais **en envoyant 2 requêtes complètes pour désynchroniser la file des réponses des proxies**.
Cela est dû au fait que nous allons être en mesure de **désynchroniser la file 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 du contenu contrôlé par l'attaquant dans la réponse à la victime**.
HTTP/1.1 permet de demander **différentes ressources sans attendre les précédentes**. Par conséquent, s'il y a un **proxy** au **milieu**, c'est au proxy de **maintenir une correspondance synchronisée des requêtes envoyées au backend et des réponses qui en proviennent**.
Cependant, il y a un problème de désynchronisation de la file des réponses. Si un attaquant envoie une attaque de Smuggling de Réponses HTTP et que les réponses à la **requête initiale et à celle smugglée sont répondues immédiatement**, la réponse smugglée ne sera pas insérée dans la file de réponse de la victime mais sera **simplement rejetée comme une erreur**.
Par conséquent, il est nécessaire que la **requête smugglée prenne plus de temps à être traitée** à l'intérieur du serveur backend. Ainsi, au moment où la requête smugglée est traitée, la communication avec l'attaquant sera terminée.
Dans cette situation spécifique, si une **victime a envoyé une requête** et que la **requête smugglée est répondue avant** la requête légitime, la **réponse smugglée sera envoyée à la victime**. Par conséquent, l'attaquant va **contrôler 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 sera envoyée à l'attaquant**, **volant** la réponse à la victime (qui peut contenir par exemple l'en-tête **Set-Cookie**).
Une autre **différence intéressante** avec le **Smuggling de Requêtes HTTP** classique est que, dans une attaque de Smuggling classique, le **but** est de **modifier le début de la requête de la victime** pour qu'elle effectue une action inattendue. Dans une **attaque de Smuggling de Réponses HTTP**, comme vous **envoyez des requêtes complètes**, vous pouvez **injecter dans une 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 **Déni de Service (DoS)** sur le serveur.
Comme expliqué précédemment, pour exploiter cette technique, il est nécessaire que le **premier message smugglé** dans le serveur **nécessite beaucoup de temps pour être traité**.
Cette **requête chronophage est suffisante** si vous voulez simplement **essayer de voler la réponse des victimes**. Mais si vous voulez effectuer un exploit plus complexe, voici une structure commune pour l'exploit.
Tout d'abord, la **requête initiale exploitant le Smuggling de Requêtes HTTP**, puis la **requête chronophage** et ensuite **1 ou plusieurs requêtes de charge utile** dont les réponses seront envoyées aux victimes.
Comme pour les charges utiles connues du Smuggling de Requêtes HTTP, vous pouvez **voler la requête des victimes** avec une différence importante : dans ce cas, vous avez juste besoin que le **contenu envoyé soit reflété dans la réponse**, **aucun stockage persistant** n'est nécessaire.
Tout d'abord, l'attaquant envoie une charge utile contenant une **dernière requête POST avec le paramètre reflété** à la fin et une longue Content-Length
Ensuite, une fois que la **requête initiale** (bleue) a été **traitée** et **pendant que** la **requête chronophage** est en cours de traitement (jaune), la **prochaine requête qui arrive d'une victime** va être **ajoutée dans la file juste après le paramètre reflété** :
Ensuite, la **victime** va **recevoir** la **réponse à la requête chronophage** et si entre-temps l'**attaquant envoie une autre requête**, la **réponse de la requête de contenu reflété lui sera envoyée**.
Jusqu'à présent, nous avons appris comment exploiter les attaques de Smuggling de Requêtes HTTP pour **contrôler** la **requête dont** la **réponse** qu'un **client** va **recevoir** et comment vous pouvez ensuite **voler la réponse qui était destinée à la victime**.
Il existe des requêtes intéressantes comme la requête **HEAD** qui sont spécifiées pour ne pas avoir **de contenu dans le corps des réponses** et qui devraient (doivent) **contenir la Content-Length** de la requête comme **si c'était une requête GET**.
Ensuite, la **victime** va **recevoir** la **réponse** de la **requête HEAD**, qui va **contenir une Content-Length mais aucun contenu du tout**. Par conséquent, le proxy **ne va pas envoyer cette réponse** à la victime, mais va **attendre** un **contenu**, qui sera en fait la **réponse à la requête jaune** (également injectée par l'attaquant) :
En 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 généralement dans ses en-têtes le Content-Type et la Content-Length**, vous pouvez **envoyer une requête comme celle-ci** pour **causer une XSS** chez la victime sans que la page soit vulnérable à la XSS :
En exploitant l'attaque de Confusion de Contenu de désynchronisation de la réponse 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 une XSS, alors le cache est empoisonné**.
Notez que dans ce cas, si le **"victim" est l'attaquant**, il peut maintenant effectuer un **empoisonnement de cache dans des URL arbitraires** car il peut **contrôler l'URL qui va être mise en cache** avec la réponse malveillante.
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 :**
Le **but** de cette attaque est d'exploiter à nouveau la **désynchronisation de la réponse** afin de **faire envoyer au proxy une réponse 100% générée par l'attaquant**.
Pour y parvenir, l'attaquant doit trouver un point de terminaison de l'application web qui **reflète certaines valeurs dans la réponse** et **connaître la longueur du contenu de la réponse HEAD**.
Cependant, notez comment les **données reflétées avaient une taille conforme à la Content-Length** de la **réponse HEAD qui a généré une réponse HTTP valide dans la file de réponse**.
Par conséquent, la **prochaine requête du deuxième victime** va **recevoir** en **réponse quelque chose entièrement fabriqué par l'attaquant**. Comme la réponse est entièrement fabriquée par l'attaquant, il peut également **faire en sorte que le proxy mette en cache la réponse**.
