<summary><strong>Lernen Sie das Hacken von AWS von Grund auf 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 bewerben möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegramm-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 senden.
OAuth bietet verschiedene Versionen, wobei grundlegende Einblicke unter [OAuth 2.0-Dokumentation](https://oauth.net/2/) verfügbar sind. Diese Diskussion konzentriert sich hauptsächlich auf den weit verbreiteten [OAuth 2.0-Autorisierungscode-Grant-Typ](https://oauth.net/2/grant-types/authorization-code/), der ein **Autorisierungsframework bereitstellt, das einer Anwendung ermöglicht, auf das Konto eines Benutzers in einer anderen Anwendung zuzugreifen oder Aktionen durchzuführen** (der Autorisierungsserver).
Nehmen wir an, es gibt eine hypothetische Website _**https://example.com**_, die dazu dient, **alle Ihre Social-Media-Beiträge** einschließlich privater Beiträge anzuzeigen. Um dies zu erreichen, wird OAuth 2.0 verwendet. _https://example.com_ wird um Ihre Erlaubnis bitten, **auf Ihre Social-Media-Beiträge zuzugreifen**. Daraufhin wird auf _https://socialmedia.com_ ein Zustimmungsbildschirm angezeigt, auf dem die **beantragten Berechtigungen und der Antragsteller** angezeigt werden. Nach Ihrer Autorisierung erhält _https://example.com_ die Möglichkeit, **in Ihrem Namen auf Ihre Beiträge zuzugreifen**.
- **Ressourceninhaber**: Sie als **Benutzer/Entität** autorisieren den Zugriff auf Ihre Ressource, z. B. Ihre Social-Media-Kontobeiträge.
- **Ressourcenserver**: Der **Server, der authentifizierte Anfragen verwaltet**, nachdem die Anwendung im Namen des Ressourceninhabers einen `Access Token` erhalten hat, z. B. **https://socialmedia.com**.
- **Client-Anwendung**: Die **Anwendung, die Autorisierung beantragt**, vom `Ressourceninhaber`, wie z. B. **https://example.com**.
- **Autorisierungsserver**: Der **Server, der `Access Tokens` ausstellt**, an die `Client-Anwendung`, nach erfolgreicher Authentifizierung des `Ressourceninhabers` und Erteilung der Autorisierung, z. B. **https://socialmedia.com**.
- **client\_id**: Eine öffentliche, eindeutige Kennung für die Anwendung.
- **client\_secret:** Ein vertraulicher Schlüssel, der nur der Anwendung und dem Autorisierungsserver bekannt ist und zur Generierung von `Access Tokens` verwendet wird.
- **response\_type**: Ein Wert, der den **Typ des angeforderten Tokens** angibt, z. B. `code`.
- **scope**: Das **Zugriffsniveau**, das von der `Client-Anwendung` vom `Ressourceninhaber` angefordert wird.
- **redirect\_uri**: Die **URL, zu der der Benutzer nach der Autorisierung umgeleitet wird**. Diese muss in der Regel mit der vorregistrierten Umleitungs-URL übereinstimmen.
- **state**: Ein Parameter, um **Daten über die Weiterleitung des Benutzers zum und vom Autorisierungsserver zu speichern**. Seine Eindeutigkeit ist entscheidend, um als **CSRF-Schutzmechanismus** zu dienen.
- **grant\_type**: Ein Parameter, der **den Grant-Typ und den Typ des zurückzugebenden Tokens** angibt.
- **code**: Der Autorisierungscode vom `Autorisierungsserver`, der zusammen mit `client_id` und `client_secret` von der Client-Anwendung verwendet wird, um einen `Access Token` zu erhalten.
- **access\_token**: Der **Token, den die Client-Anwendung für API-Anfragen** im Namen des `Ressourceninhabers` verwendet.
- **refresh\_token**: Ermöglicht der Anwendung, **einen neuen `Access Token` zu erhalten, ohne den Benutzer erneut zur Eingabe aufzufordern**.
1. Sie navigieren zu [https://example.com](https://example.com) und wählen die Schaltfläche "Mit Social Media integrieren" aus.
2. Die Website sendet dann eine Anfrage an [https://socialmedia.com](https://socialmedia.com), um Ihre Autorisierung zur Erlaubnis des Zugriffs der Anwendung von https://example.com auf Ihre Beiträge zu erhalten. Die Anfrage ist wie folgt strukturiert:
5. https://example.com verwendet diesen `code` zusammen mit seiner `client_id` und `client_secret`, um eine serverseitige Anfrage zu stellen und im Auftrag von Ihnen einen `access_token` zu erhalten. Dadurch wird der Zugriff auf die von Ihnen genehmigten Berechtigungen ermöglicht:
6. Schließlich schließt der Prozess ab, wenn https://example.com Ihren `access_token` verwendet, um einen API-Aufruf an Social Media zum Zugriff aufzurufen.
Die `redirect_uri` ist für die Sicherheit bei OAuth- und OpenID-Implementierungen entscheidend, da sie angibt, wohin sensible Daten wie Autorisierungscodes nach der Autorisierung gesendet werden. Wenn sie falsch konfiguriert ist, könnte dies Angreifern ermöglichen, diese Anfragen an bösartige Server umzuleiten und so Account-Übernahmen zu ermöglichen.
Die Ausnutzungstechniken variieren je nach Validierungslogik des Autorisierungsservers. Sie können von streichem Pfadabgleich bis zur Akzeptanz jeder URL innerhalb der angegebenen Domäne oder Unterverzeichnis reichen. Häufige Ausbeutungsmethoden umfassen offene Weiterleitungen, Pfadtraversierung, Ausnutzung schwacher Regexes und HTML-Injektion zur Token-Diebstahl.
Neben `redirect_uri` sind auch andere OAuth- und OpenID-Parameter wie `client_uri`, `policy_uri`, `tos_uri` und `initiate_login_uri` anfällig für Weiterleitungsangriffe. Diese Parameter sind optional und ihre Unterstützung variiert je nach Server.
Für diejenigen, die einen OpenID-Server ins Visier nehmen, listet der Entdeckungsendpunkt (`**.well-known/openid-configuration**`) oft wertvolle Konfigurationsdetails wie `registration_endpoint`, `request_uri_parameter_supported` und "`require_request_uri_registration`. Diese Details können dabei helfen, den Registrierungsendpunkt und andere konkrete Konfigurationen des Servers zu identifizieren.
Wie in diesem Bug-Bounty-Bericht [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) erwähnt, ist es möglich, dass die Weiterleitungs-URL in der Antwort des Servers nach der Authentifizierung des Benutzers reflektiert wird und somit anfällig für XSS ist. Möglicher Payload zum Testen:
Bei OAuth-Implementierungen kann der Missbrauch oder das Weglassen des **`state`-Parameters** das Risiko von **Cross-Site Request Forgery (CSRF)**-Angriffen erheblich erhöhen. Diese Sicherheitslücke tritt auf, wenn der `state`-Parameter entweder **nicht verwendet wird, als statischer Wert verwendet wird oder nicht ordnungsgemäß validiert wird**, was Angreifern ermöglicht, CSRF-Schutzmaßnahmen zu umgehen.
Angreifer können dies ausnutzen, indem sie den Autorisierungsprozess abfangen, um ihr Konto mit dem Konto eines Opfers zu verknüpfen, was zu potenziellen **Account Takeovers** führt. Dies ist besonders kritisch in Anwendungen, in denen OAuth für **Authentifizierungszwecke** verwendet wird.
Reale Beispiele für diese Sicherheitslücke wurden in verschiedenen **CTF-Herausforderungen** und **Hacking-Plattformen** dokumentiert, was ihre praktischen Auswirkungen verdeutlicht. Das Problem betrifft auch Integrationen mit Drittanbieterdiensten wie **Slack**, **Stripe** und **PayPal**, bei denen Angreifer Benachrichtigungen oder Zahlungen auf ihre Konten umleiten können.
Ein ordnungsgemäßer Umgang und eine Validierung des **`state`-Parameters** sind entscheidend, um sich gegen CSRF zu schützen und den OAuth-Fluss abzusichern.
1.**Ohne E-Mail-Verifizierung bei der Kontenerstellung**: Angreifer können vorbeugend ein Konto mit der E-Mail-Adresse des Opfers erstellen. Wenn das Opfer später einen Drittanbieterdienst für die Anmeldung verwendet, kann die Anwendung versehentlich dieses Drittanbieterkonto mit dem vorab erstellten Konto des Angreifers verknüpfen, was zu unbefugtem Zugriff führt.
2.**Ausnutzung der laxen OAuth-E-Mail-Verifizierung**: Angreifer können OAuth-Dienste ausnutzen, die E-Mails nicht überprüfen, indem sie sich mit ihrem Dienst registrieren und dann die E-Mail-Adresse des Kontos auf die des Opfers ändern. Diese Methode birgt ähnliche Risiken für unbefugten Zugriff auf das Konto wie das erste Szenario, jedoch über einen anderen Angriffsvektor.
Die Identifizierung und der Schutz geheimer OAuth-Parameter sind entscheidend. Während die **`client_id`** sicher offengelegt werden kann, birgt die Offenlegung des **`client_secret`** erhebliche Risiken. Wenn das `client_secret` kompromittiert ist, können Angreifer die Identität und das Vertrauen der Anwendung ausnutzen, um Benutzer-`access_tokens` und private Informationen zu stehlen.
Eine häufige Sicherheitslücke entsteht, wenn Anwendungen den Austausch des Autorisierungs-`code` gegen einen `access_token` auf der Client-Seite anstelle der Server-Seite fehlerhaft behandeln. Dieser Fehler führt zur Offenlegung des `client_secret`, was Angreifern ermöglicht, `access_tokens` unter dem Deckmantel der Anwendung zu generieren. Darüber hinaus könnten Angreifer durch Social Engineering Privilegien eskalieren, indem sie zusätzliche Scopes zur OAuth-Autorisierung hinzufügen und den vertrauenswürdigen Status der Anwendung weiter ausnutzen.
Wenn der Client den **Code und den State** hat und dieser im **Referer-Header reflektiert wird**, wenn er zu einer anderen Seite wechselt, dann ist er anfällig.
Der **Autorisierungscode sollte nur für kurze Zeit gültig sein, um das Zeitfenster zu begrenzen, in dem ein Angreifer ihn stehlen und verwenden kann**.
**[Überprüfen Sie diesen Beitrag](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)**
In diesem Bug-Bounty-Bericht: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) können Sie sehen, dass das **Token**, das **AWS Cognito** dem Benutzer zurückgibt, möglicherweise **ausreichende Berechtigungen hat, um die Benutzerdaten zu überschreiben**. Wenn Sie also die **E-Mail-Adresse des Benutzers in eine andere E-Mail-Adresse ändern können**, können Sie möglicherweise **andere Konten übernehmen**.
Wie in diesem [**Artikel**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts) erwähnt, können OAuth-Flows, die erwarten, dass das **Token** (und nicht ein Code) empfangen wird, anfällig sein, wenn sie nicht überprüfen, ob das Token zur App gehört.
Dies liegt daran, dass ein **Angreifer** eine **Anwendung erstellen** könnte, die OAuth unterstützt und sich mit Facebook (zum Beispiel) in seiner eigenen Anwendung anmeldet. Sobald ein Opfer sich mit Facebook in der **Anwendung des Angreifers** anmeldet, kann der Angreifer das **OAuth-Token des Benutzers erhalten, das seiner Anwendung gegeben wurde, und es verwenden, um sich in der OAuth-Anwendung des Opfers mit dem Token des Opfers anzumelden**.
Daher kann der Angreifer, wenn es ihm gelingt, den Benutzer dazu zu bringen, seine eigene OAuth-Anwendung zu nutzen, das Konto des Opfers in Anwendungen übernehmen, die ein Token erwarten und nicht überprüfen, ob das Token ihrer App-ID zugewiesen wurde.
Laut [**diesem Artikel**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f) war es möglich, ein Opfer dazu zu bringen, eine Seite mit einer **returnUrl** zu öffnen, die auf den Host des Angreifers verweist. Diese Informationen würden in einem Cookie (RU) gespeichert und in einem **späteren Schritt** würde der **Prompt** den **Benutzer** fragen, ob er Zugriff auf den Host des Angreifers gewähren möchte.
Um diesen Prompt zu umgehen, war es möglich, einen Tab zu öffnen, um den **OAuth-Flow** zu initiieren, der dieses RU-Cookie mit der **returnUrl** setzen würde, den Tab zu schließen, bevor der Prompt angezeigt wird, und einen neuen Tab ohne diesen Wert zu öffnen. Der **Prompt informiert nicht über den Host des Angreifers**, aber das Cookie wird darauf gesetzt, sodass das **Token an den Host des Angreifers** bei der Weiterleitung gesendet wird.
Die dynamische Client-Registrierung in OAuth dient als weniger offensichtlicher, aber kritischer Vektor für Sicherheitslücken, insbesondere für **Server-seitige Anfragenfälschung (SSRF)**-Angriffe. Dieser Endpunkt ermöglicht es OAuth-Servern, Details über Client-Anwendungen zu erhalten, einschließlich sensibler URLs, die ausgenutzt werden könnten.
- Die dynamische Client-Registrierung ist oft auf `/register` abgebildet und akzeptiert Details wie `client_name`, `client_secret`, `redirect_uris` und URLs für Logos oder JSON Web Key Sets (JWKs) über POST-Anfragen.
- Diese Funktion entspricht den in **RFC7591** und **OpenID Connect Registration 1.0** festgelegten Spezifikationen, die Parameter enthalten, die anfällig für SSRF sein können.
- Der Registrierungsprozess kann Server versehentlich SSRF auf verschiedene Arten aussetzen:
- **`logo_uri`**: Eine URL für das Logo der Client-Anwendung, das vom Server abgerufen werden könnte und SSRF auslöst oder zu XSS führt, wenn die URL falsch behandelt wird.
- **`jwks_uri`**: Eine URL zum JWK-Dokument des Clients, das bei bösartiger Gestaltung den Server dazu veranlassen kann, ausgehende Anfragen an einen vom Angreifer kontrollierten Server zu stellen.
- **`sector_identifier_uri`**: Verweist auf ein JSON-Array von `redirect_uris`, das der Server abrufen könnte und so eine SSRF-Möglichkeit schafft.
- **`request_uris`**: Listet erlaubte Anforderungs-URIs für den Client auf, die ausgenutzt werden können, wenn der Server diese URIs zu Beginn des Autorisierungsprozesses abruft.
- SSRF kann ausgelöst werden, indem ein neuer Client mit bösartigen URLs in Parametern wie `logo_uri`, `jwks_uri` oder `sector_identifier_uri` registriert wird.
- Während eine direkte Ausbeutung über `request_uris` durch Whitelist-Steuerungen gemildert werden kann, kann die Bereitstellung einer vorregistrierten, vom Angreifer kontrollierten `request_uri` SSRF während der Autorisierungsphase erleichtern.
<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 bewerben möchten** oder **HackTricks im PDF-Format herunterladen** möchten, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegramm-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 senden.
