# 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 ### 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 `` 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}}