# 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 svoju **kompaniju reklamiranu na HackTricks-u** ili **preuzmete HackTricks u PDF formatu** proverite [**PLANOVE ZA PRIJAVU**](https://github.com/sponsors/carlospolop)! * Nabavite [**zvanični PEASS & HackTricks swag**](https://peass.creator-spring.com) * Otkrijte [**The PEASS Family**](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 nas **pratite** na **Twitteru** 🐦 [**@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! ## Cross-Site Request Forgery (CSRF) Objasnjenje **Cross-Site Request Forgery (CSRF)** je vrsta sigurnosne ranjivosti koja se nalazi u veb aplikacijama. Omogućava napadačima da vrše radnje 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 se iskoristila CSRF ranjivost, potrebno je ispuniti nekoliko uslova: 1. **Identifikacija Vredne Radnje**: Napadač mora pronaći radnju 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 pretraživača 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: * [**SameSite kolačići**](hacking-with-cookies/#samesite): Ova osobina sprečava pretraživač da šalje kolačiće zajedno sa zahtevima sa drugih sajtova. [Više o SameSite kolačićima](hacking-with-cookies/#samesite). * [**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 CORS obilasku](cors-bypass.md). * **Provera Korisnika**: Traženje korisničke lozinke ili rešavanje captcha testa može potvrditi nameru korisnika. * **Provera Referrer 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 obrazac koji želite zloupotrebiti pripremljen za slanje **POST zahteva 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 inicirajućom 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** metod, možete pokušati da koristite **POST** metod 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 Tokena u Zaglavlju 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 pretraživač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 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 samim tim ćete napadati 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 se **logika servera može razlikovati** 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
``` ### Zaobilazak zahteva za pretpostavljeni zahtev za JSON podacima Prilikom pokušaja slanja JSON podataka 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 zahtev za pretpostavljeni 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 tipove sadržaja**: 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 tip sadržaja**: Da biste izbegli zahtev za pretpostavljeni zahtev dok se osiguravate da server prepoznaje sadržaj kao JSON, možete poslati podatke sa `Content-Type: text/plain; application/json`. Ovo ne pokreće zahtev za pretpostavljeni zahtev, ali ih server može pravilno obraditi ako je konfigurisan da prihvati `application/json`. 3. **Korišćenje SWF Flash fajla**: Manje uobičajen, ali izvodljiv metod uključuje korišćenje SWF flash fajla za zaobilaženje takvih ograničenja. Za dublje razumevanje ove tehnike, pogledajte [ovaj post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937). ### Zaobilazak provere Referrer / Origin **Izbegavanje zaglavlja Referrer** Aplikacije mogu validirati zaglavlje 'Referer' 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. **Bypass-ovi regularnih izraza** {% 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: ```html
``` ### **Bypass metoda HEAD** Prvi deo [**ovog CTF writeupa**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) objašnjava da je [Oak-ov izvorni kod](https://github.com/oakserver/oak/blob/main/router.ts#L281), postavljen tako 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