HTTP Connection Request Smuggling

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

Esta página resume, estende e atualiza a pesquisa seminal da PortSwigger sobre 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

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 como envenenamento de redefinição de senha ou envenenamento de cache web 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)

AnoComponenteCVENotas
2022AWS Application Load Balancer–Cabeçalho Host validado apenas na primeira requisição; corrigido por meio de patch no mecanismo de regras (divulgado pela SecurityLabs).
2023Apache Traffic Server < 9.2.2CVE-2023-39852Permitido o request smuggling via reutilização de conexão HTTP/2 quando CONFIG proxy.config.http.parent_proxy_routing_enable estava ativado.
2024Envoy Proxy < 1.29.0CVE-2024-2470Validaçã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

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks