<summary><strong>Lernen Sie AWS-Hacking von Null auf Held mit</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.
Treten Sie dem [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!
**Cross-Site Request Forgery (CSRF)** ist ein Typ von Sicherheitslücke, die in Webanwendungen gefunden wird. Es ermöglicht Angreifern, Aktionen im Namen ahnungsloser Benutzer auszuführen, indem sie deren authentifizierte Sitzungen ausnutzen. Der Angriff wird ausgeführt, wenn ein Benutzer, der in die Plattform eines Opfers eingeloggt ist, eine bösartige Website besucht. Diese Website löst dann Anfragen an das Konto des Opfers aus, indem sie Methoden wie das Ausführen von JavaScript, das Absenden von Formularen oder das Abrufen von Bildern verwendet.
1.**Identifizierung einer wertvollen Aktion**: Der Angreifer muss eine lohnenswerte Aktion finden, die ausgenutzt werden kann, wie z.B. das Ändern des Benutzerpassworts, der E-Mail oder das Erhöhen von Berechtigungen.
2.**Sitzungsverwaltung**: Die Sitzung des Benutzers sollte ausschließlich über Cookies oder den HTTP Basic Authentication-Header verwaltet werden, da andere Header nicht für diesen Zweck manipuliert werden können.
Sie könnten **die Anfrage in Burp erfassen** und CSRF-Schutzmaßnahmen überprüfen und um es aus dem Browser zu testen, können Sie auf **Als fetch kopieren** klicken und die Anfrage überprüfen:
* [**SameSite-Cookies**](hacking-with-cookies/#samesite): Dieses Attribut verhindert, dass der Browser Cookies zusammen mit Cross-Site-Anfragen sendet. [Mehr über SameSite-Cookies](hacking-with-cookies/#samesite).
* [**Cross-Origin-Ressourcenfreigabe**](cors-bypass.md): Die CORS-Richtlinie der Opferseite kann die Durchführbarkeit des Angriffs beeinflussen, insbesondere wenn der Angriff erfordert, dass die Antwort von der Opferseite gelesen wird. [Erfahren Sie mehr über CORS-Bypass](cors-bypass.md).
* **Benutzerverifizierung**: Das Auffordern des Benutzerpassworts oder das Lösen eines Captchas kann die Absicht des Benutzers bestätigen.
* **Überprüfung von Referrer- oder Origin-Headern**: Die Validierung dieser Header kann dazu beitragen, sicherzustellen, dass Anfragen von vertrauenswürdigen Quellen stammen. Eine sorgfältige Gestaltung von URLs kann jedoch schlecht implementierte Überprüfungen umgehen, wie z.B.:
* Verwendung von `http://mal.net?orig=http://example.com` (URL endet mit der vertrauenswürdigen URL)
* Verwendung von `http://example.com.mal.net` (URL beginnt mit der vertrauenswürdigen URL)
* **Ändern von Parameternamen**: Das Ändern von Parameternamen in POST- oder GET-Anfragen kann helfen, automatisierte Angriffe zu verhindern.
* **CSRF-Token**: Die Integration eines eindeutigen CSRF-Tokens in jede Sitzung und die Anforderung dieses Tokens in nachfolgenden Anfragen können das Risiko von CSRF erheblich verringern. Die Effektivität des Tokens kann durch die Durchsetzung von CORS verbessert werden.
Das Verständnis und die Implementierung dieser Abwehrmaßnahmen sind entscheidend für die Aufrechterhaltung der Sicherheit und Integrität von Webanwendungen.
Vielleicht ist das Formular, das Sie missbrauchen möchten, darauf vorbereitet, eine **POST-Anfrage mit einem CSRF-Token zu senden**, aber Sie sollten überprüfen, ob ein **GET** ebenfalls **gültig** ist und ob beim Senden einer GET-Anfrage das **CSRF-Token immer noch validiert wird**.
Anwendungen könnten einen Mechanismus implementieren, um **Tokens zu validieren**, wenn sie vorhanden sind. Es entsteht jedoch eine Sicherheitslücke, wenn die Validierung vollständig übersprungen wird, wenn das Token fehlt. Angreifer können dies ausnutzen, indem sie den Parameter entfernen, der das Token trägt, nicht nur dessen Wert. Dies ermöglicht es ihnen, den Validierungsprozess zu umgehen und einen Cross-Site Request Forgery (CSRF)-Angriff effektiv durchzuführen.
Anwendungen, die CSRF-Tokens **nicht an Benutzersitzungen binden**, stellen ein erhebliches **Sicherheitsrisiko** dar. Diese Systeme überprüfen Tokens gegen einen **globalen Pool**, anstatt sicherzustellen, dass jedes Token an die initiierende Sitzung gebunden ist.
Diese Sicherheitslücke ermöglicht es Angreifern, unbefugte Anfragen im Namen des Opfers zu stellen, indem sie den unzureichenden Token-Validierungsmechanismus der Anwendung ausnutzen.
Wenn die Anfrage eine "**seltsame**" **Methode** verwendet, überprüfen Sie, ob die **Methode****Überschreibungsfunktion** funktioniert. Wenn beispielsweise eine **PUT**-Methode verwendet wird, können Sie versuchen, eine **POST**-Methode zu verwenden und zu **senden**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
Dies könnte auch funktionieren, indem der **\_method-Parameter innerhalb einer POST-Anfrage** gesendet wird oder indem die **Header** verwendet werden:
Anwendungen können CSRF-Schutz implementieren, indem sie das Token sowohl in einem Cookie als auch in einem Anfrageparameter duplizieren oder indem sie ein CSRF-Cookie setzen und überprüfen, ob das im Backend gesendete Token mit dem Cookie übereinstimmt. Die Anwendung validiert Anfragen, indem sie überprüft, ob das Token im Anfrageparameter mit dem Wert im Cookie übereinstimmt.
Diese Methode ist jedoch anfällig für CSRF-Angriffe, wenn die Website Fehler aufweist, die es einem Angreifer ermöglichen, ein CSRF-Cookie im Browser des Opfers zu setzen, wie z.B. eine CRLF-Sicherheitslücke. Der Angreifer kann dies ausnutzen, indem er ein irreführendes Bild lädt, das das Cookie setzt, gefolgt von der Initiierung des CSRF-Angriffs.
Beachten Sie, dass, wenn das **CSRF-Token mit dem Sitzungscookie verknüpft ist, dieser Angriff nicht funktioniert**, da Sie dem Opfer Ihre Sitzung mitteilen müssten und somit sich selbst angreifen würden.
Gemäß [**dieser Quelle**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests) sind zur **Vermeidung von Preflight-Anfragen** bei Verwendung der **POST**-Methode die folgenden Content-Type-Werte zulässig:
Beachten Sie jedoch, dass die **Serverlogik variieren kann**, abhängig vom verwendeten **Content-Type**, daher sollten Sie die genannten Werte und andere wie **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Beim Versuch, JSON-Daten über eine POST-Anfrage zu senden, ist die Verwendung von `Content-Type: application/json` in einem HTML-Formular nicht direkt möglich. Ebenso führt die Verwendung von `XMLHttpRequest` zur Sendung dieses Inhaltstyps zu einer Preflight-Anfrage. Dennoch gibt es Strategien, um diese Einschränkung möglicherweise zu umgehen und zu überprüfen, ob der Server die JSON-Daten verarbeitet, unabhängig vom Content-Type:
1.**Verwendung alternativer Content-Typen**: Verwenden Sie `Content-Type: text/plain` oder `Content-Type: application/x-www-form-urlencoded`, indem Sie `enctype="text/plain"` im Formular festlegen. Dieser Ansatz testet, ob das Backend die Daten unabhängig vom Content-Type verwendet.
2.**Ändern des Content-Typs**: Um eine Preflight-Anfrage zu vermeiden und gleichzeitig sicherzustellen, dass der Server den Inhalt als JSON erkennt, können Sie die Daten mit `Content-Type: text/plain; application/json` senden. Dies löst keine Preflight-Anfrage aus, könnte aber vom Server korrekt verarbeitet werden, wenn er konfiguriert ist, `application/json` zu akzeptieren.
3.**SWF-Flash-Datei-Nutzung**: Eine weniger verbreitete, aber machbare Methode besteht darin, eine SWF-Flash-Datei zu verwenden, um solche Einschränkungen zu umgehen. Für ein tieferes Verständnis dieser Technik siehe [diesen Beitrag](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
Anwendungen können den 'Referer'-Header nur validieren, wenn er vorhanden ist. Um zu verhindern, dass ein Browser diesen Header sendet, kann das folgende HTML-Meta-Tag verwendet werden:
Der erste Teil [**dieses CTF-Lösungsberichts**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) erklärt, dass im [Oak-Quellcode](https://github.com/oakserver/oak/blob/main/router.ts#L281) ein Router so eingestellt ist, dass **HEAD-Anfragen als GET-Anfragen behandelt** werden, ohne Antwortkörper - ein gängiger Workaround, der nicht einzigartig für Oak ist. Anstatt eines spezifischen Handlers, der mit HEAD-Anfragen umgeht, werden sie einfach **an den GET-Handler übergeben, aber die App entfernt einfach den Antwortkörper**.
Wenn ein **CSRF-Token** als **Schutzmaßnahme** verwendet wird, könnten Sie versuchen, es durch eine [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens)-Schwachstelle oder eine [**Dangling Markup**](dangling-markup-html-scriptless-injection/)-Schwachstelle **exfiltrieren**.
When an attacker tricks a victim into submitting a malicious request via a form on a trusted website, it is known as a Cross-Site Request Forgery (CSRF) attack. The attacker crafts a request that performs an action on the target website using the victim's authenticated session. This can lead to unauthorized actions being performed without the victim's consent.
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)
Der Code kann verwendet werden, um ein Anmeldeformular mithilfe eines CSRF-Tokens mit Bruteforce anzugreifen (Es verwendet auch den Header X-Forwarded-For, um zu versuchen, eine mögliche IP-Blacklist zu umgehen):
Treten Sie dem [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.