Šta se desilo?

U istraživanju objavljenom 17. septembra 2026, bezbednosni istraživač Alex Brumen iz kompanije YesWeHack predstavio je tehniku nazvanu Cache Key Injection, koja zloupotrebljava način na koji pojedini web keš sistemi formiraju ključeve za čuvanje sadržaja.

Problem nastaje kada se više vrednosti promenljive dužine, poput URI-ja, HTTP zaglavlja ili drugih delova zahteva, direktno spoji u jedan cache key bez jasnih separatora. Napadač tada može da napravi dva različita HTTP zahteva koji proizvode isti ključ.

U zavisnosti od konfiguracije, takva kolizija može omogućiti pristup prethodno keširanom zaštićenom sadržaju, trovanje keša, uskraćivanje usluge ili čak stored XSS.

Kako funkcioniše napad?

Web keš sistemi koriste delove HTTP zahteva za formiranje ključa pod kojim se čuva odgovor servera. To mogu biti protokol, host, URI, parametri, kolačići ili HTTP zaglavlja.

Ako se te vrednosti direktno nadovezuju bez separatora, različite kombinacije mogu proizvesti identičan konačni ključ.

Na primer, zahtev za /h sa Accept zaglavljem koje počinje sa ome može proizvesti isti ključ kao legitimni zahtev za /home sa drugačijom Accept vrednošću. Ako je prvi odgovor 404 i bude keširan pod istim ključem, korisnici koji kasnije otvore /home mogu dobiti keširanu grešku umesto legitimne stranice.

Moguće posledice

  • Pristup keširanom sadržaju koji je trebalo da bude dostupan samo autorizovanim korisnicima.
  • Cache-Poisoned Denial of Service (CPDoS), gde se neispravan odgovor kešira umesto legitimne stranice.
  • Trovanje web keša sadržajem koji se zatim prikazuje drugim korisnicima.
  • Stored XSS u specifičnim konfiguracijama gde se napadaču kontrolisana vrednost uključuje u izvršni sadržaj stranice.

Koga pogađa?

Nisu automatski ranjivi svi Nginx, CDN ili Cloudflare sistemi. Rizik postoji kod sistema sa loše definisanim ili prilagođenim cache key konfiguracijama koje spajaju vrednosti promenljive dužine bez jasnih separatora.

Poseban rizik postoji kada se u deljenom kešu čuvaju autentifikovani, osetljivi ili korisnički specifični odgovori.

Istraživanje je demonstrirano sa Nginx-om kao origin cache sistemom, uključujući i scenario u kojem se Cloudflare nalazi ispred Nginx servera.

Kako se zaštititi?

  • Očuvajte nedvosmislene granice komponenti ključa keša, uz strukturno kodiranje ili pravilno obrađene separatore. Proverite da kontrolisani ulaz ne može da poništi te granice.
  • Ne keširajte autentifikovane ili pristupom ograničene odgovore u deljenom kešu osim ako je to pažljivo projektovano.
  • Strogo validirajte Host zaglavlje i druge vrednosti koje korisnik može da kontroliše.
  • Preusmeravajte HTTP saobraćaj na HTTPS gde je moguće.
  • Proverite da CDN i origin cache primenjuju usklađena pravila keširanja.
  • Posebno proverite custom cache key konfiguracije koje uključuju HTTP zaglavlja, kolačiće ili druge korisnički kontrolisane vrednosti.

Tehnički detalji

Problem nastaje kada se cache key formira direktnim spajanjem više vrednosti bez očuvanja njihovih granica.

Na primer, konfiguracija:

proxy_cache_key "$scheme$host$request_uri$http_accept";

može biti dvosmislena ako napadač kontroliše susedne komponente ključa. Bezbedniji pristup je korišćenje jasno definisanih separatora:

proxy_cache_key "$scheme|$host|$request_uri|$http_accept";

Samo heširanje konačnog ključa ne rešava problem. Ako dve različite kombinacije komponenti prvo proizvedu identičan string, rezultat heširanja će takođe biti identičan.

Istraživač je pokazao i scenario sa Cloudflare-om ispred Nginx-a. Authorization zaglavlje može dovesti do toga da Cloudflare zaobiđe sopstveni edge cache i prosledi zahtev origin serveru. Ako Nginx origin cache nema odgovarajuća pravila, napadač i dalje može pokušati da izazove koliziju u njegovom cache key-u.

Zašto je važno?

Istraživanje opisuje kontrolisane demonstracije. Ne dokazuje da su svi Nginx ili Cloudflare sistemi ranjivi niti potvrđuje broj napadnutih organizacija.

Ova tehnika pokazuje da bezbednost keširanja ne zavisi samo od verzije softvera, već i od konfiguracije. Naizgled mala greška u načinu formiranja cache key-a može imati posledice po poverljivost, integritet i dostupnost web aplikacije.

Preporuka Sajber Radara

Pregledajte konfiguraciju cache key-eva na web serverima i CDN slojevima. Nemojte direktno spajati korisnički kontrolisane vrednosti bez separatora i izbegavajte čuvanje osetljivih ili autentifikovanih odgovora u deljenom kešu.