# Web Cache Deception

O **Web Cache Deception (WCD)** é uma vulnerabilidade descoberta em 2017 que permite que um atacante engane um cache web (como Cloudflare, Akamai ou Varnish) para que ele armazene dados sensíveis e privados de uma vítima em uma URL que o atacante pode acessar posteriormente.

Ao contrário do *Cache Poisoning*, onde o atacante injeta conteúdo malicioso para outros usuários, no *Cache Deception* o atacante faz com que o servidor "vaze" dados legítimos de usuários para o cache público.

***

## **🏗️ Como funciona o Web Cache Deception?**

A vulnerabilidade baseia-se em uma discrepância de interpretação de URLs entre o **Cache** e o **Servidor de Origem**.

1. **Cache:** Frequentemente configurado para armazenar "arquivos estáticos" baseando-se na extensão da URL (.jpg, .css, .js).
2. **Servidor:** Muitas vezes configurado para ignorar partes extras da URL ou tratá-las como parâmetros se a rota principal for encontrada.

***

## **⚔️ Ataque Passo a Passo**

{% stepper %}
{% step %}

### **Vítima Autenticada**

A vítima está logada em `site.com`.
{% endstep %}

{% step %}

### **Link Malicioso**

O atacante induz a vítima a clicar em um link como:

`https://site.com/api/user/details/nonexistent.jpg`
{% endstep %}

{% step %}

### **Processamento no Servidor**

O servidor recebe o pedido, ignora o `/nonexistent.jpg` e retorna as informações privadas do perfil da vítima (JSON/HTML).
{% endstep %}

{% step %}

### **Decisão do Cache**

O cache vê a extensão `.jpg` e pensa: "Este é um arquivo de imagem estático, todo mundo pode ver". Ele armazena a resposta (que contém os dados privados da vítima) em seu buffer.
{% endstep %}

{% step %}

### **Exfiltração**

O atacante acessa a mesma URL e o cache entrega a cópia armazenada dos dados da vítima para ele.
{% endstep %}
{% endstepper %}

***

## **⚖️ Deception vs Poisoning**

| Característica | Web Cache Poisoning                      | Web Cache Deception                          |
| -------------- | ---------------------------------------- | -------------------------------------------- |
| **Objetivo**   | Injetar conteúdo (XSS) no cache.         | Roubar dados privados de usuários.           |
| **Vetor**      | Cabeçalhos maliciosos (Unkeyed).         | Manipulação de caminhos de URL.              |
| **Vítima**     | Qualquer um que acesse a URL envenenada. | O usuário que foi induzido a clicar no link. |

***

## **🔧 Técnicas de Exploração**

### **1. Delimitadores de Path**

Tente diferentes caracteres que o servidor possa ignorar, mas que o cache use para identificar extensões:

* `/profile/test.php/test.jpg`
* `/profile/test.php%00.jpg`
* `/profile/test.php?test.jpg`
* `/profile/test.php;test.jpg` (Muito comum em servidores Java/Spring)

### **2. Path Mapping Divergence**

Se o site usa o framework Django, ele pode aceitar as URLs de forma muito permissiva. Teste extensões de arquivos comuns de cache: `.css`, `.js`, `.png`, `.svg`, `.woff2`.

***

## **🔍 Detecção e Ferramentas**

### **1. Burp Suite**

Use o **Logger++** para observar as respostas do servidor. Se você ver um `Cache-Control: public` em uma página que contém dados sensíveis após adicionar um sufixo estático, a aplicação é vulnerável.

### **2. Analisando Cabeçalhos de Cache**

Procure por indicadores de sucesso na gravação do cache:

* `X-Cache: MISS` (Primeira vez - Vítima)
* `X-Cache: HIT` (Segunda vez - Atacante)

***

## **🛡️ Mitigação e Prevenção**

### **1. Cache-Control Rigoroso**

Sempre use `Cache-Control: no-store, private` para qualquer endpoint que retorne dados do usuário. Isso diz explicitamente ao cache para **nunca** armazenar aquele conteúdo.

### **2. Validar Extensões (Strict Path Handling)**

Configure o servidor web para retornar um erro **404 Not Found** se a URL terminar em uma extensão de arquivo que não existe fisicamente ou que não faz parte da rota esperada.

### **3. Usar cabeçalho `X-Content-Type-Options: nosniff`**

Isso ajuda a evitar que o cache tente "adivinhar" o tipo de conteúdo se o servidor não o declarar corretamente.

{% hint style="warning" %}
O Web Cache Deception é uma falha de configuração de infraestrutura. Ela é perigosa pois permite roubar tokens de sessão (Cookies), chaves de API e dados pessoais sem a necessidade de XSS ou outras falhas de código.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://0xmorte.gitbook.io/bibliadopentestbr/tecnicas/web/server-side-infraestrutura-web/web-cache-deception.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.