Razlike

Slijede razlike između dviju inačica stranice.

--- racfor_wiki:cross_site_request_forgery_napadi [2021/01/17 16:06]
sbrkic dorada formatiranja, ispravak gramatike
+++ racfor_wiki:cross_site_request_forgery_napadi [2024/12/05 12:24] (trenutno)
@@ Redak 1: / Redak 1: @@
 ===== Cross Site Request Forgery napadi =====
-===== Sažetak =====
+==== Sažetak ====
 CSRF napadi vrsta su mrežnih napada u kojima napadač zloupotrebom HTTP protokola i implementacija web preglednika nastoji postići da žrtva koristeći svoj web preglednik podnese HTML formu bez vlastite privole, a često i bez znanja da je forma uopće podnesena. U ovom radu obrađeno je funkcioniranje HTTP kolačića i HTML formi, koji su preduvjet za CSRF napade. Opisana je glavna ideja i tijek CSRF napada, kao i dvije varijante izvođenja, ovisno o vrsti HTML forme. Objašnjena je zaštita od CSRF napada, kao i dva najčešća pristupa njenoj implementaciji.
-===== Uvod =====
+==== Uvod ====
 Ispunjavanje formi (formulara) često je korištena funkcionalnost web preglednika. Primjerice svaki puta kada se korisnik prijavljuje u web stranicu on popunjava formu. HTML forme koriste se i za ostale namjene, a neke od njih su i monetarne prirode, primjerice ispunjavanje forme na stranici banke u cilju uplate na drugi bankovni račun. CSRF (engl. Cross-Site Request Forgery) napadi koriste se kako bi žrtva bez privole/znanja ispunila i poslala HTML formu. Bitan aspekt CSRF napada su HTML forme i način na koji se one prenose sa klijenta na poslužitelj. Jednako bitan aspekt je i autentifikacija korisnika (u kontekstu napada: žrtve), koja se najčešće implementira korištenjem kolačića, čija je funkcionalnost objašnjena u idućem poglavlju.
-===== Osnove HTTP kolačića (engl. cookies) =====
+==== Osnove HTTP kolačića (engl. cookies) ====
-Protokol HTTP u svojim inicijalnim verzijama nije imao nikakvu mogućnost pohrane stanja (engl. stateless), odnosno svi klijentski zahtjevi na poslužitelju su se obrađivali anonimno, pri čemu poslužitelj nije mogao odrediti identitet korisnika koji je uputio pojedini zahtjev.  Vrlo brzo je razvojem weba došlo do potrebe za identifikacijom pojedinih korisnika, primarno u cilju pružanja bolje usluge korisniku (pamćenje upisanih podataka u formama, personalizirane poruke korisniku i slično).
+Protokol HTTP u svojim inicijalnim verzijama nije imao nikakvu mogućnost pohrane stanja (engl. stateless), odnosno svi klijentski zahtjevi na poslužitelju su se obrađivali anonimno, pri čemu poslužitelj nije mogao odrediti identitet korisnika koji je uputio pojedini zahtjev [1].  Vrlo brzo je razvojem weba došlo do potrebe za identifikacijom pojedinih korisnika, primarno u cilju pružanja bolje usluge korisniku (pamćenje upisanih podataka u formama, personalizirane poruke korisniku i slično).
 Kolačići (engl. cookies) najkorištenija su metoda identifikacije korisnika. Razvijeni su u kompaniji Netscape, a njihovo korištenje ubrzo je standardizirano i implementirano od strane svih većih web preglednika.
@@ Redak 28: / Redak 28: @@
 Na poslijetku, u slučaju C prikazan je idući zahtjev koji klijent upućuje prema istom poslužitelju, ali ovaj puta je prisutno zaglavlje ''Cookie'', te je u njega upisan sadržaj kolačića, odnosno navedeni par ključ-vrijednost.
-==== Konfiguracija kolačića ====
+=== Konfiguracija kolačića ===
 Poslužitelj može konfigurirati razne parametre vezane uz funkcionalnost kolačića korištenjem specijalnih ključeva u kolačiću. Nazivi  tih specijalnih ključeva su: Expires, Domain, Path, i Secure.
