# Contaminação de Conexão HTTP Os navegadores da web usam o [**HTTP connection coalescing**](https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing), que permite que eles **reutilizem** uma única **conexão HTTP/2+** para solicitações que vão para **diferentes sites**, desde que os sites **resolvam para o mesmo IP** e usem um certificado TLS válido para ambos os nomes de host. O **roteamento da primeira solicitação** é um comportamento perigoso de proxy reverso em que o **proxy analisa a primeira solicitação** em uma conexão para descobrir **qual back-end** roteá-la e, em seguida, **envia** todas as **solicitações subsequentes** nessa conexão para o **mesmo back-end**. **A coalescência de conexão e o roteamento da primeira solicitação não funcionam bem juntos**. Por exemplo, imagine que secure.example.com e wordpress.example.com estão ambos atrás de um proxy reverso usando um certificado válido para \*.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 ``` Se um navegador tentar enviar uma solicitação para **wordpress.example.com** seguido por **secure.example.com**, a coalescência de conexão do navegador forçará **ambas as solicitações em uma única conexão** para o front-end. O roteamento da primeira solicitação resultará na **solicitação para secure.example.com ser incorretamente roteada para o back-end do WordPress**. Isso significa que se você encontrar [XSS](https://portswigger.net/web-security/cross-site-scripting) em wordpress.example.com, você pode usá-lo para comprometer 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=