Kako se kolačići istog mjesta mogu koristiti za ublažavanje CSRF napada?
Kolačići iste stranice važan su sigurnosni mehanizam koji se može upotrijebiti za ublažavanje napada krivotvorenja zahtjeva između stranica (CSRF) u web aplikacijama. CSRF napadi se događaju kada napadač prevari žrtvu da izvede nenamjernu radnju na web stranici na kojoj je žrtva autentificirana. Iskorištavanjem žrtvine sesije, napadač može izvoditi radnje u ime žrtve bez njenog pristanka.
Kolačići istog mjesta pomažu u sprječavanju CSRF napada ograničavanjem opsega kolačića na isto podrijetlo. Izvor je definiran kombinacijom protokola (npr. HTTP ili HTTPS), domene i broja priključka. Kada je kolačić postavljen s atributom "SameSite", on određuje treba li se kolačić slati u zahtjevima između stranica.
Postoje tri moguće vrijednosti za atribut "SameSite":
1. "Strict": Kada je atribut "SameSite" postavljen na "Strict", kolačić se šalje samo u zahtjevima koji potječu s iste stranice. To znači da se kolačić neće slati u zahtjevima između stranica, čime se učinkovito sprječavaju CSRF napadi. Na primjer, ako je korisnik autentificiran na "example.com" i posjeti zlonamjernu stranicu koja pokušava izvesti CSRF napad, preglednik neće uključiti "Strogi" kolačić iste stranice u zahtjev, čime će se spriječiti napad.
2. "Lax": Kada je atribut "SameSite" postavljen na "Lax", kolačić se šalje u zahtjevima između web-mjesta koji se smatraju sigurnima, primjerice kada zahtjev pokreće navigacija najviše razine korisnika. Međutim, kolačić se ne šalje u zahtjevima koje pokreću web-mjesta trećih strana, primjerice kada se slika ili oznaka skripte učitaju s druge domene. To osigurava ravnotežu između sigurnosti i upotrebljivosti. Na primjer, korisnik koji posjećuje zlonamjerno web-mjesto putem veze neće pokrenuti CSRF napad jer "Lax" kolačić istog web-mjesta neće biti uključen u zahtjev.
3. "None": Kada je atribut "SameSite" postavljen na "None", kolačić se šalje u svim zahtjevima između stranica, bez obzira na njihovo podrijetlo. Međutim, kako bi se osigurala sigurnost korištenja "Nijedan", kolačić također mora biti označen kao "Siguran", što znači da će biti poslan samo putem HTTPS veze. Ova kombinacija omogućuje web aplikacijama da podržavaju funkcionalnost između web-mjesta, a istovremeno štite od CSRF napada. Treba imati na umu da vrijednost "None" treba koristiti samo kada je to neophodno, jer povećava površinu napada i potencijal za CSRF ranjivosti.
Za ilustraciju upotrebe kolačića na istom mjestu za ublažavanje CSRF napada, razmotrite sljedeći scenarij: bankovno web mjesto koje korisnicima omogućuje prijenos sredstava. Bez kolačića istog mjesta, napadač bi mogao stvoriti zlonamjerno web mjesto koje uključuje skriveni obrazac koji automatski šalje zahtjev za prijenos sredstava na bankovno web mjesto kada ga posjeti autentificirani korisnik. Ako korisnikov preglednik uključi sesijski kolačić u zahtjev, prijenos će se izvršiti bez pristanka korisnika. Međutim, postavljanjem kolačića sesije kao kolačića iste web-lokacije s atributom "Strict", preglednik neće uključiti kolačić u zahtjev između web-mjesta, učinkovito sprječavajući CSRF napad.
Kolačići iste stranice vrijedan su sigurnosni mehanizam za ublažavanje CSRF napada u web aplikacijama. Ograničavanjem opsega kolačića na isto podrijetlo, ti kolačići sprječavaju napadače da iskoriste sesiju korisnika za izvođenje neovlaštenih radnji. Vrijednost "Strict" osigurava da se kolačići šalju samo u zahtjevima koji potječu s iste web-lokacije, dok vrijednost "Lax" omogućuje slanje kolačića u sigurnim zahtjevima između stranica. Vrijednost "None", u kombinaciji s atributom "Secure", omogućuje funkcionalnost između web-mjesta dok još uvijek štiti od CSRF napada.
Ostala nedavna pitanja i odgovori u vezi Osnove sigurnosti EITC/IS/WASF web aplikacija:
- Štiti li implementacija Ne prati (DNT) u web preglednicima od otiska prsta?
- Pomaže li HTTP Strict Transport Security (HSTS) u zaštiti od napada na stariju verziju protokola?
- Kako funkcionira DNS rebinding napad?
- Događaju li se pohranjeni XSS napadi kada je zlonamjerna skripta uključena u zahtjev web aplikaciji i zatim poslana natrag korisniku?
- Koristi li se SSL/TLS protokol za uspostavljanje šifrirane veze u HTTPS-u?
- Što su zaglavlja zahtjeva za dohvaćanje metapodataka i kako se mogu koristiti za razlikovanje zahtjeva istog podrijetla i zahtjeva s više stranica?
- Kako pouzdani tipovi smanjuju površinu napada web aplikacija i pojednostavljuju sigurnosne preglede?
- Koja je svrha zadane politike u pouzdanim tipovima i kako se ona može koristiti za prepoznavanje nesigurnih dodjela nizova?
- Kakav je postupak za stvaranje objekta pouzdanih tipova pomoću API-ja pouzdanih tipova?
- Kako direktiva pouzdanih tipova u politici sigurnosti sadržaja pomaže ublažiti ranjivosti cross-site scripting (XSS) temeljene na DOM-u?
Više pitanja i odgovora pogledajte u Osnovama sigurnosti web aplikacija EITC/IS/WASF