# HTTP Response Smuggling / Desync

<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 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 seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.

</details>

**A técnica deste post foi retirada do vídeo: [https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)**

## Dessincronização da Fila de Requisições HTTP

Em primeiro lugar, essa técnica **abusa de uma vulnerabilidade de Smuggling de Requisições HTTP**, então você precisa saber o que é isso:

A **principal** **diferença** entre essa técnica e um Smuggling de Requisições HTTP 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 enviando **2 requisições completas para dessincronizar a fila de respostas dos proxies**.

Isso ocorre porque seremos capazes de **dessincronizar a fila de respostas** para que a **resposta** da **requisição legítima da vítima seja enviada ao atacante**, ou **injetando conteúdo controlado pelo atacante na resposta para a vítima**.

### Dessincronização de Pipelines HTTP

O HTTP/1.1 permite solicitar **recursos diferentes sem precisar esperar pelos anteriores**. Portanto, se houver um **proxy** no **meio**, é tarefa dos proxies **manter uma correspondência sincronizada das requisições enviadas ao backend e das respostas provenientes dele**.

No entanto, há um problema de dessincronização da fila de respostas. Se um atacante enviar um ataque de Smuggling de Resposta HTTP e as respostas para a **requisição inicial e a contrabandeada forem respondidas imediatamente**, a resposta contrabandeada não será inserida na fila da resposta da vítima, mas será **simplesmente descartada como um erro**.

Portanto, é necessário que a **requisição contrabandeada leve mais tempo para ser processada** no servidor backend. Portanto, quando a requisição contrabandeada for processada, a comunicação com o atacante terá terminado.

Se, nessa situação específica, uma **vítima enviar uma requisição** e a **requisição contrabandeada for respondida antes** da requisição legítima, a **resposta contrabandeada será enviada à vítima**. Portanto, 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 da vítima (que pode conter, por exemplo, o cabeçalho **Set-Cookie**).

### Injeções Aninhadas Múltiplas

Outra **diferença interessante** com o Smuggling de Requisições HTTP comum é que, em um ataque de contrabando 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 contrabando de resposta HTTP**, como você está **enviando requisições completas**, você pode **injetar em uma carga útil dezenas de respostas** que irão **dessincronizar 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 poderia ser usado para causar um **DoS** no servidor.

### Organização de Exploits

Como explicado anteriormente, para abusar dessa técnica, é necessário que a **primeira mensagem contrabandeada** no servidor **leve muito tempo para ser processada**.

Essa **requisição demorada é suficiente** se você apenas quiser **tentar roubar a resposta da vítima**. Mas se você quiser realizar um exploit mais complexo, essa será uma estrutura comum para o exploit.

Primeiro, a **requisição inicial abusando do Smuggling de Requisições HTTP**, em seguida, a **requisição demorada** e depois **1 ou mais requisições de carga útil** cujas respostas serão enviadas para as vítimas.

## Abusando da Dessincronização da Fila de Respostas HTTP

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

Assim como com os payloads conhecidos de Smuggling de Requisições HTTP, 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 uma carga útil contendo uma **requisição POST final com o parâmetro refletido** no final e um grande Content-Length

Depois, uma vez que a **requisição inicial** (azul) foi **processada** e **enquanto** a **sonolenta** está sendo processada (amarela), a **próxima requisição que chega de uma vítima** será **anexada na fila logo após o parâmetro refletido**:

Então, a **vítima** irá **receber** a **resposta à requisição sonolenta** e se, nesse meio tempo, o **atacante enviar outra requisição**, a **resposta da requisição de conteúdo refletido será enviada para ele**.

## Dessincronização de Respostas

Até este ponto, aprendemos como abusar de ataques de Smuggling de Requisições HTTP 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 **dessincronizar ainda mais** as respostas.

Existem requisições interessantes como a requisição **HEAD** que são especificadas para não ter **nenhum conteúdo no corpo das respostas** e que devem (devem) **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:

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á essa resposta** para a vítima, mas irá **aguardar** por algum **conteúdo**, que na verdade será a **resposta à requisição amarela** (também injetada pelo atacante):

### Confusão de Conteúdo

Seguindo o exemplo anterior, sabendo que você pode **controlar o corpo** da requisição cuja resposta a vítima vai receber 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 que a página seja vulnerável ao XSS:

### Envenenamento de Cache

Abusando do ataque de Confusão de Conteúdo de dessincronização de respostas comentado anteriormente, **se o cache armazenar a resposta à requisição realizada pela vítima e essa resposta for uma injetada causando um XSS, então o cache estará envenenado**.

Requisição maliciosa contendo o payload XSS:

Resposta maliciosa para a vítima que contém o cabeçalho que indica ao cache para armazenar a resposta:

{% hint style="warning" %}
Note que, neste caso, se o **"vítima" for o atacante**, ele pode agora realizar **envenenamento de cache em URLs arbitrárias** pois ele pode **controlar a URL que será armazenada em cache** com a resposta maliciosa.
{% endhint %}

### Decepção de Cache da Web

Este ataque é semelhante ao anterior, mas **em vez de injetar uma carga útil dentro do cache, o atacante estará armazenando informações da vítima dentro do cache:**

### Divisão de Respostas

O **objetivo** deste ataque é abusar novamente da **dessincronização de respostas** para **fazer o proxy enviar uma resposta 100% gerada pelo atacante**.

Para alcançar isso, o atacante precisa encontrar um endpoint da aplicação web que está **refletindo alguns valores dentro da resposta** e **saber o comprimento do conteúdo da resposta HEAD**.

Ele enviará um **exploit** como:

Depois que a primeira requisição for resolvida e enviada de volta ao atacante, a **requisição da vítima é adicionada à fila**:

A vítima receberá como resposta o **HEAD response + o conteúdo da resposta da segunda requisição (contendo parte dos dados refletidos):**

No entanto, observe 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** irá **receber** como **resposta algo completamente criado pelo atacante**. Como a resposta é completamente criada pelo atacante, ele também pode **fazer o proxy armazenar em cache a resposta**.