Jesu li kolačići SameSite ubili CSRF?

Znatno ga je smanjio, ali ne i eliminirao. SameSite=Lax (moderna zadana) dopušta kolačiće s više stranica na navigaciji najviše razine. SameSite=Strict sprječava i to, ali prekida legitimne tokove. CSRF tokeni i dalje su preporučena obrana; SameSite je komplementarni sloj.

Kako se CSRF razlikuje od XSS-a?

XSS ubacuje zlonamjerni kod u pouzdanu stranicu, izvršavajući se sa svojim privilegijama. CSRF prevari preglednik da pošalje zahtjev pouzdanoj stranici bez ubacivanja bilo čega. XSS može učiniti sve što može CSRF, i više. To su različiti mehanizmi napada.

Mogu li testirati CSRF u vlastitoj aplikaciji?

Da. Pokušajte poslati obrasce s uklonjenim ili promijenjenim tokenom; ako akcija prođe, imate CSRF. Testirajte u Chromeu s provođenjem SameSite; neki naslijeđeni okviri imaju CSRF tokene koji zapravo nisu provjereni. Ručni pregled je jednostavan.

Trebaju li aplikacije s jednom stranicom CSRF zaštitu?

Ako se autentificiraju putem kolačića, da. Ako se autentificiraju putem Bearer tokena pohranjenih na strani klijenta (localStorage), manje su ranjivi na CSRF, ali više izloženi XSS-u. Obje napadne površine su važne; odaberite svoj mehanizam provjere autentičnosti imajući oboje na umu.

Je li CSRF još uvijek u OWASP Top 10?

Ispao je iz Top 10 2021. zbog raširenog ublažavanja na razini okvira i zadanih postavki kolačića SameSite. Još uvijek je na OWASP listi značajnih ranjivosti; prevalencija je pala, a ne temeljni mehanizam.

Objašnjenje CSRF-a: kada web stranica prevari vaš preglednik da djeluje u vaše ime

Cross-Site Request Forgery je ranjivost gdje zlonamjerna stranica tjera vaš preglednik da pošalje zahtjev web-mjestu na kojem ste prijavljeni — koristeći svoje vjerodajnice, poduzimajući radnje koje niste odobrili. Kolačići SameSite zatvorili su većinu povijesne površine napada, ali osnovna je klasa i dalje važna gdje god kolačići autentificiraju operacije promjene stanja.

Cjeloviti članak nalazi se u nastavku na engleskom jeziku.

Cross-Site Request Forgery (CSRF, ponekad zvan XSRF ili "sea-surf") iskorištava povjerenje web stranice u preglednik korisnika. Napadač ne može vidjeti vaše kolačiće, ali ih preglednik automatski šalje sa svakim zahtjevom izvoru kojem pripadaju. Ako napadač može pokrenuti vaš preglednik da uputi zahtjev web-mjestu na kojem ste prijavljeni, to web-mjesto vidi autentificirani zahtjev — čak iako ga je napadač pokrenuo.

Klasični napad

IZamislite banku koja obrađuje transfere putem jednostavnog GET zahtjeva: https://bank.example/transfer?to=Bob&amount=1000. Prijavljeni ste u banku. Napadač vam e-poštom šalje vezu ili hostira stranicu sa slikovnom oznakom koja upućuje na https://bank.example/transfer?to=Attacker&amount=10000. Vaš preglednik učitava sliku; banka vidi autentificirani zahtjev iz vaše sesije; prijenos prolazi.

Taj konkretan primjer uglavnom je povijesni — banke više ne obrađuju prijenose putem GET-a — ali obrazac je općenit. Svaki zahtjev za promjenom stanja koji autentifikuje isključivo putem kolačića sesije potencijalno je ranjiv na CSRF.

Što CSRF čini mogućim

Tri temelja:

