====Dijeljeni Web Cache====

**Dijeljeni Web Cache** je mehanizam za optimizaciju posluživanja statičnih resursa većem broju korisnika, često implementiran kao dio reverse proxy komponente. Kako web-poslužitelj ne bi morao pri svakom zahtjevu ponovno posluživati istu statičnu datoteku, primjerice ''style.css'' ili ''script.js'', reverse proxy pohranjuje odgovor koji sadrži taj resurs te ga pri sljedećem zahtjevu može izravno poslužiti iz cachea, umjesto da svaki put prosljeđuje zahtjev izvornom poslužitelju.

=== Obrada zahtjeva i cache zaglavlja odgovora ===

Cache poslužitelj na temelju primljenog zahtjeva određuje je li zatraženi resurs prikladan za pohranu u cache. Ako je, onda iz zahtjeva konstruira **cache key** i provjerava postoji li pod tim ključem već pohranjeni odgovor. Ako pohranjeni odgovor već postoji i nije prestar, poslužuje ga direktno. Ako je konfigurirano da se koriste cache zaglavlja u odgovoru, cache status će imati vrijednost **HIT**. 

Ako je pohranjen resurs prestar (zadnja verzija je pohranjena prije više vremena nego što je dopušteno konfiguracijom), tada se prosljeđuje zahtjev serveru, te se potom odgovor servera pohranjuje u cache i prosljeđuje nazad korisniku uz vrijednost cache zaglavlja **EXPIRED**.

Ako nikakva prijašnja verzija tog resursa nije bila pohranjena u cache, tada se zahtjev također prosljeđuje serveru, čiji se odgovor onda pohranjuje u cache i prosljeđuje nazad korisniku uz zaglavlje **MISS**.

Ako cache poslužitelj zaključi da zahtjev nije prikladan za korištenje cachea, prosljeđuje ga serveru, a odgovor servera zatim prosljeđuje korisniku. U ovom slučaju cache status je **BYPASS**.


Server na koji cache poslužitelj prosljeđuje zahtjeve i pohranjuje odgovore može davati upute cache poslužitelju o tome bi li se pojedini resurs trebao pohraniti u cache preko zaglavlja ''Cache-Control''. Ponekad cache poslužitelj ignorira te upute te koristi vlastitu konfiguraciju.

=== Cache key ===

**Cache key** može se smatrati jedinstvenim identifikatorom pod kojim cache poslužitelj pohranjuje odgovor. Konstruira se iz zahtjeva, tako da ako dva zahtjeva rezultiraju istim cache keyem, za oba zahtjeva je relevantan isti cache resurs. U tom slučaju odgovor koji je bio poslužen na prvi zahtjev može biti poslužen i na drugi bez opterećivanja servera.

Jedan od glavnih dijelova cache keya je URL putanja, dok URL query često ne ulazi u cache key, osim u određenim slučajevima.
Osim URL putanje, često se koriste i URL scheme, host, port te određeni request headeri.

=== Primjeri napada ===

Neispravno konfigurirana pravila za konstrukciju cache keya ili neusklađena URL normalizacija između cache poslužitelja i web servera mogu dovesti do ranjivosti koje omogućuju napade kao što su **Cache deception** i **Cache poisoning**.

Jedan primjer ranjivosti nastaje kada cache poslužitelj pohranjuje odgovore na zahtjeve čije putanje počinju s '/static/' i pritom ne normalizira URL, dok izvorni poslužitelj to čini.

U tom slučaju cache poslužitelj može zaključiti da je odgovor na zahtjev sa sljedećim URL-om:

<code>
/static/../internal-profile
</code>

potrebno pohraniti u cache, dok će server ovaj URL normalizirati u:

<code>
/internal-profile
</code>

Server će za ovaj zahtjev poslužiti dinamički generiran odgovor s potencijalno osjetljivim podatcima korisnika koji će cache pohraniti. Drugi korisnik nakon toga može poslati zahtjev koji rezultira istim cache keyem i tako iz cachea dobiti odgovor s osjetljivim podacima prethodnog korisnika. Ovo je primjer **Cache Deception** napada.


Drugi primjer ranjivosti nastaje kada cache poslužitelj naivno pohranjuje odgovore na zahtjeve čiji URL završava sufiksom ''.js'' ili ''.css'' te uključuje URL query u konstrukciju cache keya, dok izvorni poslužitelj ignorira nepoznate URL parametre.

Ako napadač može manipulacijom zahtjeva izazvati generiranje odgovora koji sadrži XSS payload, a koji inače ne bi mogao iskoristiti za napad na druge korisnike, napadač može koristiti ranjivi cache poslužitelj kako bi pohranio odgovor s payloadom u cache te ga naknadno poslužio drugim korisnicima.

Napadač u zahtjevu šalje payload za konstrukciju XSS napada u odgovoru, te postavlja URL u 

<code>
/dashboard?undefined_parametar=.js
</code>

Server ignorira URL query te vraća odgovor s XSS napadom te cache pohranjuje taj odgovor. Dok se odgovor koji sadrži XSS payload nalazi u cacheu, drugom korisniku može biti poslužen taj odgovor ako njegov zahtjev rezultira istim cache keyem.

Napadač to može iskoristiti tako da drugom korisniku pošalje link koji će rezultirati izračunom istog cache keya zahtjeva kao i onaj pod kojim je pohranjen napadačev payload:

<code>
stranica/dashboard?undefined_parametar=.js
</code>

kako bi osigurao da se žrtvi posluži njegov XSS napad koji je pohranjen u cacheu. Ovo je primjer  korištenja **Cache poisoning** tehnike za distribuciju napada, cache poisoning sam po sebi nije napad nego način distribucije drugog napada, kao što je XSS, žrtvama.