Differences

This shows you the differences between two versions of the page.

--- csrf [2026/06/16 13:39] – ispravke, sadrzaj mbunic
+++ csrf [2026/06/16 15:37] (current) – Promjena sadržaja primjera, velike prepravke i prerada mitigacije mbunic
@@ Line 1: / Line 1: @@
 ====CSRF=====
-**CSRF** (engl. //cross site request forgery//) je vrsta napada koja iskorištava ranjivost nastalu zbog nerazlikovanja autentičnih korisničkih zahtjeva od krivotvorenih zahtjeva, često s drugih stranica.
+**CSRF** (engl. //cross site request forgery//) je vrsta napada koja iskorištava ranjivost nastalu zbog nerazlikovanja autentičnih korisničkih zahtjeva od krivotvorenih zahtjeva s drugih stranica.
 Jednostavan primjer:
@@ Line 12: / Line 12: @@
 Napadač može prilagoditi parametre //amount// i //to// u URL-u i poslati takav link žrtvi. Klikom na link, ako je žrtva aktivno prijavljena u bankarsku aplikaciju i ima aktivnu sesiju, žrtva bi poslala novce napadaču.
+Napadač može na svojoj zlonamjernoj stranici napisati JavaScript kod koji se izvršava automatski posjetom stranice i u pozadini šalje ovaj zahtjev. Web preglednik žrtve automatski dodaje kolačić sa sesijom za domenu stranice banke uz zahtjev, ako žrtva ima aktivnu sesiju na stranici banke te se transakcija izvršava u žrtvinom kontekstu. Ovo je primjer CSRF napada.
 Napad bi potencijalno bio moguć i da funkcionalnost koristi POST zahtjev. Pretpostavimo da bankarska aplikacija koristi formu sljedećeg izgleda:
@@ Line 40: / Line 43: @@
 Kada bi žrtva posjetila napadačevu stranicu i pokušala se registrirati klikom na gumb REGISTER, poslala bi zahtjev POST prema <code>www.example.com/transfer</code> s parametrima amount i to postavljenim na "1000" i "attacker".
-No, slanje ovog zahtjeva je moguće automatizirati tako da ga žrtva pošalje samim posjetom stranice. Npr. dodavanjem funkcije submit u onload atribut u body elementu:
+Slanje ovog zahtjeva je također moguće automatizirati tako da ga žrtva pošalje samim posjetom stranice. Npr. dodavanjem funkcije submit u onload atribut u body elementu:
 <code html>
@@ Line 50: / Line 53: @@
 </code>
-Ako je žrtva u trenutku kada posjeti napadačevu stranicu prijavljena u bankarsku aplikaciju i ako je ta aplikacija ranjiva na CSRF napade, novac bi se sa žrtvinog računa prebacio na napadačev.
+Ako je žrtva u trenutku kada posjeti napadačevu stranicu prijavljena u bankarsku aplikaciju i ako je ta aplikacija ranjiva na CSRF napade, novac bi se i u ovom slučaju prebacio sa žrtvinog računa na napadačev.
+===Prevencija CSRF ranjivosti===
+Osnovni razlog ranjivosti na CSRF napade je nedostatak mehanizma za provjeru zahtjeva, kojim bi se razlikovalo dolazi li zahtjev iz legitimnog korisničkog konteksta.
+Uobičajena zaštita od ovakvih napada je korištenje CSRF tokena. To su nasumično generirane vrijednosti čija se jedna kopija vrijednosti šalje korisniku uz odgovor poslužitelja, dok se druga pohranjuje na poslužitelju radi kasnije provjere. Često imaju kratak period valjanosti.
+Unutar POST zahtjeva klijent šalje predani token natrag nakon čega poslužitelj provjerava njegovu validnost, uspoređujući ga s vrijednošću pohranjenom na poslužitelju kako bi se odredilo jesu li vrijednosti iste. Ako je vrijednost ispravna, zahtjev se izvršava i generira se novi token.
-Osnovni razlog za CSRF napade je da web aplikacija nema implementirane mehanizme po kojima bi mogla razlikovati legitimne od nelegitimnih zahtjeva.
+Alternativno, postoji i drugi pristup gdje se kopija vrijednosti nakon generiranja ne pohranjuje na poslužitelju, već se samo šalje korisniku. Korisnički zahtjev u tom slučaju mora sadržavati istu vrijednost tokena na dva mjesta: u kolačiću i unutar samog zahtjeva (npr. uz HTTP formu ili kao parametar zahtjeva). Ovakav pristup se naziva //double submit cookie pattern//
-Najbolja zaštita od ovakvih napada je korištenje CSRF tokena. To su nasumično generirane vrijednosti čija
+Ako su CSRF tokeni ispravno implementirani, napadač ne može pogoditi niti saznati vrijednost CSRF tokena, pa zato ne može uspješno lažirati zahtjev korisnika. CSRF tokeni se uglavnom ne koriste u [[HTTP]] GET zahtjevima zbog čega je važno da GET zahtjevi ne mijenjaju stanje u aplikaciji.
-u sjednicu korisnika svakim novim zahtjevom i imaju kratak period trajanja. Unutar svakog novog zahtjeva klijent šalje predani token natrag nakon čega poslužitelj provjerava njegovu validnost. Ako je vrijednost ispravna, zahtjev se izvršava i postavlja se novi token. Budući da (ako su CSRF tokeni ispravno implementirani) napadač ne može pogoditi vrijednost CSRF tokena, ne može ni lažirati korisnički zahtjev. CSRF tokeni se često ne postavljaju u [[HTTP]] GET zahtjeve zbog čega je bitno da se GET zahtjevima ne može mijenjati stanje u aplikaciji.