<summary><strong>Leer AWS-hacking vanaf nul tot held met</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* As jy jou **maatskappy geadverteer wil sien in HackTricks** of **HackTricks in PDF wil aflaai** Kyk na die [**INSKRYWINGSPLANNE**](https://github.com/sponsors/carlospolop)!
* Ontdek [**Die PEASS Familie**](https://opensea.io/collection/the-peass-family), ons versameling eksklusiewe [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Deel jou haktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-opslag.
**Kruiswebversoekvergiffenis (CSRF)** is 'n tipe sekuriteitskwesbaarheid wat in webtoepassings gevind word. Dit stel aanvallers in staat om aksies namens onvermoedende gebruikers uit te voer deur hul geagiteerde sessies te benut. Die aanval word uitgevoer wanneer 'n gebruiker, wat by 'n slagoffer se platform aangemeld is, 'n skadelike webwerf besoek. Hierdie webwerf aktiveer dan versoek aan die slagoffer se rekening deur metodes soos die uitvoer van JavaScript, die indien van vorms, of die ophaling van beelde.
Om 'n CSRF-kwesbaarheid te benut, moet verskeie toestande voldoen word:
1.**Identifiseer 'n Waardevolle Aksie**: Die aanvaller moet 'n aksie vind wat die moeite werd is om te benut, soos die verandering van die gebruiker se wagwoord, e-pos, of die verhoging van voorregte.
2.**Sessiebestuur**: Die gebruiker se sessie moet slegs deur koekies of die HTTP Basiese Verifikasiekop beheer word, aangesien ander koppe nie vir hierdie doel gemanipluleer kan word nie.
3.**Afwees van Onvoorspelbare Parameters**: Die versoek moet nie onvoorspelbare parameters bevat nie, aangesien dit die aanval kan voorkom.
Jy kan die versoek in Burp **vasvang** en CSRF-beskerming toets en om vanaf die blaaier te toets, kan jy op **Kopieer as ophaal** klik en die versoek toets:
* [**SelfdeSite-koekies**](hacking-with-cookies/#samesite): Hierdie eienskap voorkom dat die blaaier koekies saam met kruiswebversoeke stuur. [Meer oor SelfdeSite-koekies](hacking-with-cookies/#samesite).
* [**Kruis-oorsprong hulpbrondeling**](cors-bypass.md): Die CORS-beleid van die slagoffersite kan die uitvoerbaarheid van die aanval beïnvloed, veral as die aanval vereis dat die respons van die slagoffersite gelees word. [Leer oor CORS-omleiding](cors-bypass.md).
* **Gebruikerverifikasie**: Die versoek vir die gebruiker se wagwoord of die oplos van 'n captcha kan die gebruiker se bedoeling bevestig.
* **Kontroleer Verwysers of Oorsprongkoppe**: Die validering van hierdie koppe kan help om te verseker dat versoek van betroubare bronne afkomstig is. Tog kan sorgvuldige samestelling van URL's swak geïmplementeerde kontroles omseil, soos:
* **Wysiging van Parametername**: Die wysiging van die name van parameters in POST- of GET-versoeke kan help om outomatiese aanvalle te voorkom.
* **CSRF-tokens**: Die insluiting van 'n unieke CSRF-token in elke sessie en die vereiste van hierdie token in volgende versoek kan die risiko van CSRF aansienlik verminder. Die doeltreffendheid van die token kan versterk word deur CORS af te dwing.
Miskien is die vorm wat jy wil misbruik voorberei om 'n **POST-versoek met 'n CSRF-token te stuur maar**, jy moet **kontroleer** of 'n **GET** ook **geldig** is en of wanneer jy 'n GET-versoek stuur die **CSRF-token steeds gevalideer word**.
Toepassings kan 'n meganisme implementeer om **tokens te valideer** wanneer hulle teenwoordig is. 'n Kwesbaarheid ontstaan egter as die validasie heeltemal omseil word wanneer die token afwesig is. Aanvallers kan dit uitbuit deur die parameter wat die token dra, nie net sy waarde nie, te verwyder. Dit stel hulle in staat om die validasieproses te omseil en 'n Kruiswebversoekvergiffenis (CSRF) aanval doeltreffend uit te voer.
Toepassings wat nie CSRF-tokens aan gebruikersessies bind nie, bied 'n aansienlike **sekuriteitsrisiko**. Hierdie stelsels verifieer tokens teen 'n **globale poel** eerder as om te verseker dat elke token aan die inisieerdersessie gebind is.
Hierdie kwesbaarheid stel aanvallers in staat om ongemagtigde versoek op naam van die slagoffer te maak deur die toepassing se **onvoldoende tokenvalidasiemeganisme** uit te buit.
As die versoek 'n "**vreemde**" **metode** gebruik, kontroleer of die **metodeoorheersingsfunksionaliteit** werk. Byvoorbeeld, as dit 'n **PUT**-metode gebruik, kan jy probeer om 'n POST-metode te gebruik en **stuur**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
Toepassings kan CSRF-beskerming implementeer deur die token in beide 'n koekie en 'n versoekparameter te dupliseer of deur 'n CSRF-koekie in te stel en te verifieer of die token wat in die agtergrond gestuur word ooreenstem met die koekie. Die toepassing valideer versoek deur te kyk of die token in die versoekparameter ooreenstem met die waarde in die koekie.
Hierdie metode is egter vatbaar vir CSRF-aanvalle as die webwerf foute het wat 'n aanvaller toelaat om 'n CSRF-koekie in die slagoffer se blaaier te stel, soos 'n CRLF-kwesbaarheid. Die aanvaller kan dit uitbuit deur 'n misleidende beeld te laai wat die koekie stel, gevolg deur die inisieer van die CSRF-aanval.
Let wel dat as die **csrf-token verband hou met die sessie-cookie, sal hierdie aanval nie werk nie** omdat jy die slagoffer jou sessie moet instel, en dus sal jy jouself aanval.
Volgens [**hierdie**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), ten einde **preflight**-versoeke te **vermy** deur die **POST**-metode te gebruik, is hierdie die toegelate Inhouds-Tipe waardes:
Let egter daarop dat die **bedienerslogika mag verskil** afhangende van die gebruikte **Inhouds-Tipe**, dus moet jy die genoemde waardes probeer asook ander soos **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Wanneer daar gepoog word om JSON data via 'n POST versoek te stuur, is dit nie direk moontlik om die `Content-Type: application/json` in 'n HTML vorm te gebruik nie. Op soortgelyke wyse, die gebruik van `XMLHttpRequest` om hierdie inhoudstipe te stuur, inisieer 'n preflight versoek. Nietemin, daar is strategieë om moontlik hierdie beperking te omseil en te toets of die bediener die JSON data verwerk ongeag die Content-Type:
1.**Gebruik Alternatiewe Inhoudstipes**: Gebruik `Content-Type: text/plain` of `Content-Type: application/x-www-form-urlencoded` deur `enctype="text/plain"` in die vorm te stel. Hierdie benadering toets of die agterkant die data gebruik ongeag die Content-Type.
2.**Wysig Inhoudstipe**: Om 'n preflight versoek te vermy terwyl die bediener die inhoud as JSON herken, kan jy die data stuur met `Content-Type: text/plain; application/json`. Dit inisieer nie 'n preflight versoek nie, maar kan korrek deur die bediener verwerk word as dit ingestel is om `application/json` te aanvaar.
3.**SWF Flash-lêer Gebruik**: 'n Minder algemene maar uitvoerbare metode behels die gebruik van 'n SWF flash-lêer om sulke beperkings te omseil. Vir 'n dieper begrip van hierdie tegniek, verwys na [hierdie pos](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
Toepassings kan die 'Referer' kop net valideer as dit teenwoordig is. Om te voorkom dat 'n webblaaier hierdie kop stuur, kan die volgende HTML meta-etiket gebruik word:
Die eerste deel van [**hierdie CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) word verduidelik dat [Oak se bronkode](https://github.com/oakserver/oak/blob/main/router.ts#L281), 'n router is ingestel om **HEAD-versoeke as GET-versoeke te hanteer** sonder 'n responsliggaam - 'n algemene omweg wat nie uniek is aan Oak nie. In plaas van 'n spesifieke verwerker wat met HEAD-versoeke werk, word hulle eenvoudigweg **aan die GET-verwerker gegee, maar die program verwyder net die responsliggaam**.
As 'n **CSRF-token** as **verdediging** gebruik word, kan jy probeer om dit te **uitlek** deur 'n [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) kwesbaarheid of 'n [**Dangling Markup**](dangling-markup-html-scriptless-injection/) kwesbaarheid te misbruik.
xh.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); //to send proper header info (optional, but good to have as it may sometimes not work without this)
Die kode kan gebruik word om 'n aanmeldingsvorm te Brut Force met behulp van 'n CSRF-token (Dit maak ook gebruik van die kop X-Forwarded-For om te probeer om 'n moontlike IP-swartlys te omseil):
<summary><strong>Leer AWS-hacking vanaf nul tot held met</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* As jy wil sien dat jou **maatskappy geadverteer word in HackTricks** of **HackTricks aflaai in PDF-formaat** Kyk na die [**INSKRYWINGSPLANNE**](https://github.com/sponsors/carlospolop)!
* Ontdek [**Die PEASS Familie**](https://opensea.io/collection/the-peass-family), ons versameling eksklusiewe [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Deel jou hacktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-opslag.