Kolačići se šalju automatski. Preglednik ne traži dopuštenje; kolačići pripadaju izvoru i putuju sa svakim zahtjevom do tog izvora, bez obzira na to gdje je zahtjev pokrenut.
HTML može pokrenuti zahtjeve s različitim izvorima. Oznake slika, podnošenje obrazaca, oznake skripte i razni drugi elementi mogu biti usmjereni na bilo koji URL.
Poslužitelji djeluju na zahtjeve bez provjere intent. Poslužitelj vidi autentificirani zahtjev; bez eksplicitne CSRF zaštite, obrađuje radnju.

Standardne obrane

CSRF tokeni (sinkronizacijski tokeni). Poslužitelj uključuje nasumični token u svakom obliku. Podnesci moraju sadržavati token. Zlonamjerna stranica napadača ne može pročitati token (pravilo istog porijekla), pa krivotvoreni zahtjevi ne uspijevaju. Moderni web okviri automatski generiraju i provjeravaju tokene.
Kolačići SameSite. Kolačići označeni SameSite=Lax (zadano u modernim preglednicima od 2020.) ne šalju se na zahtjeve između web-mjesta osim navigacije najviše razine. SameSite=Strogo je još strože. Ovo je najveća pojedinačna promjena koja je smanjila CSRF rizik u proteklih pet godina.
Provjera zaglavlja Origin i Referer. Poslužitelji mogu provjeriti odgovara li zaglavlje Origin očekivanom izvoru. Zahtjevi između stranica imaju različito podrijetlo, što dopušta odbijanje.
Kolačić dvostrukog slanja. Poslužitelj postavlja vrijednost iu kolačiću iu zasebnom parametru zahtjeva; verifikator provjerava da li odgovaraju. Radi bez stanja sesije na strani poslužitelja.
Ponovna provjera autentičnosti za osjetljive radnje. Potvrda lozinke, MFA izazov ili pojačana provjera autentičnosti na operacijama visoke vrijednosti. Pobjeđuje CSRF i nekoliko drugih klasa napada istovremeno.

Revolucija kolačića SameSite

Prije 2020. svaki zahtjev između web-mjesta nosio je kolačiće odredišne web-lokacije — uključujući zahtjeve zlonamjernih stranica za promjenu stanja. SameSite=Lax je kolačiće između stranica učinio iznimkom, a ne pravilom. Glavni preglednici zadano su postavili Lax u razdoblju 2020.-2021., a učinak je bio dramatičan: većina povremenih CSRF ranjivosti preko noći je postala neiskoristiva.

Kvaka: SameSite=Lax još uvijek dopušta kolačiće na navigaciji najviše razine (preusmjeravanja cijele stranice). Operacije promjene stanja pokrenute klikom na vezu i dalje mogu sadržavati kolačiće. Obrana je dobra, ali nije potpuna.

SameSite=Strict to u potpunosti sprječava. Kompromis: prekida tijekove prijave koji ovise o navigaciji između web-mjesta (jednostruka prijava, preusmjeravanja nakon OAuth-a). Većina velikih web-mjesta koristi Lax kao zadani i Strict samo za najosjetljivije kolačiće.

CSRF i API-ji

Moderni API-ji često provjeravaju autentičnost putem zaglavlja za autorizaciju (tokena nositelja) umjesto kolačića. CSRF se ne primjenjuje jer preglednik ne uključuje automatski proizvoljna zaglavlja na zahtjeve drugog porijekla. Problem CSRF-a uglavnom pripada sustavima s autentifikacijom kolačića.

Međutim, API-ji koji miješaju kolačiće za neke tokove i tokene za druge mogu imati suptilne CSRF površine. Koristite jedno ili drugo dosljedno.

CSRF i CORS

CORS (Cross-Origin Resource Sharing) definira kada će preglednik dopustiti JavaScriptu čitanje zahtjeva s različitim izvorima. CSRF je o tome je li zahtjev uopće sent, s kolačićima. Povezani su, ali različiti:

CSRF sprječava zlonamjernu stranicu da izazove zahtjev
CORS sprječava zlonamjernu stranicu da pročita odgovor

