<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você 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 do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
A **principal diferença** entre esta técnica e um HTTP Request Smuggling comum é que **em vez de atacar** a **requisição da vítima****adicionando um prefixo a ela**, vamos **vazar ou modificar a resposta que a vítima recebe**. Isso é feito, em vez de enviar 1 requisição e meia para abusar do HTTP Request Smuggling, **enviando 2 requisições completas para desincronizar a fila de respostas dos proxies**.
Isso porque vamos conseguir **desincronizar a fila de respostas** de modo que a **resposta** da **requisição legítima** da **vítima seja enviada ao atacante**, ou **injetando conteúdo controlado pelo atacante na resposta à vítima**.
HTTP/1.1 permite solicitar **diferentes recursos sem precisar esperar pelos anteriores**. Portanto, se houver um **proxy** no **meio**, é tarefa do proxy **manter uma correspondência sincronizada das requisições enviadas ao backend e das respostas recebidas dele**.
No entanto, há um problema ao desincronizar a fila de respostas. Se um atacante enviar um ataque de HTTP Response Smuggling e as respostas para a **requisição inicial e a contrabandeada forem respondidas imediatamente**, a resposta contrabandeada não será inserida na fila de respostas da vítima, mas **será descartada como um erro**.
Portanto, é necessário que a **requisição contrabandeada****leve mais tempo para ser processada** dentro do servidor backend. Assim, quando a requisição contrabandeada for processada, a comunicação com o atacante já terá terminado.
Se nessa situação específica uma **vítima enviou uma requisição** e a **resposta à requisição contrabandeada for respondida antes** da requisição legítima, a **resposta contrabandeada será enviada à vítima**. Assim, o atacante estará **controlando a requisição "realizada" pela vítima**.
Além disso, se o **atacante então realizar uma requisição** e a **resposta legítima** à requisição da **vítima for respondida****antes** da requisição do atacante. A **resposta à vítima será enviada ao atacante**, **roubando** a resposta destinada à vítima (que pode conter, por exemplo, o cabeçalho **Set-Cookie**).
Outra **diferença interessante** com o HTTP Request Smuggling comum é que, em um ataque de smuggling comum, o **objetivo** é **modificar o início da requisição da vítima** para que ela execute uma ação inesperada. Em um **ataque de HTTP Response Smuggling**, como você está **enviando requisições completas**, você pode **injetar em um payload dezenas de respostas** que irão **desincronizar dezenas de usuários** que estarão **recebendo** as **respostas injetadas**.
Além de poder **distribuir mais facilmente dezenas de exploits** entre usuários legítimos, isso também pode ser usado para causar um **DoS** no servidor.
### Organização do Exploit
Como explicado anteriormente, para abusar desta técnica, é necessário que a **primeira mensagem contrabandeada** enviada ao servidor **exija muito tempo para ser processada**.
Esta **requisição que consome tempo é suficiente** se apenas quisermos **tentar roubar a resposta da vítima.** Mas se você quiser realizar um exploit mais complexo, esta será uma estrutura comum para o exploit.
Primeiro, a **requisição inicial** abusando do **HTTP Request Smuggling**, depois a **requisição que consome tempo** e então **1 ou mais requisições de payload** cujas respostas serão enviadas às vítimas.
## Abusando da Desincronização da Fila de Respostas HTTP
### Capturando as requisições de outros usuários <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
Como com os payloads conhecidos de HTTP Request Smuggling, você pode **roubar a requisição da vítima** com uma diferença importante: Neste caso, você só precisa que o **conteúdo enviado seja refletido na resposta**, **nenhum armazenamento persistente** é necessário.
Primeiro, o atacante envia um payload contendo uma **requisição POST final com o parâmetro refletido** no final e um Content-Length grande
.png>)
Então, uma vez que a **requisição inicial** (azul) foi **processada** e **enquanto** a sonolenta está sendo processada (amarelo) a **próxima requisição que chega de uma vítima** será **anexada na fila logo após o parâmetro refletido**:
(1).png>)
Então, a **vítima** irá **receber** a **resposta à requisição sonolenta** e se, enquanto isso, o **atacante****enviar****outra****requisição**, a **resposta do conteúdo refletido será enviada a ele**.
## Desincronização de Resposta
Até este ponto, aprendemos como abusar de ataques de HTTP Request Smuggling para **controlar** a **requisição****cuja****resposta** um **cliente** vai **receber** e como você pode então **roubar a resposta que era destinada à vítima**.
Mas ainda é possível **desincronizar ainda mais** as respostas.
Existem requisições interessantes como a requisição **HEAD** que são especificadas para não ter **nenhum conteúdo dentro do corpo da resposta** e que devem (obrigatoriamente) **conter o Content-Length** da requisição como **se fosse uma requisição GET**.
Portanto, se um atacante **injetar** uma requisição **HEAD**, como nestas imagens:
.png>)
Então, **uma vez que a azul é respondida ao atacante**, a próxima requisição da vítima será introduzida na fila:
Então, a **vítima** irá **receber** a **resposta** da requisição **HEAD**, que **vai conter um Content-Length mas nenhum conteúdo**. Portanto, o proxy **não enviará esta resposta** à vítima, mas **esperará** por algum **conteúdo**, que na verdade será **resposta à requisição amarela** (também injetada pelo atacante):
(1).png>)
### Confusão de Conteúdo
Seguindo o exemplo anterior, sabendo que você pode **controlar o corpo** da requisição cuja resposta será recebida pela vítima e que uma **resposta HEAD** geralmente contém em seus cabeçalhos o **Content-Type e o Content-Length**, você pode **enviar uma requisição como a seguinte** para **causar XSS** na vítima sem a página ser vulnerável a XSS:
Abusando do ataque de desincronização de resposta e Confusão de Conteúdo comentado anteriormente, **se o cache armazenar a resposta à requisição realizada pela vítima e esta resposta for uma injetada causando um XSS, então o cache está envenenado**.
Requisição maliciosa contendo o payload XSS:
(1).png>)
Resposta maliciosa à vítima que contém o cabeçalho que indica ao cache para armazenar a resposta:
(1).png>)
{% hint style="warning" %}
Note que neste caso se o **"vítima" é o atacante** ele pode agora realizar **envenenamento de cache em URLs arbitrários** pois ele pode **controlar a URL que vai ser armazenada** com a resposta maliciosa.
{% endhint %}
### Engano de Cache Web
Este ataque é semelhante ao anterior, mas **em vez de injetar um payload dentro do cache, o atacante estará armazenando informações da vítima dentro do cache:**
(1)(1).png>)
### Divisão de Resposta
O **objetivo** deste ataque é abusar novamente da **desincronização de resposta** para **fazer o proxy enviar uma resposta 100% gerada pelo atacante**.
Para conseguir isso, o atacante precisa encontrar um ponto final da aplicação web que esteja **refletindo alguns valores dentro da resposta** e **conhecer o comprimento do conteúdo da resposta HEAD**.
Ele enviará um **exploit** como:
(1)(1)(1).png>)
Após a primeira requisição ser resolvida e enviada de volta ao atacante, a **requisição da vítima é adicionada à fila**:
(1)(1)(1).png>)
A vítima receberá como resposta a **resposta HEAD + o conteúdo da segunda resposta à requisição (contendo parte dos dados refletidos):**
(1).png>)
No entanto, note como os **dados refletidos tinham um tamanho de acordo com o Content-Length** da **resposta HEAD** que **gerou uma resposta HTTP válida na fila de respostas**.
Portanto, a **próxima requisição da segunda vítima** estará **recebendo** como **resposta algo completamente criado pelo atacante**. Como a resposta é completamente criada pelo atacante, ele também pode **fazer o proxy armazenar a resposta no cache**.
* Não esqueça de conferir este vídeo explicando todas essas técnicas muito bem: [https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você 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 do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
