OAuth zu Kontoübernahme
Reading time: 17 minutes
tip
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Unterstützen Sie HackTricks
- Überprüfen Sie die Abonnementpläne!
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.
Grundlegende Informationen
OAuth bietet verschiedene Versionen, mit grundlegenden Einblicken, die in der OAuth 2.0-Dokumentation verfügbar sind. Diese Diskussion konzentriert sich hauptsächlich auf den weit verbreiteten OAuth 2.0-Autorisierungscode-Grant-Typ, der einen Autorisierungsrahmen bietet, der es einer Anwendung ermöglicht, auf das Konto eines Benutzers in einer anderen Anwendung zuzugreifen oder Aktionen durchzuführen (dem Autorisierungsserver).
Betrachten Sie eine hypothetische Website https://example.com, die alle Ihre Social-Media-Beiträge anzeigen soll, einschließlich privater. Um dies zu erreichen, wird OAuth 2.0 verwendet. https://example.com wird um Ihre Erlaubnis bitten, auf Ihre Social-Media-Beiträge zuzugreifen. Folglich erscheint ein Zustimmungsbildschirm auf https://socialmedia.com, der die angeforderten Berechtigungen und den Entwickler, der die Anfrage stellt, umreißt. Nach Ihrer Genehmigung erhält https://example.com die Fähigkeit, in Ihrem Namen auf Ihre Beiträge zuzugreifen.
Es ist wichtig, die folgenden Komponenten innerhalb des OAuth 2.0-Rahmens zu verstehen:
- resource owner: Sie, als der Benutzer/Entität, autorisieren den Zugriff auf Ihre Ressource, wie Ihre Social-Media-Kontenbeiträge.
- resource server: Der Server, der authentifizierte Anfragen verwaltet, nachdem die Anwendung ein
access token
im Namen desresource owner
gesichert hat, z.B. https://socialmedia.com. - client application: Die Anwendung, die Autorisierung vom
resource owner
anfordert, wie https://example.com. - authorization server: Der Server, der
access tokens
an dieclient application
nach erfolgreicher Authentifizierung desresource owner
und Sicherstellung der Autorisierung ausgibt, z.B. https://socialmedia.com. - client_id: Ein öffentlicher, eindeutiger Identifikator für die Anwendung.
- client_secret: Ein vertraulicher Schlüssel, der nur der Anwendung und dem Autorisierungsserver bekannt ist, der zur Generierung von
access_tokens
verwendet wird. - response_type: Ein Wert, der den angeforderten Token-Typ angibt, wie
code
. - scope: Der Zugriffslevel, den die
client application
vomresource owner
anfordert. - redirect_uri: Die URL, zu der der Benutzer nach der Autorisierung umgeleitet wird. Diese muss in der Regel mit der vorab registrierten Umleitungs-URL übereinstimmen.
- state: Ein Parameter, um Daten während der Umleitung des Benutzers zum und vom Autorisierungsserver aufrechtzuerhalten. Seine Einzigartigkeit ist entscheidend, um als CSRF-Schutzmechanismus zu dienen.
- grant_type: Ein Parameter, der den Grant-Typ und den zurückzugebenden Token-Typ angibt.
- code: Der Autorisierungscode vom
authorization server
, der zusammen mitclient_id
undclient_secret
von der Client-Anwendung verwendet wird, um einaccess_token
zu erwerben. - access_token: Der Token, den die Client-Anwendung für API-Anfragen im Namen des
resource owner
verwendet. - refresh_token: Ermöglicht der Anwendung, ein neues
access_token
zu erhalten, ohne den Benutzer erneut zu fragen.
Ablauf
Der tatsächliche OAuth-Ablauf verläuft wie folgt:
- Sie navigieren zu https://example.com und wählen die Schaltfläche „Mit Social Media integrieren“.
- Die Website sendet dann eine Anfrage an https://socialmedia.com, in der um Ihre Genehmigung gebeten wird, damit die Anwendung von https://example.com auf Ihre Beiträge zugreifen kann. Die Anfrage ist wie folgt strukturiert:
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
- Ihnen wird dann eine Zustimmungsseite angezeigt.
- Nach Ihrer Genehmigung sendet Social Media eine Antwort an die
redirect_uri
mit den Parameterncode
undstate
:
https://example.com?code=uniqueCode123&state=randomString123
- https://example.com verwendet diesen
code
zusammen mit seinerclient_id
undclient_secret
, um eine serverseitige Anfrage zu stellen, um einaccess_token
in Ihrem Namen zu erhalten, das den Zugriff auf die Berechtigungen ermöglicht, denen Sie zugestimmt haben:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
- Schließlich endet der Prozess, wenn https://example.com Ihr
access_token
verwendet, um einen API-Aufruf an Social Media zu tätigen, um auf
Schwachstellen
Offene redirect_uri
Die redirect_uri
ist entscheidend für die Sicherheit in OAuth- und OpenID-Implementierungen, 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, was einen Account-Übernahme ermöglicht.
Die Ausbeutungstechniken variieren je nach Validierungslogik des Autorisierungsservers. Sie können von striktem Pfadabgleich bis hin zur Akzeptanz beliebiger URLs innerhalb der angegebenen Domain oder Unterverzeichnisse reichen. Zu den gängigen Ausbeitungsmethoden gehören offene Umleitungen, Pfadtraversierung, das Ausnutzen schwacher Regex und HTML-Injektion zum Diebstahl von Tokens.
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 Umleitungsangriffe. Diese Parameter sind optional und ihre Unterstützung variiert zwischen den Servern.
Für diejenigen, die einen OpenID-Server anvisieren, 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 helfen, den Registrierungsendpunkt und andere Konfigurationsspezifika des Servers zu identifizieren.
XSS in der Umleitungsimplementierung
Wie in diesem Bug-Bounty-Bericht erwähnt https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, könnte es möglich sein, dass die Umleitungs-URL in der Antwort des Servers nach der Authentifizierung des Benutzers reflektiert wird und anfällig für XSS ist. Mögliche Payload zum Testen:
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
CSRF - Unsachgemäße Handhabung des Statusparameters
In OAuth-Implementierungen kann der Missbrauch oder das Versäumnis des state
-Parameters das Risiko von Cross-Site Request Forgery (CSRF)-Angriffen erheblich erhöhen. Diese Schwachstelle entsteht, wenn der state
-Parameter entweder nicht verwendet, als statischer Wert verwendet oder nicht ordnungsgemäß validiert oder mit der Benutzersitzung verknüpft wird, während man sich anmeldet, 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 Kontoübernahmen führt, indem ein Benutzer sich mit einem fast abgeschlossenen OAuth-Flow anmeldet, der dem Angreifer gehört. Dies ist besonders kritisch in Anwendungen, in denen OAuth für Authentifizierungszwecke verwendet wird.
Echte Beispiele für diese Schwachstelle wurden in verschiedenen CTF-Herausforderungen und Hacking-Plattformen dokumentiert, die ihre praktischen Auswirkungen hervorheben. Das Problem erstreckt sich auch auf Integrationen mit Drittanbieterdiensten wie Slack, Stripe und PayPal, wo Angreifer Benachrichtigungen oder Zahlungen auf ihre Konten umleiten können.
Eine ordnungsgemäße Handhabung und Validierung des state
-Parameters ist entscheidend, um sich gegen CSRF zu schützen und den OAuth-Flow abzusichern.
Vor der Kontoübernahme
- Ohne E-Mail-Verifizierung bei der Kontoerstellung: Angreifer können proaktiv ein Konto mit der E-Mail des Opfers erstellen. Wenn das Opfer später einen Drittanbieterdienst für die Anmeldung verwendet, könnte die Anwendung versehentlich dieses Drittanbieter-Konto mit dem vom Angreifer erstellten Konto verknüpfen, was zu unbefugtem Zugriff führt.
- Ausnutzung laxen OAuth-E-Mail-Verifizierung: Angreifer können OAuth-Dienste ausnutzen, die E-Mails nicht verifizieren, indem sie sich bei ihrem Dienst registrieren und dann die Kontoe-Mail auf die des Opfers ändern. Diese Methode birgt ähnlich das Risiko eines unbefugten Zugriffs auf das Konto, ähnlich dem ersten Szenario, jedoch über einen anderen Angriffsvektor.
Offenlegung von Geheimnissen
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 wird, können Angreifer die Identität und das Vertrauen der Anwendung ausnutzen, um Benutzer-access_tokens
und private Informationen zu stehlen.
Eine häufige Schwachstelle entsteht, wenn Anwendungen fälschlicherweise den Austausch des Autorisierungscodes gegen ein access_token
auf der Client-Seite anstelle der Server-Seite behandeln. Dieser Fehler führt zur Offenlegung des client_secret
, was es Angreifern ermöglicht, access_tokens
im Namen der Anwendung zu generieren. Darüber hinaus könnten Angreifer durch Social Engineering Privilegien erhöhen, indem sie zusätzliche Scopes zur OAuth-Autorisierung hinzufügen und so den vertrauenswürdigen Status der Anwendung weiter ausnutzen.
Client Secret Bruteforce
Sie können versuchen, das client_secret eines Dienstanbieters mit dem Identitätsanbieter zu bruteforcen, um zu versuchen, Konten zu stehlen.
Die Anfrage zum BF könnte ähnlich aussehen wie:
POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close
code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]
Referer-Header leckt Code + State
Sobald der Client den Code und State hat, wenn er im Referer-Header reflektiert wird, während er zu einer anderen Seite navigiert, ist er anfällig.
Zugriffstoken im Browserverlauf gespeichert
Gehe zum Browserverlauf und überprüfe, ob das Zugriffstoken dort gespeichert ist.
Dauerhafter Autorisierungscode
Der Autorisierungscode sollte nur für eine gewisse Zeit gültig sein, um das Zeitfenster zu begrenzen, in dem ein Angreifer ihn stehlen und verwenden kann.
Autorisierungs-/Aktualisierungstoken nicht an den Client gebunden
Wenn du den Autorisierungscode erhalten und ihn mit einem anderen Client verwenden kannst, kannst du andere Konten übernehmen.
Glückliche Pfade, XSS, Iframes & Post-Nachrichten zum Lecken von Code- & State-Werten
AWS Cognito
In diesem Bug-Bounty-Bericht: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ kannst du sehen, dass das Token, das AWS Cognito dem Benutzer zurückgibt, ausreichende Berechtigungen haben könnte, um die Benutzerdaten zu überschreiben. Daher, wenn du die Benutzer-E-Mail für eine andere Benutzer-E-Mail ändern kannst, könntest du in der Lage sein, andere Konten zu übernehmen.
# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]
# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}
Für detailliertere Informationen darüber, wie man AWS Cognito missbrauchen kann, siehe:
AWS - Cognito Unauthenticated Enum - HackTricks Cloud
Missbrauch anderer App-Token
Wie in diesem Bericht erwähnt, könnten OAuth-Flows, die erwarten, das Token (und nicht einen Code) zu erhalten, anfällig sein, wenn sie nicht überprüfen, ob das Token zur App gehört.
Das liegt daran, dass ein Angreifer eine Anwendung, die OAuth unterstützt und sich mit Facebook anmeldet (zum Beispiel), in seiner eigenen Anwendung erstellen könnte. Sobald ein Opfer sich mit Facebook in der Anwendung des Angreifers anmeldet, könnte der Angreifer das OAuth-Token des Benutzers, das seiner Anwendung gegeben wurde, erhalten und es verwenden, um sich in der OAuth-Anwendung des Opfers mit dem Benutzer-Token des Opfers anzumelden.
vorsicht
Daher, wenn es dem Angreifer gelingt, dass der Benutzer auf seine eigene OAuth-Anwendung zugreift, wird er in der Lage sein, das Konto des Opfers in Anwendungen zu übernehmen, die ein Token erwarten und nicht überprüfen, ob das Token ihrer App-ID zugewiesen wurde.
Zwei Links & Cookie
Laut diesem Bericht war es möglich, ein Opfer dazu zu bringen, eine Seite mit einem returnUrl zu öffnen, die auf den Host des Angreifers zeigt. Diese Informationen würden in einem Cookie (RU) gespeichert und in einem späteren Schritt wird die Eingabeaufforderung den Benutzer fragen, ob er Zugriff auf den Host des Angreifers gewähren möchte.
Um diese Eingabeaufforderung 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 die Eingabeaufforderung angezeigt wird, und einen neuen Tab ohne diesen Wert zu öffnen. Dann wird die Eingabeaufforderung nicht über den Host des Angreifers informieren, aber das Cookie würde auf ihn gesetzt, sodass das Token an den Host des Angreifers in der Umleitung gesendet wird.
Eingabeaufforderung Interaktionsumgehung
Wie in diesem Video erklärt, erlauben einige OAuth-Implementierungen, den prompt
GET-Parameter als None (&prompt=none
) anzugeben, um zu verhindern, dass Benutzer gefragt werden, ob sie den gegebenen Zugriff in einer Eingabeaufforderung im Web bestätigen, wenn sie bereits in der Plattform angemeldet sind.
response_mode
Wie in diesem Video erklärt, könnte es möglich sein, den Parameter response_mode
anzugeben, um zu bestimmen, wo der Code in der finalen URL bereitgestellt werden soll:
response_mode=query
-> Der Code wird innerhalb eines GET-Parameters bereitgestellt:?code=2397rf3gu93f
response_mode=fragment
-> Der Code wird innerhalb des URL-Fragmentparameters#code=2397rf3gu93f
bereitgestelltresponse_mode=form_post
-> Der Code wird innerhalb eines POST-Formulars mit einem Eingabefeld namenscode
und dem Wert bereitgestelltresponse_mode=web_message
-> Der Code wird in einer Post-Nachricht gesendet:window.opener.postMessage({"code": "asdasdasd...
OAuth ROPC-Flow - 2 FA-Umgehung
Laut diesem Blogbeitrag handelt es sich um einen OAuth-Flow, der es ermöglicht, sich über Benutzername und Passwort bei OAuth anzumelden. Wenn während dieses einfachen Flows ein Token zurückgegeben wird, das Zugriff auf alle Aktionen hat, die der Benutzer ausführen kann, ist es möglich, 2FA mit diesem Token zu umgehen.
ATO auf Webseitenumleitung basierend auf offener Umleitung zum Referrer
Dieser Blogbeitrag beschreibt, wie es möglich war, eine offene Umleitung zum Wert des Referrers zu missbrauchen, um OAuth für ATO zu missbrauchen. Der Angriff war:
- Das Opfer greift auf die Webseite des Angreifers zu
- Das Opfer öffnet den bösartigen Link und ein Opener startet den Google OAuth-Flow mit
response_type=id_token,code&prompt=none
als zusätzliche Parameter unter Verwendung der Referrer der Webseite des Angreifers. - Im Opener, nachdem der Anbieter das Opfer autorisiert hat, sendet er sie zurück zum Wert des
redirect_uri
-Parameters (Opfer-Web) mit einem 30X-Code, der die Webseite des Angreifers weiterhin im Referrer behält. - Die Webseite des Opfers löst die offene Umleitung basierend auf dem Referrer aus, indem sie den Benutzer des Opfers zur Webseite des Angreifers umleitet, da der
respose_type
id_token,code
war, wird der Code im Fragment der URL an den Angreifer zurückgesendet, was ihm ermöglicht, das Konto des Benutzers über Google auf der Webseite des Opfers zu übernehmen.
SSRFs-Parameter
Überprüfen Sie diese Forschung Für weitere Details zu dieser Technik.
Die dynamische Client-Registrierung in OAuth dient als weniger offensichtlicher, aber kritischer Vektor für Sicherheitsanfälligkeiten, insbesondere für Server-Side Request Forgery (SSRF)-Angriffe. Dieser Endpunkt ermöglicht es OAuth-Servern, Details über Client-Anwendungen zu erhalten, einschließlich sensibler URLs, die ausgenutzt werden könnten.
Wichtige Punkte:
- Dynamische Client-Registrierung wird oft auf
/register
abgebildet und akzeptiert Details wieclient_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 potenziell anfällig für SSRF sind.
- Der Registrierungsprozess kann unbeabsichtigt Server in mehreren Wegen SSRF aussetzen:
logo_uri
: Eine URL für das Logo der Client-Anwendung, die möglicherweise vom Server abgerufen wird, was SSRF auslösen oder zu XSS führen kann, wenn die URL falsch behandelt wird.jwks_uri
: Eine URL zum JWK-Dokument des Clients, die, wenn bösartig erstellt, den Server dazu bringen kann, ausgehende Anfragen an einen vom Angreifer kontrollierten Server zu stellen.sector_identifier_uri
: Verweist auf ein JSON-Array vonredirect_uris
, die der Server abrufen könnte, was eine SSRF-Möglichkeit schafft.request_uris
: Listet erlaubte Anfrage-URIs für den Client auf, die ausgenutzt werden können, wenn der Server diese URIs zu Beginn des Autorisierungsprozesses abruft.
Ausbeutungsstrategie:
- SSRF kann ausgelöst werden, indem ein neuer Client mit bösartigen URLs in Parametern wie
logo_uri
,jwks_uri
odersector_identifier_uri
registriert wird. - Während eine direkte Ausbeutung über
request_uris
möglicherweise durch Whitelist-Kontrollen gemildert wird, kann die Bereitstellung einer vorregistrierten, vom Angreifer kontrolliertenrequest_uri
während der Autorisierungsphase SSRF erleichtern.
OAuth-Anbieter-Race Conditions
Wenn die Plattform, die Sie testen, ein OAuth-Anbieter ist, lesen Sie dies, um mögliche Race Conditions zu testen.
Mutable Claims Attack
In OAuth identifiziert das Sub-Feld eindeutig einen Benutzer, aber sein Format variiert je nach Autorisierungsserver. Um die Benutzeridentifikation zu standardisieren, verwenden einige Clients E-Mails oder Benutzerhandles. Dies ist jedoch riskant, da:
- Einige Autorisierungsserver nicht sicherstellen, dass diese Eigenschaften (wie E-Mail) unveränderlich bleiben.
- In bestimmten Implementierungen – wie "Anmelden mit Microsoft" – verlässt sich der Client auf das E-Mail-Feld, das vom Benutzer in Entra ID kontrolliert wird und nicht verifiziert ist.
- Ein Angreifer kann dies ausnutzen, indem er seine eigene Azure AD-Organisation (z. B. doyensectestorg) erstellt und sie verwendet, um sich bei Microsoft anzumelden.
- Obwohl die Objekt-ID (die in sub gespeichert ist) unveränderlich und sicher ist, kann die Abhängigkeit von einem veränderlichen E-Mail-Feld eine Kontoübernahme ermöglichen (zum Beispiel, indem ein Konto wie victim@gmail.com übernommen wird).
Client Confusion Attack
In einem Client Confusion Attack versäumt es eine Anwendung, die den OAuth Implicit Flow verwendet, zu überprüfen, ob das endgültige Zugriffstoken speziell für ihre eigene Client-ID generiert wurde. Ein Angreifer richtet eine öffentliche Website ein, die den OAuth Implicit Flow von Google verwendet, und trickst Tausende von Benutzern aus, sich anzumelden und dadurch Zugriffstoken zu sammeln, die für die Website des Angreifers bestimmt sind. Wenn diese Benutzer auch Konten auf einer anderen anfälligen Website haben, die die Client-ID des Tokens nicht validiert, kann der Angreifer die gesammelten Tokens wiederverwenden, um die Opfer zu impersonieren und deren Konten zu übernehmen.
Scope Upgrade Attack
Der Authorization Code Grant-Typ umfasst sichere serverseitige Kommunikation zur Übertragung von Benutzerdaten. Wenn der Authorization Server jedoch einen Scope-Parameter in der Access Token-Anfrage implizit vertraut (ein Parameter, der in der RFC nicht definiert ist), könnte eine bösartige Anwendung die Berechtigungen eines Autorisierungscodes erhöhen, indem sie einen höheren Scope anfordert. Nachdem das Access Token generiert wurde, muss der Resource Server es überprüfen: Bei JWT-Token umfasst dies die Überprüfung der JWT-Signatur und das Extrahieren von Daten wie client_id und scope, während der Server bei zufälligen String-Token den Authorization Server abfragen muss, um die Details des Tokens abzurufen.
Redirect Scheme Hijacking
In mobilen OAuth-Implementierungen verwenden Apps benutzerdefinierte URI-Schemata, um Redirects mit Autorisierungscodes zu empfangen. Da jedoch mehrere Apps dasselbe Schema auf einem Gerät registrieren können, wird die Annahme, dass nur der legitime Client die Redirect-URI kontrolliert, verletzt. Auf Android beispielsweise wird eine Intent-URI wie com.example.app://
oauth basierend auf dem Schema und optionalen Filtern, die in einem Intent-Filter der App definiert sind, erfasst. Da die Intent-Auflösung von Android breit gefächert sein kann – insbesondere wenn nur das Schema angegeben ist – kann ein Angreifer eine bösartige App mit einem sorgfältig gestalteten Intent-Filter registrieren, um den Autorisierungscode zu hijacken. Dies kann eine Kontoübernahme ermöglichen, entweder durch Benutzerinteraktion (wenn mehrere Apps berechtigt sind, die Absicht zu behandeln) oder durch Umgehungstechniken, die übermäßig spezifische Filter ausnutzen, wie im Bewertungsflussdiagramm von Ostorlab beschrieben.
Referenzen
- https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
- https://portswigger.net/research/hidden-oauth-attack-vectors
- https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html
tip
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Unterstützen Sie HackTricks
- Überprüfen Sie die Abonnementpläne!
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.