CSRF (Cross Site Request Forgery)
Join HackenProof Discord server to communicate with experienced hackers and bug bounty hunters!
Hacking Insights Engage with content that delves into the thrill and challenges of hacking
Real-Time Hack News Keep up-to-date with fast-paced hacking world through real-time news and insights
Latest Announcements Stay informed with the newest bug bounties launching and crucial platform updates
Join us on Discord and start collaborating with top hackers today!
Cross-Site Request Forgery (CSRF) Explained
Cross-Site Request Forgery (CSRF) je vrsta sigurnosne ranjivosti koja se nalazi u web aplikacijama. Omogućava napadačima da izvrše radnje u ime nesvesnih korisnika iskorišćavajući njihove autentifikovane sesije. Napad se izvršava kada korisnik, koji je prijavljen na platformu žrtve, poseti zlonamernu stranicu. Ova stranica zatim pokreće zahteve na račun žrtve putem metoda kao što su izvršavanje JavaScript-a, slanje obrazaca ili preuzimanje slika.
Prerequisites for a CSRF Attack
Da bi se iskoristila CSRF ranjivost, nekoliko uslova mora biti ispunjeno:
Identify a Valuable Action: Napadač treba da pronađe radnju koja vredi iskorišćavanja, kao što je promena lozinke korisnika, email-a ili povećanje privilegija.
Session Management: Sesija korisnika treba da se upravlja isključivo putem kolačića ili HTTP Basic Authentication zaglavlja, jer se druga zaglavlja ne mogu manipulisati u tu svrhu.
Absence of Unpredictable Parameters: Zahtev ne bi trebao sadržati nepredvidive parametre, jer oni mogu sprečiti napad.
Quick Check
Možete uhvatiti zahtev u Burp-u i proveriti CSRF zaštite, a da biste testirali iz pregledača, možete kliknuti na Copy as fetch i proveriti zahtev:
Defending Against CSRF
Nekoliko mera zaštite može se implementirati kako bi se zaštitilo od CSRF napada:
SameSite cookies: Ova atribut sprečava pregledač da šalje kolačiće zajedno sa zahtevima sa drugih sajtova. Više o SameSite kolačićima.
Cross-origin resource sharing: CORS politika sajta žrtve može uticati na izvodljivost napada, posebno ako napad zahteva čitanje odgovora sa sajta žrtve. Saznajte više o CORS zaobilaženju.
User Verification: Traženje lozinke korisnika ili rešavanje captcha može potvrditi nameru korisnika.
Checking Referrer or Origin Headers: Validacija ovih zaglavlja može pomoći da se osigura da zahtevi dolaze iz pouzdanih izvora. Međutim, pažljivo kreiranje URL-ova može zaobići loše implementirane provere, kao što su:
Korišćenje
http://mal.net?orig=http://example.com
(URL se završava sa pouzdanim URL-om)Korišćenje
http://example.com.mal.net
(URL počinje sa pouzdanim URL-om)Modifying Parameter Names: Menjanje imena parametara u POST ili GET zahtevima može pomoći u sprečavanju automatizovanih napada.
CSRF Tokens: Uključivanje jedinstvenog CSRF tokena u svaku sesiju i zahtev za ovim tokenom u narednim zahtevima može značajno smanjiti rizik od CSRF. Efikasnost tokena može se poboljšati primenom CORS-a.
Razumevanje i implementacija ovih odbrana je ključno za održavanje sigurnosti i integriteta web aplikacija.
Defences Bypass
From POST to GET
Možda je obrazac koji želite da zloupotrebite pripremljen da pošalje POST zahtev sa CSRF tokenom, ali trebate proveriti da li je GET takođe validan i da li kada pošaljete GET zahtev CSRF token još uvek se validira.
Lack of token
Aplikacije mogu implementirati mehanizam za validaciju tokena kada su prisutni. Međutim, ranjivost nastaje ako se validacija potpuno preskoči kada token nije prisutan. Napadači mogu iskoristiti ovo tako što će ukloniti parametar koji nosi token, ne samo njegovu vrednost. Ovo im omogućava da zaobiđu proces validacije i efikasno izvrše Cross-Site Request Forgery (CSRF) napad.
CSRF token is not tied to the user session
Aplikacije koje ne vezuju CSRF tokene za korisničke sesije predstavljaju značajan sigurnosni rizik. Ovi sistemi verifikuju tokene protiv globalnog bazena umesto da osiguraju da je svaki token vezan za inicijalnu sesiju.
Evo kako napadači iskorišćavaju ovo:
Authenticate koristeći svoj nalog.
Obtain a valid CSRF token iz globalnog bazena.
Use this token u CSRF napadu protiv žrtve.
Ova ranjivost omogućava napadačima da šalju neovlašćene zahteve u ime žrtve, iskorišćavajući neadekvatan mehanizam validacije tokena aplikacije.
Method bypass
Ako zahtev koristi "čudan" metod, proverite da li funkcionalnost override metoda radi. Na primer, ako koristi PUT metod, možete pokušati da koristite POST metod i pošaljete: https://example.com/my/dear/api/val/num?_method=PUT
Ovo takođe može raditi slanjem _method parametra unutar POST zahteva ili korišćenjem zaglavlja:
X-HTTP-Method
X-HTTP-Method-Override
X-Method-Override
Custom header token bypass
Ako zahtev dodaje prilagođeno zaglavlje sa tokenom kao metod zaštite od CSRF, onda:
Testirajte zahtev bez prilagođenog tokena i takođe zaglavlja.
Testirajte zahtev sa tačno istom dužinom, ali različitim tokenom.
CSRF token is verified by a cookie
Aplikacije mogu implementirati zaštitu od CSRF tako što će duplirati token u kolačiću i parametru zahteva ili postavljanjem CSRF kolačića i verifikovanjem da li token poslat u pozadini odgovara kolačiću. Aplikacija validira zahteve proverom da li se token u parametru zahteva poklapa sa vrednošću u kolačiću.
Međutim, ova metoda je ranjiva na CSRF napade ako sajt ima greške koje omogućavaju napadaču da postavi CSRF kolačić u pregledaču žrtve, kao što je CRLF ranjivost. Napadač može iskoristiti ovo tako što će učitati obmanjujuću sliku koja postavlja kolačić, nakon čega pokreće CSRF napad.
Ispod je primer kako bi napad mogao biti strukturiran:
Imajte na umu da ako je csrf token povezan sa sesijskim kolačićem, ovaj napad neće uspeti jer ćete morati da postavite žrtvi vašu sesiju, a samim tim ćete napadati sebe.
Promena Content-Type
Prema ovome, kako bi se izbegli preflight zahtevi korišćenjem POST metode, ovo su dozvoljene vrednosti Content-Type:
application/x-www-form-urlencoded
multipart/form-data
text/plain
Međutim, imajte na umu da logika servera može varirati u zavisnosti od korišćenog Content-Type, tako da biste trebali isprobati pomenute vrednosti i druge poput application/json
,text/xml
, application/xml
.
Primer (iz ovde) slanja JSON podataka kao text/plain:
Bypassing Preflight Requests for JSON Data
Kada pokušavate da pošaljete JSON podatke putem POST zahteva, korišćenje Content-Type: application/json
u HTML formi nije direktno moguće. Slično tome, korišćenje XMLHttpRequest
za slanje ovog tipa sadržaja pokreće preflight zahtev. Ipak, postoje strategije za potencijalno zaobilaženje ove ograničenja i proveru da li server obrađuje JSON podatke bez obzira na Content-Type:
Use Alternative Content Types: Koristite
Content-Type: text/plain
iliContent-Type: application/x-www-form-urlencoded
postavljanjemenctype="text/plain"
u formi. Ovaj pristup testira da li backend koristi podatke bez obzira na Content-Type.Modify Content Type: Da biste izbegli preflight zahtev dok osiguravate da server prepoznaje sadržaj kao JSON, možete poslati podatke sa
Content-Type: text/plain; application/json
. Ovo ne pokreće preflight zahtev, ali bi moglo biti ispravno obrađeno od strane servera ako je konfigurisan da prihvatiapplication/json
.SWF Flash File Utilization: Manje uobičajena, ali izvodljiva metoda uključuje korišćenje SWF flash datoteke za zaobilaženje takvih ograničenja. Za detaljno razumevanje ove tehnike, pogledajte ovaj post.
Referrer / Origin check bypass
Avoid Referrer header
Aplikacije mogu validirati 'Referer' header samo kada je prisutan. Da biste sprečili pretraživač da pošalje ovaj header, može se koristiti sledeći HTML meta tag:
Ovo osigurava da 'Referer' zaglavlje bude izostavljeno, potencijalno zaobilazeći provere validacije u nekim aplikacijama.
Regexp zaobilaženja
URL Format BypassDa biste postavili naziv domena servera u URL-u koji će Referrer poslati unutar parametara, možete uraditi:
HEAD метод заобилажења
Први део овог CTF извештаја објашњава да је Изворни код Ока, рутер подешен да обрађује HEAD захтеве као GET захтеве без тела одговора - уобичајена заобилазница која није јединствена за Ок. Уместо специфичног обрађивача који се бави HEAD захтевима, они су једноставно дати GET обрађивачу, али апликација само уклања тело одговора.
Стога, ако је GET захтев ограничен, можете једноставно послати HEAD захтев који ће бити обрађен као GET захтев.
Примери експлоатације
Екстракција CSRF токена
Ако се CSRF токен користи као одбрана, можете покушати да екстрахујете злоупотребом XSS рањивости или Данглинг Маркуп рањивости.
GET користећи HTML тагове
Drugi HTML5 tagovi koji se mogu koristiti za automatsko slanje GET zahteva su:
Form GET zahtev
Form POST zahtev
Form POST zahtev kroz iframe
Ajax POST zahtev
multipart/form-data POST zahtev
multipart/form-data POST zahtev v2
Form POST zahtev iz iframe-a
Ukrao CSRF token i poslao POST zahtev
Ukrao CSRF token i poslao Post zahtev koristeći iframe, formu i Ajax
Ukrao CSRF token i poslao POST zahtev koristeći iframe i formu
Ukrao token i poslao ga koristeći 2 iframes
POSTUkrao CSRF token pomoću Ajax-a i poslao post sa formom
CSRF са Socket.IO
CSRF Login Brute Force
Kod se može koristiti za Brut Force forme za prijavu koristeći CSRF token (takođe koristi header X-Forwarded-For da pokuša da zaobiđe moguće IP crne liste):
Alati
Reference
Pridružite se HackenProof Discord serveru da komunicirate sa iskusnim hakerima i lovcima na greške!
Uvidi u Hacking Uključite se u sadržaj koji istražuje uzbuđenje i izazove hakovanja
Vesti o Hacking-u u Realnom Vremenu Budite u toku sa brzim svetom hakovanja kroz vesti i uvide u realnom vremenu
Najnovija Obaveštenja Budite informisani o najnovijim nagradama za greške i važnim ažuriranjima platformi
Pridružite nam se na Discord i počnite da sarađujete sa vrhunskim hakerima danas!
Last updated