A CSRF napad ne treba čitati odgovor — samo mu je potreban poslužitelj da izvrši radnju. Preglednik poslušno pokreće zahtjev i dobiva odgovor; zlonamjerna stranica to možda neće vidjeti, ali šteta je učinjena. CORS ne popravlja CSRF.

Poznati CSRF incidenti

Netflix manipulacija redom čekanja (2006.). Istraživači su otkrili da izrađene IMG oznake mogu dodati filmove u vaš Netflix red čekanja bez vašeg angažmana. Popravak su bili prvi CSRF tokeni u širokoj upotrebi.
Vanzite preuzimanja YouTube računa u kasnim 2000-ima.
Brisanja GitHub repozitorija putem CSRF-a 2012. (popravljeno) brzo).
Brojne CSRF ranjivosti dodataka za WordPress prijavljuju se svake godine; ekosustav dodataka i dalje ih proizvodi u velikom obimu.

Za programere u 2026.

Koristite okvir s ugrađenom CSRF zaštitom (svi to imaju Django, Rails, Spring, Laravel)
Provjerite CSRF tokene pri svakoj promjeni stanja request
Postavi SameSite=Lako (ili Strogo) na kolačiće sesije
Za API-je, koristite tokene nositelja radije nego kolačiće kada je to moguće
Zahtijevajte ponovnu provjeru autentičnosti za operacije s visokim ulozima
Ne oslanjajte se samo na izvor/preporuku — neki klijenti izostavite ova zaglavlja

Za korisnike

Ne možete se izravno obraniti od CSRF-a — to je greška na strani poslužitelja. Zadane postavke modernog preglednika (SameSite=Lax) značajno pomažu, ali ovisite o tome da svaka stranica na koju se prijavite ima implementiranu zaštitu. Ostanite prijavljeni samo onoliko koliko vam je potrebno; odjavite se s osjetljivih računa kada se ne koriste; i vjerujte modernim glavnim stranicama — sve su se bavile CSRF-om u svojim modelima prijetnji.

Često postavljana pitanja

Jesu li kolačići SameSite ubili CSRF?: Znatno ga je smanjio, ali ne i eliminirao. SameSite=Lax (moderna zadana) dopušta kolačiće s više stranica na navigaciji najviše razine. SameSite=Strict sprječava i to, ali prekida legitimne tokove. CSRF tokeni i dalje su preporučena obrana; SameSite je komplementarni sloj.
Kako se CSRF razlikuje od XSS-a?: XSS ubacuje zlonamjerni kod u pouzdanu stranicu, izvršavajući se sa svojim privilegijama. CSRF prevari preglednik da pošalje zahtjev pouzdanoj stranici bez ubacivanja bilo čega. XSS može učiniti sve što može CSRF, i više. To su različiti mehanizmi napada.
Mogu li testirati CSRF u vlastitoj aplikaciji?: Da. Pokušajte poslati obrasce s uklonjenim ili promijenjenim tokenom; ako akcija prođe, imate CSRF. Testirajte u Chromeu s provođenjem SameSite; neki naslijeđeni okviri imaju CSRF tokene koji zapravo nisu provjereni. Ručni pregled je jednostavan.
Trebaju li aplikacije s jednom stranicom CSRF zaštitu?: Ako se autentificiraju putem kolačića, da. Ako se autentificiraju putem Bearer tokena pohranjenih na strani klijenta (localStorage), manje su ranjivi na CSRF, ali više izloženi XSS-u. Obje napadne površine su važne; odaberite svoj mehanizam provjere autentičnosti imajući oboje na umu.
Je li CSRF još uvijek u OWASP Top 10?: Ispao je iz Top 10 2021. zbog raširenog ublažavanja na razini okvira i zadanih postavki kolačića SameSite. Još uvijek je na OWASP listi značajnih ranjivosti; prevalencija je pala, a ne temeljni mehanizam.