<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* 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-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe seus truques 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.
Essa vulnerabilidade ocorre quando uma **desincronização** entre **proxies de front-end** e o **servidor de back-end** permite que um **atacante****envie** uma **solicitação HTTP** que será **interpretada** como uma **única solicitação** pelos **proxies de front-end** (balanceador de carga/proxy reverso) e **como 2 solicitações** pelo **servidor de back-end**.\
Isso permite que um usuário **modifique a próxima solicitação que chega ao servidor de back-end após a dele**.
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 solicitação** para o proxy reverso que será **interpretada** pelo **servidor de back-end como 2 solicitações diferentes**. O **perigo** dessa técnica reside no fato de que o **servidor de back-end interpretará a 2ª solicitação injetada** como se ela **viesse do próximo cliente** e a **solicitação real** desse cliente fará **parte** da **solicitação injetada**.
* **Content-Length**: Esse cabeçalho usa um **número decimal** para indicar o **número** de **bytes** do **corpo** da solicitação. O corpo é esperado para terminar no último caractere, **uma nova linha não é necessária no final da solicitaçã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 solicitação do Request Smuggling.
Os ataques de solicitação de desincronização HTTP são elaborados enviando solicitações ambíguas que exploram discrepâncias na forma como os servidores de front-end e de back-end interpretam os cabeçalhos `Content-Length` (CL) e `Transfer-Encoding` (TE). Esses ataques podem se manifestar de 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 de back-end priorizam esses cabeçalhos. As vulnerabilidades surgem do processamento das mesmas solicitações pelos servidores de maneiras diferentes, levando a resultados inesperados e potencialmente maliciosos.
#### Vulnerabilidade CL.TE (Content-Length usado pelo Front-End, Transfer-Encoding usado pelo Back-End)
- **Front-End (CL):** Processa a solicitação com base no cabeçalho `Content-Length`.
- **Back-End (TE):** Processa a solicitação com base no cabeçalho `Transfer-Encoding`.
- **Cenário de Ataque:**
- O atacante envia uma solicitação em que o valor do cabeçalho `Content-Length` não corresponde ao comprimento real do conteúdo.
- O servidor de front-end encaminha a solicitação inteira para o back-end, com base no valor de `Content-Length`.
- O servidor de back-end processa a solicitação em chunks devido ao cabeçalho `Transfer-Encoding: chunked`, interpretando os dados restantes como uma solicitação separada e subsequente.
#### Vulnerabilidade TE.CL (Transfer-Encoding usado pelo Front-End, Content-Length usado pelo Back-End)
- **Front-End (TE):** Processa a solicitação com base no cabeçalho `Transfer-Encoding`.
- **Back-End (CL):** Processa a solicitação com base no cabeçalho `Content-Length`.
- **Cenário de Ataque:**
- O atacante envia uma solicitação em chunks 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 solicitação inteira para o back-end.
- O servidor de back-end, respeitando `Content-Length`, processa apenas a parte inicial da solicitação (`7b` bytes), deixando o restante como parte de uma solicitação subsequente não intencional.
#### Vulnerabilidade TE.TE (Transfer-Encoding usado por ambos, com obfuscação)
- **Servidores:** Ambos suportam `Transfer-Encoding`, mas um pode ser enganado para ignorá-lo por meio 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 à desincronização.
- 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 tem conteúdo.
- É crucial para entender e elaborar ataques de desincronização, 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ê pode indicar ao proxy para **excluir o cabeçalho Content-Length ou Transfer-Encoding para que um ataque de desincronização de solicitação HTTP seja possível de ser abusado**.
```
Connection: Content-Length
```
Para **mais informações sobre cabeçalhos hop-by-hop** visite:
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:
### 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.
- 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.
- 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.
- 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.
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, fazer uma solicitação para `/` resultar 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 em 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" 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.
À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:
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`.
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`.
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: <IP do cliente>`, 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 incrementar 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.
É 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:
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.
O Contrabando de Solicitação HTTP pode ser aproveitado para explorar páginas da web vulneráveis a **XSS Refletido**, oferecendo vantagens significativas:
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:
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` smuggled, onde o cabeçalho `User-Agent` é injetado com um script, `<script>alert(1)</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.
### Usando o HTTP request smuggling para transformar um redirecionamento no local em um redirecionamento aberto <a href="#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect" id="using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect"></a>
### Explorando Redirecionamentos no Local com HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
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:
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 <a href="#using-http-request-smuggling-to-perform-web-cache-poisoning" id="using-http-request-smuggling-to-perform-web-cache-poisoning"></a>
### Explorando o Envenenamento de Cache Web via Contrabando de Solicitação HTTP <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
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:
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 no local 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 no local 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 <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
> **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 a partir 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:
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.
* [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 requisição.
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* 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-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
