# CSRF (Cross Site Request Forgery)
Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)! Drugi načini podrške HackTricks-u: * Ako želite da vidite **vašu kompaniju reklamiranu na HackTricks-u** ili **preuzmete HackTricks u PDF formatu** Proverite [**PLANOVE ZA PRIJATELJSTVO**](https://github.com/sponsors/carlospolop)! * Nabavite [**zvanični PEASS & HackTricks swag**](https://peass.creator-spring.com) * Otkrijte [**Porodiču PEASS**](https://opensea.io/collection/the-peass-family), našu kolekciju ekskluzivnih [**NFT-ova**](https://opensea.io/collection/the-peass-family) * **Pridružite se** 💬 [**Discord grupi**](https://discord.gg/hRep4RUj7f) ili [**telegram grupi**](https://t.me/peass) ili **pratite** nas na **Twitter-u** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Podelite svoje hakovanje trikove slanjem PR-ova na** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repozitorijume.
Pridružite se [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) serveru kako biste komunicirali sa iskusnim hakerima i lovcima na bagove! **Hakerski uvidi**\ Uključite se u sadržaj koji istražuje uzbuđenje i izazove hakovanja **Vesti o hakovanju u realnom vremenu**\ Budite u toku sa brzim svetom hakovanja kroz vesti i uvide u realnom vremenu **Najnovije najave**\ Budite informisani o najnovijim nagradama za pronalaženje bagova i važnim ažuriranjima platformi **Pridružite nam se na** [**Discord-u**](https://discord.com/invite/N3FrSbmwdy) i počnite da sarađujete sa vrhunskim hakerima danas! ## Objasnjenje Cross-Site Request Forgery (CSRF) **Cross-Site Request Forgery (CSRF)** je vrsta sigurnosne ranjivosti koja se nalazi u veb aplikacijama. Omogućava napadačima da izvrše akcije u ime nesumnjivih korisnika iskorišćavanjem njihovih autentifikovanih sesija. Napad se izvršava kada korisnik, koji je prijavljen na platformu žrtve, poseti zlonamerni sajt. Taj sajt zatim pokreće zahteve ka nalogu žrtve putem metoda poput izvršavanja JavaScript-a, slanja formi ili dohvatanja slika. ### Preduslovi za CSRF Napad Da bi iskoristio CSRF ranjivost, potrebno je ispuniti nekoliko uslova: 1. **Identifikacija Vredne Akcije**: Napadač mora pronaći akciju vrednu iskorišćavanja, poput promene korisničke lozinke, e-pošte ili povećanja privilegija. 2. **Upravljanje Sesijom**: Korisnička sesija treba da se upravlja isključivo putem kolačića ili zaglavlja HTTP Basic Authentication, jer se ostala zaglavlja ne mogu manipulisati u tu svrhu. 3. **Odsustvo Nepredvidivih Parametara**: Zahtev ne sme sadržati nepredvidive parametre, jer oni mogu sprečiti napad. ### Brza Provera Možete **uhvatiti zahtev u Burp-u** i proveriti CSRF zaštitu i testirati iz brauzera možete kliknuti na **Kopiraj kao fetch** i proveriti zahtev:
### Odbrana Od CSRF-a Mogu se primeniti različite mere zaštite od CSRF napada: * [**Kolačići sa istim sajtom (SameSite cookies)**](hacking-with-cookies/#samesite): Ova osobina sprečava pregledač da šalje kolačiće zajedno sa zahtevima sa drugih sajtova. [Više o kolačićima sa istim sajtom](hacking-with-cookies/#samesite). * [**Deljenje resursa preko različitih sajtova (Cross-origin resource sharing)**](cors-bypass.md): CORS politika sajta žrtve može uticati na izvodljivost napada, posebno ako napad zahteva čitanje odgovora sa sajta žrtve. [Saznajte više o zaobilaženju CORS-a](cors-bypass.md). * **Provera Korisnika**: Traženje korisničke lozinke ili rešavanje captcha-e može potvrditi nameru korisnika. * **Provera Referrera ili Origin Zaglavlja**: Validacija ovih zaglavlja može pomoći u osiguravanju da zahtevi dolaze od pouzdanih izvora. Međutim, pažljivo oblikovanje 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) * **Menjanje Imena Parametara**: Menjanje imena parametara u POST ili GET zahtevima može pomoći u sprečavanju automatizovanih napada. * **CSRF Tokeni**: Uključivanje jedinstvenog CSRF tokena u svaku sesiju i zahtevanje ovog tokena u narednim zahtevima može značajno smanjiti rizik od CSRF-a. Efikasnost tokena može se poboljšati primenom CORS-a. Razumevanje i primena ovih odbrana su ključni za održavanje sigurnosti i integriteta veb aplikacija. ## Bypass Odbrana ### Od POST-a do GET-a Možda je forma koju želite zloupotrebiti pripremljena da pošalje **POST zahtev sa CSRF tokenom**, međutim, treba **proveriti** da li je **GET** takođe **validan** i da li se **CSRF token i dalje validira** kada pošaljete GET zahtev. ### Nedostatak tokena Aplikacije mogu implementirati mehanizam za **validaciju tokena** kada su prisutni. Međutim, ranjivost se javlja ako se validacija potpuno preskoči kada token nije prisutan. Napadači mogu iskoristiti ovo tako što će **ukloniti parametar** koji nosi token, a ne samo njegovu vrednost. To im omogućava da zaobiđu proces validacije i efikasno izvrše napad Cross-Site Request Forgery (CSRF). ### CSRF token nije vezan za korisničku sesiju Aplikacije koje **ne vezuju CSRF tokene za korisničke sesije** predstavljaju značajan **sigurnosni rizik**. Ovi sistemi proveravaju tokene protiv **globalnog fonda** umesto da osiguraju da je svaki token povezan sa inicijalnom sesijom. Evo kako napadači iskorišćavaju ovo: 1. **Autentifikacija** korišćenjem sopstvenog naloga. 2. **Dobijanje validnog CSRF tokena** iz globalnog fonda. 3. **Korišćenje ovog tokena** u CSRF napadu protiv žrtve. Ova ranjivost omogućava napadačima da izvrše neovlaštene zahteve u ime žrtve, iskorišćavajući nedovoljno efikasan mehanizam validacije tokena aplikacije. ### Bypass Metoda Ako zahtev koristi "**čudnu**" **metodu**, proverite da li funkcionalnost **zamene metoda** radi. Na primer, ako se koristi PUT metoda, možete pokušati da koristite POST metodu i poslati: _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_ ### Bypass Prilagođenog Zaglavlja Tokena Ako zahtev dodaje **prilagođeno zaglavlje** sa **tokenom** u zahtev kao **metodu zaštite od CSRF-a**, onda: * Testirajte zahtev bez **Prilagođenog Tokena i takođe zaglavlja.** * Testirajte zahtev sa tačno **istom dužinom ali drugačijim tokenom**. ### CSRF token se proverava putem kolačića Aplikacije mogu implementirati zaštitu od CSRF-a dupliranjem tokena i u kolačiću i u parametru zahteva ili postavljanjem CSRF kolačića i proverom da li token poslat na backend odgovara kolačiću. Aplikacija validira zahteve proverom da li token u parametru zahteva odgovara vrednosti u kolačiću. Međutim, ovaj metod je ranjiv na CSRF napade ako veb sajt ima propuste koji omogućavaju napadaču da postavi CSRF kolačić u pregledaču žrtve, kao što je CRLF ranjivost. Napadač može iskoristiti ovo učitavanjem obmanjujuće slike koja postavlja kolačić, a zatim pokretanjem CSRF napada. U nastavku je prikazan primer kako bi napad mogao biti struktuiran: ```html
``` {% hint style="info" %} Imajte na umu da ako je **CSRF token povezan sa sesijskim kolačićem, ovaj napad neće uspeti** jer će vam biti potrebno da postavite žrtvi svoju sesiju, i time ćete napadati sami sebe. {% endhint %} ### Promena Content-Type Prema [**ovome**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), kako bi se **izbegli preflight** zahtevi koristeći **POST** metod, dozvoljene vrednosti Content-Type su: * **`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, pa biste trebali isprobati navedene vrednosti i druge poput **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ Primer (sa [ovde](https://brycec.me/posts/corctf\_2021\_challenges)) slanja JSON podataka kao text/plain: ```html
``` ### Bypassing Preflight Requests for JSON Data Kada pokušavate poslati JSON podatke putem POST zahteva, korišćenje `Content-Type: application/json` u HTML formi nije direktno moguće. Slično, korišćenje `XMLHttpRequest` za slanje ovog tipa sadržaja pokreće preflight zahtev. Ipak, postoje strategije za potencijalno zaobilaženje ove ograničenosti i proveru da li server obrađuje JSON podatke bez obzira na Content-Type: 1. **Koristite Alternativne Content Type-ove**: Koristite `Content-Type: text/plain` ili `Content-Type: application/x-www-form-urlencoded` postavljanjem `enctype="text/plain"` u formi. Ovaj pristup testira da li backend koristi podatke bez obzira na Content-Type. 2. **Izmenite Content Type**: Da biste izbegli preflight zahtev, a istovremeno osigurali 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 ih server može pravilno obraditi ako je konfigurisan da prihvata `application/json`. 3. **Korišćenje SWF Flash Fajla**: Manje uobičajen, ali izvodljiv metod uključuje korišćenje SWF flash fajla za zaobilaženje ovakvih ograničenja. Za dublje razumevanje ove tehnike, pogledajte [ovaj post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937). ### Zaobilaženje Provere Referrera / Origin-a **Izbegavanje Referrer zaglavlja** Aplikacije mogu validirati 'Referer' zaglavlje samo kada je prisutno. Da bi se sprečilo slanje ovog zaglavlja od strane pregledača, može se koristiti sledeća HTML meta oznaka: ```xml ``` Ovo osigurava da se zaglavlje 'Referer' izostavi, potencijalno zaobilazeći provere validacije u nekim aplikacijama. **Bajpasiranje Regexp-a** {% content-ref url="ssrf-server-side-request-forgery/url-format-bypass.md" %} [url-format-bypass.md](ssrf-server-side-request-forgery/url-format-bypass.md) {% endcontent-ref %} Da biste postavili ime domena servera u URL koji će Referrer poslati unutar parametara, možete uraditi sledeće: ```html
``` ### **Bypassovanje metode HEAD** Prvi deo [**ovog CTF rešenja**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) objašnjava da [Oak-ov izvorni kod](https://github.com/oakserver/oak/blob/main/router.ts#L281), gde je ruter podešen da **obradi HEAD zahteve kao GET zahteve** bez tela odgovora - uobičajeni trik koji nije jedinstven za Oak. Umesto specifičnog rukovaoca koji se bavi HEAD zahtevima, oni se jednostavno **prosleđuju GET rukovaocu, ali aplikacija jednostavno uklanja telo odgovora**. Dakle, ako je GET zahtev ograničen, možete jednostavno **poslati HEAD zahtev koji će biti obrađen kao GET zahtev**. ## **Primeri eksploatacije** ### **Izvlačenje CSRF tokena** Ako se **CSRF token** koristi kao **odbrana**, možete pokušati da ga **izvučete** zloupotrebom [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) ranjivosti ili [**Dangling Markup**](dangling-markup-html-scriptless-injection/) ranjivosti. ### **GET korišćenjem HTML tagova** ```xml

404 - Page not found

The URL you are requesting is no longer available ``` Drugi HTML5 tagovi koji se mogu koristiti za automatsko slanje GET zahteva su: ```html