# HTTP Desync Attack ## **📋 Índice** 1. [Conceitos Fundamentais](#-conceitos-fundamentais) 2. [Arquitetura em Camadas (Front-end vs Back-end)](#-arquitetura-em-camadas-front-end-vs-back-end) 3. [Tipos de Desync (CL.TE, TE.CL, TE.TE)](#-tipos-de-desync-clte-tecl-tete) 4. [Técnicas de Exploração](#-técnicas-de-exploração) 5. [Cenários de Exploração Prática](#-cenários-de-exploração-prática) 6. [Detecção e Ferramentas](#-detecção-e-ferramentas) 7. [Mitigação e Prevenção](#-mitigação-e-prevenção) *** ## **🔍 Conceitos Fundamentais** O **HTTP Desync Attack**, também conhecido como **HTTP Request Smuggling**, é uma técnica que interfere na forma como um site processa sequências de requisições HTTP recebidas de um ou mais usuários. A vulnerabilidade ocorre quando o servidor de front-end (como um load balancer ou proxy) e o servidor de back-end interpretam os limites de uma requisição de forma diferente. *** ## **🏗️ Arquitetura em Camadas** A maioria das aplicações modernas usa uma infraestrutura em camadas: 1. **Front-end (Reverse Proxy):** Recebe o tráfego do usuário e o encaminha para o back-end. 2. **Back-end:** Processa a lógica da aplicação. Para otimizar a performance, essas camadas frequentemente usam o **HTTP Keep-Alive**, enviando várias requisições pela mesma conexão TCP. O "Desync" ocorre quando o Front-end e o Back-end discordam sobre **onde termina uma requisição e começa a próxima**. *** ## **📂 Tipos de Desync** O ataque baseia-se em dois cabeçalhos HTTP que definem o tamanho do corpo da requisição: * `Content-Length` (CL): O tamanho em bytes (ex: `Content-Length: 11`). * `Transfer-Encoding` (TE): Indica que o dado será enviado em pedaços (chunks) (ex: `Transfer-Encoding: chunked`). ### **1. CL.TE (Front-end usa CL, Back-end usa TE)** O front-end processa a requisição baseada no `Content-Length`, enquanto o back-end a processa baseada no `Transfer-Encoding`. **Exemplo de Payload:** ```http POST / HTTP/1.1 Host: vulnerable-site.com Content-Length: 13 Transfer-Encoding: chunked 0 SMUGGLED ``` * **Front-end (CL):** Lê 13 bytes (até o final de `0\r\n\r\n`) e envia tudo. * **Back-end (TE):** Vê o chunk `0` e encerra a requisição ali. A string `SMUGGLED` fica "presa" no buffer da conexão TCP do back-end, sendo anexada ao *início* da próxima requisição de qualquer usuário. ### **2. TE.CL (Front-end usa TE, Back-end usa CL)** O inverso do anterior. ### **3. TE.TE (Ambos usam TE, mas um pode ser ofuscado)** Ocorre quando ambos suportam `Transfer-Encoding`, mas um dos servidores pode ser induzido a ignorar o cabeçalho através de ofuscação (ex: `Transfer-Encoding: xchunked`). *** ## **🔧 Técnicas de Exploração** ### **1. Bypass de Segurança do Front-end** Se o front-end bloqueia acesso a uma rota como `/admin`, mas o back-end não, você pode "smuggle" um request para `/admin` dentro de um request legítimo. ### **2. Captura de Requests de Outros Usuários** Você pode "envenenar" o buffer para que o próximo request de um usuário real seja anexado ao seu payload, permitindo capturar cookies de sessão ou tokens CRSF. ### **3. Web Cache Poisoning** Se houver um cache no front-end, você pode fazer com que o cache armazene uma resposta maliciosa vinculada a uma URL legítima. *** ## **🚀 Cenários de Exploração Prática** ### **Cenário A: Acesso Administrativo via CL.TE** ```http POST / HTTP/1.1 Host: site.com Content-Length: 139 Transfer-Encoding: chunked 0 GET /admin HTTP/1.1 Host: site.com X-Ignore: X ``` O próximo usuário que acessar o site terá seu request anexado ao final do seu `GET /admin`, resultando em: ```http GET /admin HTTP/1.1 Host: site.com X-Ignore: XGET /index.html HTTP/1.1 ... ``` *** ## **🔍 Detecção e Ferramentas** ### **1. Burp Suite - HTTP Request Smuggler** A extensão "HTTP Request Smuggler" para o Burp Suite é o padrão ouro. Ela automatiza o teste de dezenas de variações de ofuscação de cabeçalhos. ### **2. Turbo Intruder** Para ataques que exigem timing preciso e envio massivo de pacotes. ### **3. Testes Manuais com CL e TE** Ao enviar um request com ambos os cabeçalhos, se a resposta do servidor for um timeout ou um erro 400 inesperado, há grandes chances de desync. *** ## **🛡️ Mitigação e Prevenção** ### **1. Usar HTTP/2 de Ponta a Ponta** O HTTP/2 tem um mecanismo robusto para definir o tamanho da requisição, eliminando a ambiguidade do `Content-Length` vs `Transfer-Encoding`. ### **2. Desabilitar Reuso de Conexões TCP** Embora impacte a performance, desativar o reuso impede que requisições de usuários diferentes compartilhem o mesmo buffer. ### **3. Configuração de Servidor (Hardening)** * Configure o front-end para normalizar requisições ambíguas antes de encaminhá-las. * Rejeite qualquer requisição que contenha ambos os cabeçalhos `Content-Length` e `Transfer-Encoding`. *** > O HTTP Request Smuggling é extremamente perigoso pois permite escalar falhas simples para o comprometimento total de sessões de usuários sem qualquer interação da vítima. Sempre valide a configuração de seus proxies e load balancers. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://0xmorte.gitbook.io/bibliadopentestbr/tecnicas/rede-and-infraestrutura/http-desync-attack.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.