Web Cache Deception | Lab & PoC

O que é Web Cache Deception?

Web Cache Deception (WCD) é uma técnica onde o atacante engana um cache intermediário (CDN, reverse proxy) para armazenar uma resposta que contém dados sensíveis de outro usuário.

A vulnerabilidade existe quando:

1. O cache decide cachear baseado na extensão da URL (.css, .js, .png, etc.)
2. O backend ignora o sufixo e resolve a rota normalmente (/account → dados do usuário)
3. O backend não envia headers Cache-Control adequados (ou o cache os ignora)

Diferença entre Web Cache Deception e Web Cache Poisoning

	Cache Deception	Cache Poisoning
Quem acessa a URL maliciosa?	A vítima	O atacante
O que é cacheado?	Resposta legítima com dados da vítima	Resposta manipulada pelo atacante
Vetor	Induzir vítima a clicar em link	Manipular headers/params que entram na cache key
Resultado	Atacante lê dados privados do cache	Todos os usuários recebem conteúdo malicioso

Anatomia do ataque

Vítima (autenticada) ──→ GET /account/x.css ──→ Nginx (cache)
                                                    │
                                    "extensão .css → cachear!"
                                                    │
                                                    ▼
                                              Flask (backend)
                                              resolve /account
                                              retorna dados sensíveis
                                                    │
                                                    ▼
                                          Nginx armazena no cache
                                          key: /account/x.css

Atacante (não autenticado) ──→ GET /account/x.css ──→ Nginx
                                                        │
                                              cache HIT → retorna
                                              dados da vítima

Pré-requisitos do ataque

1. Cache intermediário que decide cachear por extensão de URL
2. Backend que ignora path segments extras (path normalization)
3. Ausência de Cache-Control: no-store, private nas respostas sensíveis
4. Vítima precisa acessar a URL crafted (requer interação: phishing, img tag, etc.)

Variantes de path confusion

/account/x.css              → extensão estática
/account%2fx.css            → URL encoding
/account/..%2fstatic/x.css  → path traversal normalizado
/account;x.css              → path parameter (Tomcat/Java)
/account%00.css             → null byte (legacy)
/account/.css               → dot segment

Como rodar o lab

Opção 1: Local (Nginx + Flask)

# Instalar dependências
sudo apt install nginx
pip3 install flask

# Iniciar
./setup.sh start

# Em outro terminal, executar exploit
python3 exploit.py --target http://localhost:8080

# Parar
./setup.sh stop

Opção 2: Docker

docker-compose up -d
python3 exploit.py --target http://localhost:8080
docker-compose down

Remediação

1. Backend: Sempre enviar Cache-Control: no-store, private em respostas autenticadas
2. Cache/Proxy: Não cachear baseado apenas em extensão. Respeitar headers do backend
3. Cache/Proxy: Configurar proxy_cache_bypass para requests com Cookie
4. WAF: Bloquear URLs com extensões estáticas em paths de aplicação

Fix no Nginx:

location ~* \.(css|js|png|jpg)$ {
    # Não cachear se tem cookie de sessão
    proxy_cache_bypass $http_cookie;
    proxy_no_cache $http_cookie;
    # ... resto da config
}

Fix no backend (Flask):

@app.after_request
def add_cache_headers(response):
    if "user" in session:
        response.headers["Cache-Control"] = "no-store, private"
    return response