# HTTP Connection Request Smuggling

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

**Esta página resume, estende e atualiza** a pesquisa seminal da PortSwigger sobre [Browser-Powered Desync Attacks](https://portswigger.net/research/browser-powered-desync-attacks) e trabalhos subsequentes sobre abuso de estado de conexão HTTP/2. Foca em vulnerabilidades onde **uma origem é determinada apenas uma vez por conexão TCP/TLS**, permitindo que um atacante “contrabandeie” solicitações para um host interno diferente uma vez que o canal esteja estabelecido.

## Connection-State Attacks <a href="#state" id="state"></a>

### First-request Validation

Ao roteirizar solicitações, proxies reversos podem depender do cabeçalho **Host** (ou **:authority** no HTTP/2) para determinar o servidor de back-end de destino, muitas vezes confiando em uma lista de permissões de hosts que têm acesso permitido. No entanto, existe uma vulnerabilidade em vários proxies onde a lista de permissões é **apenas aplicada na primeira solicitação em uma conexão**. Consequentemente, os atacantes podem acessar hosts virtuais internos enviando primeiro uma solicitação permitida e, em seguida, reutilizando a mesma conexão subjacente:
```http
GET / HTTP/1.1
Host: allowed-external-host.example

GET /admin HTTP/1.1
Host: internal-only.example
```
### Roteamento do Primeiro Pedido

Muitos proxies reversos HTTP/1.1 mapeiam uma conexão de saída para um pool de back-end **baseando-se exclusivamente no primeiro pedido que eles encaminham**. Todos os pedidos subsequentes enviados através do mesmo socket de front-end são reutilizados silenciosamente, independentemente do cabeçalho Host. Isso pode ser combinado com ataques clássicos de [cabeçalho Host](https://portswigger.net/web-security/host-header) como envenenamento de redefinição de senha ou [envenenamento de cache web](https://portswigger.net/web-security/web-cache-poisoning) para obter acesso semelhante ao SSRF a outros hosts virtuais:
```http
GET / HTTP/1.1
Host: public.example

POST /pwreset HTTP/1.1
Host: private.internal
```
> [!TIP]
> No Burp Suite Professional ≥2022.10 você pode habilitar **HTTP Request Smuggler → Connection-state probe** para detectar automaticamente essas fraquezas.

---

## NOVO em 2023-2025 – Abuso de Coalescência de Conexão HTTP/2/3

Navegadores modernos frequentemente **coalescem** requisições HTTP/2 e HTTP/3 em uma única conexão TLS quando o certificado, protocolo ALPN e endereço IP coincidem. Se um front-end autoriza apenas a primeira requisição, cada requisição coalescida subsequente herda essa autorização – **mesmo que o Host/:authority mude**.

### Cenário de Exploração
1. O atacante controla `evil.com`, que resolve para o mesmo nó de borda CDN que o alvo `internal.company`.
2. O navegador da vítima já possui uma conexão HTTP/2 aberta para `evil.com`.
3. O atacante incorpora uma `<img src="https://internal.company/…">` oculta em sua página.
4. Como os parâmetros de conexão coincidem, o navegador reutiliza a conexão TLS **existente** e multiplexa a requisição para `internal.company`.
5. Se o CDN/roteador apenas validou a primeira requisição, o host interno é exposto.

PoCs para Chrome/Edge/Firefox estão disponíveis na palestra de James Kettle *“HTTP/2: The Sequel is Always Worse”* (Black Hat USA 2023).

### Ferramentas
* **Burp Suite 2023.12** introduziu um ponto de inserção experimental **HTTP/2 Smuggler** que tenta automaticamente coalescência e técnicas TE/CL.
* **smuggleFuzz** (https://github.com/microsoft/smugglefuzz) – Um framework Python lançado em 2024 para forçar vetores de desincronização front-end/back-end sobre HTTP/2 e HTTP/3, incluindo permutações de estado de conexão.

### Mitigações
* Sempre **revalide Host/:authority em cada requisição**, não apenas na criação da conexão.
* Desative ou restrinja estritamente a **coalescência de origem** em camadas de CDN/balancer (por exemplo, `http2_origin_cn` desligado no NGINX).
* Implemente certificados ou endereços IP separados para nomes de host internos e externos para que o navegador não possa coalescê-los legalmente.
* Prefira **connection: close** ou `proxy_next_upstream` após cada requisição, quando prático.

---

## Casos do Mundo Real (2022-2025)

| Ano | Componente | CVE | Notas |
|------|-----------|-----|-------|
| 2022 | AWS Application Load Balancer | – | Cabeçalho Host validado apenas na primeira requisição; corrigido por meio de patch no mecanismo de regras (divulgado pela SecurityLabs). |
| 2023 | Apache Traffic Server < 9.2.2 | CVE-2023-39852 | Permitido o request smuggling via reutilização de conexão HTTP/2 quando `CONFIG proxy.config.http.parent_proxy_routing_enable` estava ativado. |
| 2024 | Envoy Proxy < 1.29.0 | CVE-2024-2470 | Validação inadequada de :authority após o primeiro stream permitiu request smuggling entre inquilinos em malhas compartilhadas. |

---

## Cheat-Sheet de Detecção

1. Envie duas requisições na **mesma** conexão TCP/TLS com cabeçalhos Host ou :authority diferentes.
2. Observe se a segunda resposta se origina do primeiro host (seguro) ou do segundo host (vulnerável).
3. No Burp: `Repeat → keep-alive → Send → Follow`.
4. Ao testar HTTP/2, abra um stream **dedicado** (ID 1) para um host benigno, depois multiplexe um segundo stream (ID 3) para um host interno e procure uma resposta.

---

## Referências

* PortSwigger Research – *HTTP/2: The Sequel is Always Worse* (Black Hat USA 2023)
* Aviso de Segurança do Envoy CVE-2024-2470 – Validação inadequada de autoridade

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