← Zurück zum Blog

Checkliste für OAuth-Sicherheitstests: Authentifizierungsfehler mit schwerwiegenden Auswirkungen finden

Schwachstellen in OAuth 2.0 führen regelmäßig die Ranglisten der Bug-Bounty-Auszahlungen für kritische Sicherheitslücken an. Eine einzige Kontoübernahme aufgrund einer OAuth-Fehlkonfiguration kann zur vollständigen Kompromittierung eines Unternehmens führen — und solche Fehler treten in Anwendungen auf, die von Milliarden Menschen genutzt werden.

---

Grundlagen von OAuth 2.0 für Sicherheitstests

Wichtige OAuth-Komponenten

• Autorisierungsserver (AS) — Stellt Token aus (z. B. Google, Okta, Auth0)
• Ressourcenserver (RS) — API, die Token akzeptiert
• Client — Ihre Anwendung, die Zugriff anfordert
• Ressourceneigentümer — Der Nutzer, der Zugriff gewährt
• Autorisierungscode — Kurzlebiger, einmalig verwendbarer Code, der gegen Token eingetauscht wird
• Zugriffstoken — Bearer-Token für den API-Zugriff
• Aktualisierungstoken — Langlebiges Token zum Abrufen neuer Zugriffstoken
• PKCE — Proof Key for Code Exchange (verhindert das Abfangen von Codes)

---

Abschnitt 1: Abfangen des Autorisierungscodes

Test 1.1 — Offene Weiterleitung in redirect_uri

Wenn der Autorisierungsserver redirect_uri nicht präzise genug validiert, kann ein Angreifer den Autorisierungscode an einen von ihm kontrollierten Server weiterleiten.

# Legitime Anfrage
https://auth.example.com/oauth/authorize?
  client_id=app123&
  redirect_uri=https://app.com/callback&
  response_type=code&state=xyz

# Angriffsversuche
# 1. Pfadtraversierung
redirect_uri=https://app.com/callback/../../../evil.com/steal

# 2. Zusätzlicher Pfad
redirect_uri=https://app.com.evil.com/callback

# 3. Umgehung mittels Fragment
redirect_uri=https://app.com/callback%23@evil.com

# 4. Umgehung mittels Abfragezeichenfolge
redirect_uri=https://app.com/callback?next=https://evil.com

Test 1.2 — Validierung des state-Parameters

# Prüfen, ob state:
# 1. In der Autorisierungsanfrage vorhanden ist
# 2. Beim Callback validiert wird
# 3. Kryptografisch zufällig ist (nicht sequenziell/vorhersehbar)
# 4. Nur einmal verwendbar ist (wiederverwendete state-Werte sollten abgelehnt werden)

# Test: denselben state-Parameter erneut verwenden
curl -s "https://app.com/oauth/callback?code=VALID_CODE&state=PREVIOUSLY_USED_STATE"
# Sollte zurückgeben: Fehler (state bereits verwendet)

Test 1.3 — Wiederverwendung von Codes

# Autorisierungscodes dürfen nur einmal verwendet werden
# Durch erneutes Senden des Codes nach dem ersten Austausch testen:

# Erste Verwendung (legitim)
POST /oauth/token
code=AUTH_CODE_123&grant_type=authorization_code&...

# Zweite Verwendung (sollte fehlschlagen)
POST /oauth/token
code=AUTH_CODE_123&grant_type=authorization_code&...
# Erwartet: {"error": "invalid_grant"}

---

Abschnitt 2: Tests zur Umgehung von PKCE

Test 2.1 — Durchsetzung von PKCE

PKCE verhindert Angriffe durch das Abfangen von Autorisierungscodes. Wenn ein Server PKCE unterstützt, aber nicht erzwingt, sind öffentliche Clients gefährdet.

# Flow MIT PKCE starten (legitim)
code_verifier = generate_random_string(64)
code_challenge = base64url(sha256(code_verifier))

GET /authorize?
  code_challenge=abc123&
  code_challenge_method=S256&...

# Angriff: Code austauschen, OHNE code_verifier bereitzustellen
POST /token
grant_type=authorization_code&
code=INTERCEPTED_CODE&
redirect_uri=https://legitimate-app.com/callback
# Fehlt: code_verifier
# Falls dies gelingt -> PKCE wird nicht erzwungen -> Kritische Schwachstelle

Test 2.2 — Herabstufung von code_challenge_method

# Versuch einer Herabstufung von S256 auf plain (weniger sicher)
GET /authorize?
  code_challenge=ACTUAL_CODE_VERIFIER&
  code_challenge_method=plain&...

# Falls akzeptiert: Der Server verwendet möglicherweise plain statt S256
# Anschließend mit code_verifier = ursprünglicher Klartext austauschen
POST /token
code_verifier=ORIGINAL_PLAIN_TEXT&...

---

Abschnitt 3: Token-Schwachstellen

Test 3.1 — Offenlegung von Zugriffstoken über den Referrer

Test 3.2 — Ausweitung des Token-Berechtigungsumfangs

# Minimalen Berechtigungsumfang anfordern
GET /authorize?scope=read:email&...

# Nach Erhalt des Zugriffstokens nicht autorisierte API-Aufrufe testen
GET /api/user/delete
Authorization: Bearer ACCESS_TOKEN_WITH_READ_SCOPE
# Sollte 403 zurückgeben, nicht 200

