* 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) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **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).
La principale origine de cette vulnérabilité est le fait que le **proxy inverse** va **communiquer avec le client** en utilisant **HTTP/2**, mais il va ensuite **transformer** cette **communication** avec le **serveur back-end** en **HTTP/1.1**.
Le problème avec cette approche est que l'**utilisateur** va pouvoir **injecter** des **en-têtes** inutiles dans la **communication HTTP/2** qui ne seront probablement pas vérifiées par le proxy. Mais ensuite, lorsque ceux-ci sont **injectés aveuglément dans la communication HTTP/1.1**, **une attaque de smuggling de requête peut être effectuée**.
La spécification HTTP/2 indique que l'en-tête **Content-Length n'est pas nécessaire mais peut être indiqué**. Par conséquent, le **proxy inverse** va **traiter tout le contenu envoyé par les utilisateurs** comme la requête, mais ensuite, lorsqu'il **descend en HTTP/1.1**, cet **en-tête** va être **injecté** dans la **requête** et donc, le **back-end va traiter la requête comme 2 requêtes différentes** comme vous pouvez le voir sur l'image ci-dessous :
La spécification HTTP/2 indique également que **tout message contenant des champs d'en-tête spécifiques à la connexion DOIT être considéré comme malformé... mais si vous ne suivez pas cette règle, vous êtes vulnérable**.
Cette technique a été exploitée sur le load balancer AWS, donc en s'assurant que les utilisateurs accèdent à un en-tête Host pointant vers un serveur contrôlé par l'attaquant, ils accéderont à ce serveur.
C'est exactement la même technique que précédemment, mais en vérifiant les requêtes, James a remarqué que les clients lui demandaient de lui envoyer leurs informations d'identification, il a donc simplement modifié son serveur pour permettre à CORS de lui envoyer les informations d
