Differences

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

--- csrf [2023/12/04 16:53] – lss
+++ csrf [2026/06/16 15:37] (current) – Promjena sadržaja primjera, velike prepravke i prerada mitigacije mbunic
@@ Line 1: / Line 1: @@
 ====CSRF=====
-CSRF (Cross site request forgery) je vrsta napada koja iskorištava ranjivost nastalu zbog ne razlikovanja autentičnih zahtjeva korisnika od krivotvorenih.
+**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.
-Najjednostavniji primjer jest sljedeći:
+Jednostavan primjer:
-Zamislimo da se na adresi <code>www.example.com</code> nalazi bankarska aplikacija koja ima funkcionnalnost gdje se slanjem GET zahtjeva
+Na adresi <code>www.example.com</code> se nalazi bankarska aplikacija koja ima sljedeću funkcionalnost implementiranu GET zahtjevima:
 <code>www.example.com/transfer?amount=1000&to=receiver_username</code>
-šalje količinu novaca u parametru //amount// s računa korisnika koji je napravio taj zahtjev na račun korisnika s korisničkim računom //receiver_username//.
-Napadač može prilagoditi parametre //amount// i //to// u URL-u i poslati takav link žrtvi. Klikom na link, žrtva bi poslala novce napadaču.
+Ovim zahtjevom se izvršava transakcija. U parametru //amount// se definira količina novaca s računa korisnika koji je poslao zahtjev na račun korisnika s korisničkim računom navedenim u parametru //receiver_username//.
-Ovaj napad je moguće izvesti i kreiranjem lažne stranice čime se on dodatno prikrije. Recimo da napadač istraži izgled obrasca POST metodom na stranici <code>www.napadacevastranica.test</code> i on bude izgleda:
+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.
-<code>
+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.
-	<form action="www.example.com/transfer" method="GET">
+Napad bi potencijalno bio moguć i da funkcionalnost koristi POST zahtjev. Pretpostavimo da bankarska aplikacija koristi formu sljedećeg izgleda:
+<code html>
+	<form action="/transfer" method="POST">
 		<label for="amount">Amount: </label>
 		<input type="text" name="amount" id="amount"/>
 		<label for="to">To: </label>
-	 	<input type="text" name="to" id="amount">
+	 	<input type="text" name="to" id="to">
 		<input type="submit"/>
 	</form>
 </code>
+Zatim napadač kreira svoju lažnu stranicu te na njoj postavi sljedeći obrazac:
+<code html>
+	<form action="https://www.example.com/transfer" method="POST">
+		<input type="hidden" name="amount" value="1000"/>
+		<input type="hidden" name="to" value="attacker">
+		<input type="submit" value="REGISTER">
+	</form>
+</code>
+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".
+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>
+<body onload="document.forms[0].submit()">
+	<form...>
+	...
+	</form>
+</body>
+</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 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.
+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//
+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.