@@ Redak 43: / Redak 43: @@
 === Autentifikacija putem kolačića ===
-Danas se kolačići često koriste za autentifikaciju korisnika uz tzv. poslužiteljske sjednice. Za svakog klijenta se na poslužitelju generira sjednica, koja se najčešće pohranjuje u bazu podataka. Identifikator sjednice zapisuje se u kolačić na klijentu. U svim zahtjevima prema poslužitelju klijent šalje kolačić sa identifikatorom sjedince koji posluzitelj koristi za daljnju obradu zahtjeva. Ovom metodom u kolačiću se ne pohranjuju osjetljive vrijednosti sjednice, već samo identifikator koji poslužitelju služi za dohvat iste.
+Danas se kolačići često koriste za autentifikaciju korisnika uz tzv. poslužiteljske sjednice. Za svakog klijenta se na poslužitelju generira sjednica, koja se najčešće pohranjuje u bazu podataka. Identifikator sjednice zapisuje se u kolačić na klijentu. U svim zahtjevima prema poslužitelju klijent šalje kolačić sa identifikatorom sjedince koji poslužitelju koristi za daljnju obradu zahtjeva. Ovom metodom u kolačiću se ne pohranjuju osjetljive vrijednosti sjednice, već samo identifikator koji poslužitelju služi za dohvat iste.
 Iako ova metoda autentifikacije nije preduvjet za CSRF napade, danas se vrlo često koristi u praksi.
@@ Redak 50: / Redak 50: @@
 ==== Osnove HTML formi ====
-HTML forme jedan su od načina na koji korisnik može podatke prenijeti na posluzitelj. Koncipirane su kao parovi vrijednosti ključ-vrijednost, slično kolačićima.
+HTML forme jedan su od načina na koji korisnik može podatke prenijeti na poslužitelj. Koncipirane su kao parovi vrijednosti ključ-vrijednost, slično kolačićima.
 Jednostavan primjer koda HTML forme prikazan je u nastavku:
@@ Redak 90: / Redak 90: @@
 Vrlo bitna karakteristika ovog pristupa prijenosu HTML formi na poslužitelj je ta što je gore navedeni primjer URL-a moguće distribuirati kao običnu poveznicu (engl. link). Svaki korisnik koji bi u svojem web pregledniku kliknuo na navedenu poveznicu bi na poslužitelj poslao  zahtjev sa istim parametrima, iako korisnik uopće nije popunjavao nikakvu HTML formu u svojem pregledniku.
-=== Prijenos HTML formi korištnjem POST zahtjeva ===
+=== Prijenos HTML formi korištenjem POST zahtjeva ===
 Ukoliko HTML forma koristi POST zahtjev za prijenos na poslužitelj, parovi ključ-vrijednost enkodiraju se i šalju u tijelu zahtjeva prema poslužitelju. Razlika u odnosu na prethodno opisanu metodu je u tome što se korištenjem POST zahtjeva parametri forme ne nalaze u URL-u, odnosno nije moguće klikom na URL poslati parametre poslužitelju. Slika 3 prikazuje primjer prijenosa HTML forme korištenjem POST zahtjeva.
@@ Redak 96: / Redak 96: @@
 {{:racfor_wiki:csrf-post-forma.png|Slika 3: prijenos HTML forme korištenjem POST zahtjeva}}
