Hacknite Wiki

User Tools

Site Tools

Trace:
csrf

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
csrf [2023/12/04 17:43] – lsscsrf [2026/06/16 15:37] (current) – Promjena sadržaja primjera, velike prepravke i prerada mitigacije mbunic
Line 1: Line 1:
 ====CSRF===== ====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> <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//. 
 + 
 +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: Napad bi potencijalno bio moguć i da funkcionalnost koristi POST zahtjev. Pretpostavimo da bankarska aplikacija koristi formu sljedećeg izgleda:
  
-<code>+<code html>
  
  <form action="/transfer" method="POST">  <form action="/transfer" method="POST">
Line 20: Line 24:
  <input type="text" name="amount" id="amount"/>  <input type="text" name="amount" id="amount"/>
  <label for="to">To: </label>  <label for="to">To: </label>
- <input type="text" name="to" id="amount">+ <input type="text" name="to" id="to">
  <input type="submit"/>  <input type="submit"/>
  </form>  </form>
Line 27: Line 31:
 </code> </code>
  
-Zatim kreira svoju lažnu stranicu te na njoj postavi sljedeći obrazac: +Zatim napadač kreira svoju lažnu stranicu te na njoj postavi sljedeći obrazac: 
-<code>+ 
 +<code html>
  <form action="https://www.example.com/transfer" method="POST">  <form action="https://www.example.com/transfer" method="POST">
  <input type="hidden" name="amount" value="1000"/>  <input type="hidden" name="amount" value="1000"/>
Line 38: 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". 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>+<code html>
 <body onload="document.forms[0].submit()"> <body onload="document.forms[0].submit()">
  <form...>  <form...>
Line 48: Line 53:
 </code> </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. 
  
-Osnovni razlog za CSRF napade je da web aplikacija nema implementirane mehanizme po kojima bi mogla razlikovati legitimne od nelegitimnih zahtjeva.+===Prevencija CSRF ranjivosti===
  
-Najbolja zaštita od ovakvih napada je korištenje CSRF tokena. To su nasumično generirane vrijednosti čija +Osnovni razlog ranjivosti na CSRF napade je nedostatak mehanizma za provjeru zahtjeva, kojim bi se razlikovalo dolazi li zahtjev iz legitimnog korisničkog konteksta.
-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.+
  
-__**Primjer**__ - **Zadatak s Hacknite platforme -"Korisni linkovi"**+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.
  
-<file> +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.
-Mario je napravio stranicu preko koje si korisnici šalju poveznice. On je administrator na stranici s +
  
-korisničkim imenom "admin". U prilošku zadatka je dana datoteka "user.php". Kako bi zadatak simulirao +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//
  
-korisnike na stranici, svaka poveznica koja se pošalje je otvorena.   +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.
-</file>+
  
  
  
  
csrf.1701711837.txt.gz · Last modified: 2025/12/01 11:40 (external edit)
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki