# CSRF (Cross Site Request Forgery)
{% hint style="success" %}
Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}
Join [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) 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**](https://discord.com/invite/N3FrSbmwdy) 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:
1. **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.
2. **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.
3. **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**](hacking-with-cookies/#samesite): Ova atribut sprečava pregledač 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 zaobilaženju](cors-bypass.md).
* **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:
1. **Authenticate** koristeći svoj nalog.
2. **Obtain a valid CSRF token** iz globalnog bazena.
3. **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:
```html
```
{% hint style="info" %}
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.
{% endhint %}
### Promena Content-Type
Prema [**ovome**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), 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](https://brycec.me/posts/corctf\_2021\_challenges)) slanja JSON podataka kao text/plain:
```html
```
### 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:
1. **Use Alternative Content Types**: 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. **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 prihvati `application/json`.
3. **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](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
### 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:
```xml
```
Ovo osigurava da 'Referer' zaglavlje bude izostavljeno, potencijalno zaobilazeći provere validacije u nekim aplikacijama.
**Regexp zaobilaženja**
{% 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 naziv domena servera u URL-u koji će Referrer poslati unutar parametara, možete uraditi:
```html
```
### **HEAD метод заобилажења**
Први део [**овог CTF извештаја**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) објашњава да је [Изворни код Ока](https://github.com/oakserver/oak/blob/main/router.ts#L281), рутер подешен да **обрађује HEAD захтеве као GET захтеве** без тела одговора - уобичајена заобилазница која није јединствена за Ок. Уместо специфичног обрађивача који се бави HEAD захтевима, они су једноставно **дати GET обрађивачу, али апликација само уклања тело одговора**.
Стога, ако је GET захтев ограничен, можете једноставно **послати HEAD захтев који ће бити обрађен као GET захтев**.
## **Примери експлоатације**
### **Екстракција CSRF токена**
Ако се **CSRF токен** користи као **одбрана**, можете покушати да **екстрахујете** злоупотребом [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) рањивости или [**Данглинг Маркуп**](dangling-markup-html-scriptless-injection/) рањивости.
### **GET користећи HTML тагове**
```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