Test 3.3 — Schwachstellen in JWT-Zugriffstoken

# Falls Zugriffstoken JWTs sind, Folgendes testen:

# 1. Algorithmusverwechslung (RS256 -> HS256)
header = {"alg": "HS256", "typ": "JWT"}
# Mit dem öffentlichen Schlüssel als HMAC-Geheimnis signieren

# 2. None-Algorithmus
header = {"alg": "none", "typ": "JWT"}
# Einige Bibliotheken akzeptieren unsignierte Token

# 3. Kid-Injektion (falls 'kid' verwendet wird)
header = {"alg": "HS256", "kid": "' OR 1=1--"}
# SQL-Injektion im kid-Parameter

# Werkzeuge:
# jwt_tool: python3 jwt_tool.py TOKEN -T (manipulieren)
# jwt-cracker: für schwache Geheimnisse

Test 3.4 — Umgehung der Rotation von Aktualisierungstoken

# Prüfen, ob alte Aktualisierungstoken nach der Rotation ungültig werden
POST /token
grant_type=refresh_token&refresh_token=OLD_REFRESH_TOKEN

# Falls dies ein neues Token zurückgibt -> altes Token wurde nicht ungültig gemacht
# Ein Angreifer, der das alte Aktualisierungstoken gestohlen hat, kann weiterhin neue Zugriffstoken abrufen

---

Abschnitt 4: Szenarien zur Kontoübernahme

Test 4.1 — OAuth-Kontoverknüpfung ohne E-Mail-Verifizierung

Test 4.2 — Vorbereitete Kontoübernahme

# Angriffsszenario:
# 1. Angreifer erstellt ein Konto mit victim@example.com (bevor sich das Opfer registriert)
# 2. Angreifer verknüpft seinen OAuth-Anbieter mit dieser E-Mail-Adresse
# 3. Das Opfer registriert sich später über Google OAuth mit victim@example.com
# 4. Das Opfer erhält Zugriff auf das vorab erstellte Konto des Angreifers (oder umgekehrt)

# Testverfahren:
# 1. Konto mit der E-Mail-Adresse des Opfers registrieren (bevor es existiert)
# 2. OAuth mit einer anderen E-Mail-Adresse verbinden
# 3. Versuchen, auf das zukünftige Konto des Opfers zuzugreifen

Test 4.3 — Token-Fixierung

# Einige Implementierungen erlauben die Angabe von access_token in der Anfrage
# oder binden Token nicht ordnungsgemäß an Sitzungen

# Test: bekannten Token-Wert erzwingen
GET /oauth/callback?access_token=KNOWN_VALUE

# Falls die Anwendung dieses Token akzeptiert und verwendet -> Token-Fixierung

Test 4.4 — Verwechslung von sub- und email-Claims

# Falls eine Anwendung Konten anhand von email statt sub zuordnet:
# Bösartigen OAuth-Anbieter mit der E-Mail-Adresse des Opfers als 'email'-Claim registrieren
# Einige Anbieter erlauben das Festlegen beliebiger email-Claims

# Durch Erstellen eines benutzerdefinierten OAuth-Anbieters mit folgenden Werten testen:
{
  "sub": "attacker-unique-id",
  "email": "victim@example.com",
  "email_verified": true
}

---

Abschnitt 5: Schwachstellen des Autorisierungsservers

Test 5.1 — Schwache Client-Authentifizierung

# Vertrauliche Clients müssen sich mit client_secret authentifizieren
# Prüfen, ob client_secret optional ist:
POST /token
grant_type=authorization_code&
code=CODE&
client_id=CONFIDENTIAL_CLIENT_ID&
# Fehlt: client_secret
# Falls dies funktioniert -> Client-Authentifizierung wird nicht erzwungen

Test 5.2 — Missbrauch des Geräteautorisierungs-Flows

# Der Geräte-Flow (für Geräte mit eingeschränkten Eingabemöglichkeiten) kann für Phishing missbraucht werden
POST /device/code
client_id=LEGITIMATE_CLIENT

# Gibt einen user_code zurück, den das Opfer unter verification_uri eingibt
# Der Angreifer nutzt dies für Social Engineering:
# „Geben Sie den Code XXXX-XXXX unter accounts.target.com/activate ein“

---

Vollständige Checkliste für OAuth-Tests

---

Praxisbeispiele für OAuth-Sicherheitslücken

Fehlertyp	Plattform	Auswirkung	Prämie
Umgehung von redirect_uri	Facebook	Kontoübernahme	5,000
Fehlender state-Parameter	Airbnb	CSRF → Kontoübernahme	$8,000
Wiederverwendung von Codes	Microsoft	Replay-Angriff	5,000
JWT-None-Algorithmus	Auth0	Umgehung der Authentifizierung	0,000
Kontoübernahme durch E-Mail-Verwechslung	Slack	Kontoübernahme	0,000
PKCE nicht erzwungen	Mehrere	Abfangen von Codes	$5,000+

---

Testwerkzeuge

• Burp Suite — OAuth-Flows abfangen und verändern; die OAuth-Erweiterung verwenden
• jwt_tool — Umfassende JWT-Tests (Algorithmusverwechslung, Scans)
• oidcscan — Automatisierter Schwachstellenscanner für OpenID Connect
• OAuth2 Proxy — Zum Einrichten von Testumgebungen
• Postman — Token-Austausch-Flows mit einfacher Parameteränderung testen