<summary><strong>Aprenda hacking na 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ê deseja 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 do 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 o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** facilmente com as **ferramentas comunitárias mais avançadas do mundo**.\
> * 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.
> * No **engano 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.
O envenenamento de cache tem como objetivo manipular o cache do lado do cliente para forçar os clientes a carregar recursos inesperados, parciais ou sob o controle de um atacante. A extensão do impacto depende da popularidade da página afetada, pois a resposta contaminada é servida exclusivamente aos usuários que visitam a página durante o período de contaminação do cache.
A execução de um ataque de envenenamento de cache envolve várias etapas:
1.**Identificação de Entradas Não Chaveadas**: Estes são parâmetros que, embora não sejam necessários para que uma solicitação seja armazenada em cache, podem alterar a resposta retornada pelo servidor. Identificar essas entradas é crucial, pois elas podem ser exploradas para manipular o cache.
2.**Exploração das Entradas Não Chaveadas**: Após identificar as entradas não chaveadas, o próximo passo envolve descobrir como abusar desses parâmetros para modificar a resposta do servidor de uma forma que beneficie o atacante.
3.**Garantir que a Resposta Envenenada seja Armazenada em Cache**: O último passo é garantir que a resposta manipulada seja armazenada em cache. Dessa forma, qualquer usuário que acesse a página afetada enquanto o cache estiver envenenado receberá a resposta contaminada.
Normalmente, quando uma resposta foi **armazenada em cache** haverá um **cabeçalho indicando isso**, você pode verificar quais cabeçalhos deve prestar atenção neste post: [**Cabeçalhos de Cache HTTP**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
Se você suspeitar que a resposta está sendo armazenada em cache, você poderia tentar **enviar solicitações com um cabeçalho ruim**, que deveria 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ê saberá que está vulnerável (e até poderia realizar um DoS).\
Você poderia 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 para carregar o script de lá:
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ê consegue abusar de alguma forma (realizar um XSS ou carregar um código JS controlado por você? realizar um DoS?...)
Depois de ter **identificado** a **página** que pode ser abusada, qual **parâmetro**/**cabeçalho** usar e **como** abusar dele, você precisa obter a página em cache. Dependendo do recurso que você está tentando colocar em cache, isso pode levar algum tempo, talvez seja necessário 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 colocada em cache e o valor **`hit`** quando está em cache.\
O cabeçalho **`Cache-Control`** também é interessante para saber se um recurso está em cache e quando será a próxima vez que o recurso será colocado em cache novamente: `Cache-Control: public, max-age=1800`\
Outro cabeçalho interessante é o **`Vary`**. Esse 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.\
Ao colocar uma solicitação em cache, 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 **navegadores diferentes** para verificar se está funcionando.
Os cookies também podem ser refletidos na resposta de uma página. Se você puder abusar disso para causar um XSS, por exemplo, você poderá explorar o XSS em vários clientes que carregam a resposta de cache maliciosa.
### Envenenamento de cache com travessia de caminho para roubar chave de API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
[**Este artigo explica**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) como foi possível roubar uma chave de API da OpenAI com uma URL como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` porque qualquer coisa que corresponda a `/share/*` será armazenada em cache sem o Cloudflare normalizar a URL, o que foi feito quando a solicitação chegou ao servidor web.
### Usando vários cabeçalhos para explorar vulnerabilidades de envenenamento de cache na web <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Às vezes, você precisará **explorar várias entradas não-chaveadas** 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 **encaminhando** 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.
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:
Saiba aqui como realizar [ataques de Envenenamento de Cache ao abusar do Contrabando de Requisições HTTP](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning).
O [Scanner de Vulnerabilidades de Cache Web](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) pode ser usado para testar automaticamente o envenenamento de cache web. Ele suporta diversas técnicas e é altamente personalizável.
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** facilmente com as ferramentas comunitárias mais avançadas do mundo.\
O ATS encaminhou o fragmento dentro da URL sem removê-lo e gerou a chave de cache apenas usando o host, caminho e consulta (ignorando o fragmento). Assim, a requisição `/#/../?r=javascript:alert(1)` foi enviada para o backend como `/#/../?r=javascript:alert(1)` e a chave de cache não continha o payload dentro dela, apenas host, caminho e consulta.
Enviar um valor inválido no cabeçalho content-type desencadeou uma resposta em cache 405. A chave de cache continha o cookie, então era possível atacar apenas usuários não autenticados.
O GitLab usa buckets GCP para armazenar conteúdo estático. Os **Buckets GCP** suportam o cabeçalho `x-http-method-override`. Assim, 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`.
Em aplicações Ruby on Rails, o middleware Rack é frequentemente utilizado. O objetivo do código Rack é pegar o valor do cabeçalho **`x-forwarded-scheme`** e defini-lo como o esquema da requisição. Quando o cabeçalho `x-forwarded-scheme: http` é enviado, ocorre um redirecionamento 301 para o mesmo local, potencialmente causando uma Negação de Serviço (DoS) para esse recurso. Além disso, a aplicação pode reconhecer o cabeçalho `X-forwarded-host` e redirecionar os usuários para o host especificado. Esse comportamento pode levar ao carregamento de arquivos JavaScript do servidor de um atacante, representando um risco de segurança.
O Cloudflare anteriormente armazenava em cache respostas 403. Tentar acessar S3 ou Azure Storage Blobs com cabeçalhos de Autorização incorretos resultaria em uma resposta 403 que era armazenada em cache. Embora o Cloudflare tenha parado de armazenar em cache respostas 403, esse comportamento ainda pode estar presente em outros serviços de proxy.
Os caches frequentemente incluem parâmetros GET específicos na chave de cache. Por exemplo, o Varnish da Fastly armazenava o parâmetro `size` nas requisições. No entanto, se uma versão codificada em URL do parâmetro (por exemplo, `siz%65`) também fosse enviada com um valor incorreto, a chave de cache seria construída usando o parâmetro `size` correto. No entanto, o backend processaria o valor no parâmetro codificado em URL. Codificar em URL o segundo parâmetro `size` levava à sua omissão pelo cache, mas sua utilização pelo backend. Atribuir um valor de 0 a esse parâmetro resultava em um erro 400 Bad Request cacheável.
Alguns desenvolvedores bloqueiam requisições com agentes de usuário que correspondem aos de ferramentas de alto tráfego como FFUF ou Nuclei para gerenciar a carga do servidor. Ironicamente, essa abordagem pode introduzir vulnerabilidades como envenenamento de cache e DoS.
O [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica os caracteres aceitáveis em nomes de cabeçalho. Cabeçalhos contendo caracteres fora do intervalo **tchar** especificado idealmente deveriam desencadear uma resposta 400 Bad Request. Na prática, os servidores nem sempre seguem esse padrão. Um exemplo notável é o Akamai, que encaminha cabeçalhos com caracteres inválidos e armazena qualquer erro 400, desde que o cabeçalho `cache-control` não esteja presente. Foi identificado um padrão explorável onde o envio de um cabeçalho com um caractere ilegal, como `\`, resultaria em um erro 400 Bad Request cacheável.
Primeiramente, observe que **extensões** como `.css`, `.js`, `.png`, etc geralmente são **configuradas** para serem **salvas** no **cache**. Portanto, se você acessar `www.example.com/profile.php/nonexistent.js`, o cache provavelmente armazenará a resposta porque vê a extensão `.js`. No entanto, se a **aplicação** estiver **reproduzindo** com o **conteúdo sensível** do usuário armazenado em _www.example.com/profile.php_, você pode **roubar** esses conteúdos de outros usuários.
No exemplo, é explicado que se você carregar uma página inexistente como _http://www.example.com/home.php/non-existent.css_, o conteúdo de _http://www.example.com/home.php_ (**com as informações sensíveis do usuário**) será retornado e o servidor de cache vai salvar o resultado.\
Então, o **atacante** pode acessar _http://www.example.com/home.php/non-existent.css_ em seu próprio navegador e observar as **informações confidenciais** dos usuários que acessaram antes.
Observe que o **proxy de cache** deve ser **configurado** para **armazenar** arquivos **com base** na **extensão** do arquivo (_.css_) e não com base no tipo de conteúdo. No exemplo _http://www.example.com/home.php/non-existent.css_ terá um tipo de conteúdo `text/html` em vez de um tipo mime `text/css` (o esperado para um arquivo _.css_).
Saiba aqui como realizar [ataques de Decepção de Cache abusando do Contrabando de Requisições HTTP](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception).
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** facilmente com as ferramentas comunitárias mais avançadas do mundo.\
<summary><strong>Aprenda hacking 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ê deseja ver sua **empresa anunciada no HackTricks** 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)
* **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.
