# HTTP Connection Request Smuggling

{{#include ../banners/hacktricks-training.md}}

**Este é um resumo do post** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks)

## Ataques de Estado de Conexão <a href="#state" id="state"></a>

### Validação do Primeiro Pedido

Ao roteirizar solicitações, proxies reversos podem depender do **cabeçalho Host** para determinar o servidor back-end de destino, muitas vezes confiando em uma lista de permissões de hosts que têm acesso permitido. No entanto, uma vulnerabilidade existe em alguns proxies onde a lista de permissões é aplicada apenas na solicitação inicial em uma conexão. Consequentemente, atacantes poderiam explorar isso fazendo primeiro uma solicitação a um host permitido e, em seguida, solicitando um site interno através da mesma conexão:
```
GET / HTTP/1.1
Host: [allowed-external-host]

GET / HTTP/1.1
Host: [internal-host]
```
### Roteamento do Primeiro Pedido

Em algumas configurações, um servidor front-end pode usar o **cabeçalho Host do primeiro pedido** para determinar o roteamento de back-end para esse pedido e, em seguida, rotear persistentemente todos os pedidos subsequentes da mesma conexão de cliente para a mesma conexão de back-end. Isso pode ser demonstrado como:
```
GET / HTTP/1.1
Host: example.com

POST /pwreset HTTP/1.1
Host: psres.net
```
Esse problema pode potencialmente ser combinado com [Host header attacks](https://portswigger.net/web-security/host-header), como envenenamento de redefinição de senha ou [web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning), para explorar outras vulnerabilidades ou obter acesso não autorizado a hosts virtuais adicionais.

> [!NOTE]
> Para identificar essas vulnerabilidades, o recurso 'connection-state probe' no HTTP Request Smuggler pode ser utilizado.

{{#include ../banners/hacktricks-training.md}}