-Korisnik je u pregledniku u polje ''item'' upisao vrijednost ''bandsaw 2647'', nakon čega je preglednik navedeni par ključ-vrijednost upisao u tijelo HTTP zahtjeva prema poslužitelju. Putanja zahtjeva glasi ''/inventory-check.cgi'' te je očito da ne sadrži parametre, tj. vrijednosti forme.
+Korisnik je u pregledniku u polje ''item'' upisao vrijednost ''bandsaw 2647'', nakon čega je preglednik navedeni par ključ-vrijednost upisao u tijelo HTTP zahtjeva prema poslužitelju. Putanja zahtjeva glasi ''/inventory-check.cgi'' te je očito kako ne sadrži parametre, tj. vrijednosti forme.
-=== Ideja i tijek CSRF napada ===
+==== Ideja i tijek CSRF napada ====
-CSRF (engl. Cross-Site Request Forgery) napadi temelje se na korištenju kolačića za autentifikaciju korisnika, te na načinu na koji se HTML forme s klijenta šalju poslužitelju.
+CSRF (engl. Cross-Site Request Forgery) napadi temelje se na korištenju kolačića za autentifikaciju korisnika, te na načinu na koji se HTML forme s klijenta šalju poslužitelju [2].
 Zamislimo da neka banka ima mrežnu stranicu na kojoj svojim korisnicima nudi opciju uplate novca na neki drugi račun, primjerice za plaćanje režija. Jednostavan primjer HTML forme za ostvarivanje navedene funkcionalnosti prikazan je u  nastavku.
@@ Redak 117: / Redak 117: @@
 Pretpostavimo da navedena stranica banke koristi kolačiće za autentifikaciju korisnika. Kako je opisano u prošlim poglavljima, to spodrazumijeva da će korisnikov web preglednik, nakon inicijalne prijave u sustav, uz svaki HTTP zahtjev **automatski** dostavljati i kolačić koji identificira (i autentificira) korisnika.
-Bitno je uočiti kako je i slanje HTML forme na poslužitelj zapravo običan HTTP zahtjev, te će korisnikov preglednik automatski u zaglavlje zahtjeva dodati vrijednost kolačića. Primjerice, ako je legitiman korisnik bankarske stranice odlučio na račun `1234` uplatiti `100` kuna, klikom na gumb  "Slanje" web preglednik šalje iduci zahtjev poslužitelju:
+Bitno je uočiti kako je i slanje HTML forme na poslužitelj zapravo običan HTTP zahtjev, te će korisnikov preglednik automatski u zaglavlje zahtjeva dodati vrijednost kolačića. Primjerice, ako je legitiman korisnik bankarske stranice odlučio na račun `1234` uplatiti `100` kuna, klikom na gumb  "Slanje" web preglednik šalje idući zahtjev poslužitelju:
 <code>
@@ Redak 136: / Redak 136: @@
-==== CSRF napadi uz korištenje prijenosa HTML forme POST zahtjevom ====
+=== CSRF napadi uz korištenje prijenosa HTML forme POST zahtjevom ===
@@ Redak 149: / Redak 149: @@
 </code>
-Forma je vrlo slična onoj iz prethodnog poglavlja gdje se koristio GET zahtjev za slanje forme, a jedina razlika je u tome što je u `method` atributu forme specifirana vrijednost `POST`. Klikom na gumb "Slanje" korisnikov web preglednik šalje idući POST zahtjev poslužitelju:
+Forma je vrlo slična onoj iz prethodnog poglavlja gdje se koristio GET zahtjev za slanje forme, a jedina razlika je u tome što je u ''method'' atributu forme specifirana vrijednost ''POST''. Klikom na gumb "Slanje" korisnikov web preglednik šalje idući POST zahtjev poslužitelju:
 <code>
@@ Redak 164: / Redak 164: @@
 <form action="example.com/uplata", method="POST">
   <!-- sakriveni dio forme -->
-  <input type="number"    name="broj_racuna"  type="hidden">
+  <input type="number"    name="broj_racuna"  type="hidden" value="1234">
-  <input type="number"    name="iznos_hrk"    type="hidden">
+  <input type="number"    name="iznos_hrk"    type="hidden" value="9999">
   <!-- benigni dio forme   -->
   <input type="text"      name="benigno_polje">
@@ Redak 176: / Redak 176: @@
 U prikazanom primjeru zloupotrebljava se atribut ''type'' HTML forme čija je vrijednost postavljena na ''hidden'' za ključeve ''broj_racuna'' i ''iznos_hrk'', što znači da se navedena polja **ne će prikazati u žrtvinom web poslužitelju**. Međutim, klikom na gumb "Slanje" sva polja u formi će se poslati, uključujući i ona koja su postavljena kao sakrivena. Napadač navedenu formu treba objaviti na nekoj web stranici te "natjerati" žrtvu da ju ispuni odnosno pošalje.
-Osim činjenice da ovu varijantu napada, za razliku od GET varijante, nije vrlo jednostavno izvesti, dodatna manjkavost ove varijante je u tome sto se u zahtjevu prema poslužitelju banke šalje i dodatna vrijednost u formi, odnosno ključ ''benigno_polje''. Ukoliko bankarski poslužitelj vrši validaciju forme, tj. provjerava da se u formi nalaze točno oni ključevi koji se moraju nalaziti, poslužitelj invalidira pridospjeli zahtjev, te napad ne uspijeva.
+Osim činjenice da ovu varijantu napada, za razliku od GET varijante, nije vrlo jednostavno izvesti, dodatna manjkavost ove varijante je u tome što se u zahtjevu prema poslužitelju banke šalje i dodatna vrijednost u formi, odnosno ključ ''benigno_polje''. Ukoliko bankarski poslužitelj vrši validaciju forme, tj. provjerava da se u formi nalaze točno oni ključevi koji se moraju nalaziti, poslužitelj invalidira pridospjeli zahtjev, te napad ne uspijeva.
 === CSRF napadi maskirani u HTML slike ===
@@ Redak 194: / Redak 194: @@
 ==== Prevencija CSRF napada ====
-Postoje dva osnovna načina zaštite od CSRF napada, a oba se temelje na nasumično generiranoj tajnoj vrijednosti koju poslužitelj šalje legitimnom klijentu, a klijent primljenu vrijednost prenosi poslužitelju kao dodatni parametar HTML forme. Poslužitelj zatim provjerava jednakost poslane i primljene tajne vrijednosti. Taj se tajni ključ naziva CSRF token ili sinkronizacijski token.
+Postoje dva osnovna načina zaštite od CSRF napada [3], a oba se temelje na nasumično generiranoj tajnoj vrijednosti koju poslužitelj šalje legitimnom klijentu, a klijent primljenu vrijednost prenosi poslužitelju kao dodatni parametar HTML forme. Poslužitelj zatim provjerava jednakost poslane i primljene tajne vrijednosti. Taj se tajni ključ naziva CSRF token ili sinkronizacijski token.
 Ideja je da napadač ne moze izvršiti CSRF napad jer ne može pogoditi tajnu vrijednost koju je poslužitelj poslao legitimnom klijentu, ako je vrijednost uopće poslana.
@@ Redak 221: / Redak 221: @@
-===== Zaključak =====
+==== Zaključak ====
 CSRF napadi vrlo su opasni jer ih je u nekim slučajevima moguće izvesti a da žrtva toga nije svjesna. Radi svestranih primjena HTML formi u različite svrhe, poslijedice napada mogu biti od velikog utjecaja za žrtvu. Na sreću, CSRF napadi otkriveni su rano, a iako ranjivosti koje napadi zloupotrebljavaju nije moguće eliminirati,  prevencija CSRF napada je relativno jednostavna za implementirati te bi se trebala koristiti pri obradi svake forme na web stranici.
@@ Redak 227: / Redak 227: @@
-===== Literatura =====
+==== Literatura ====
 [1] [[ https://books.google.hr/books/about/HTTP_The_Definitive_Guide.html?id=qEoOl9bcV_cC&redir_esc=y |David Gourley, Brian Totty, Marjorie Sayer, Anshu Aggarwal and Sailu Reddy. HTTP: The Definitive Guide. O'Reilly Media, Inc., 2002.]]
@@ Redak 235: / Redak 235: @@
 [3] [[https://en.wikipedia.org/wiki/Cross-site_request_forgery | Wikipedia: Cross-site request forgery. Pristupljeno: 12. 2020.]]
+==== Izvori slika ====
+Sve slike preuzete su iz knjige [1].

racfor_wiki/cross_site_request_forgery_napadi.1610899593.txt.gz · Zadnja izmjena: 2024/12/05 12:23 (vanjsko uređivanje)