Teil 9 – Weitere Schwachstellen und OAuth 2.1

Sep. 14, 2025

—

von

Warum wir über den Tellerrand schauen müssen

In den letzten Teilen haben wir uns große Themen wie Token-Diebstahl, CSRF und den unsicheren Implicit Flow angesehen. Aber die Welt von OAuth ist noch breiter: Es gibt eine ganze Reihe weiterer Schwachstellen, die in der Praxis auftauchen. Gleichzeitig arbeitet die Community an Verbesserungen – und das Ergebnis ist OAuth 2.1.

Weitere typische Schwachstellen

1. Offene Redirect-URIs

Wir haben dieses Problem schon angeschnitten:

Wenn ein Autorisierungs-Server nicht streng prüft, welche Redirect-URIs erlaubt sind, können Angreifer die Nutzer auf ihre eigene Domain umleiten.
Ergebnis: Der Autorisierungscode oder das Access Token landet beim Angreifer.

👉 Praxis: Viele reale Exploits beginnen mit einem simplen offenen Redirect.

2. Scope-Manipulation

Scopes sollen fein regeln, was eine App darf. Doch:

Manche Implementierungen überprüfen nicht, ob die App wirklich nur die erlaubten Scopes anfragt.
Beispiel: Eine App sollte nur read:profile bekommen, fragt aber read:profile write:profile.
Wenn der Server es zulässt, kann die App plötzlich Daten ändern statt nur lesen.

3. Unsichere Refresh Tokens

Refresh Tokens sind mächtig, weil sie neuen Zugriff gewähren, ohne dass der Benutzer erneut zustimmen muss. Probleme entstehen, wenn:

Refresh Tokens im Browser gespeichert werden.
Sie kein Ablaufdatum haben.
Sie nicht widerrufen werden können.

👉 In der Praxis bedeutet ein gestohlenes Refresh Token oft dauerhaften Account-Zugriff.

4. Falsche Token-Validierung

Manche Anwendungen prüfen Tokens nicht korrekt:

Access Tokens werden nicht auf Gültigkeit oder Aussteller geprüft.
JWTs werden nicht signiert oder die Signatur wird ignoriert.
„aud“-Feld (Audience) wird nicht validiert → Token, das für App A gedacht war, wird bei App B akzeptiert.

👉 Solche Fehler sind brandgefährlich, weil sie direkt zu Missbrauch führen.

5. Insecure Default Configurations

Viele Frameworks bringen Standard-Setups mit, die unsicher sind:

Automatische Wildcards bei Redirect URIs.
Speicherung von Tokens im Local Storage.
Keine Aktivierung von PKCE.

👉 Entwickler vertrauen den Defaults – und bauen dadurch ungewollt Lücken ein.

6. „Mix-Up“-Attacks

Ein spezieller Angriff:

Nutzer verwendet mehrere OAuth-Provider (z. B. Google und Facebook).
Angreifer bringt die Anwendung dazu, ein Token vom falschen Provider zu akzeptieren.
Ergebnis: falsche Identitäten werden verknüpft.

7. Clickjacking im Consent-Screen

Wenn der Einwilligungsbildschirm (Consent-Screen) nicht geschützt ist, kann er in einem unsichtbaren iFrame eingebettet werden.

Angreifer bringt Nutzer dazu, unbewusst auf „Zulassen“ zu klicken.
Nutzer gibt der App Zugriff, ohne es zu merken.

Reale Folgen dieser Schwachstellen

Account Takeover: Tokens oder Codes werden abgefangen → Angreifer übernimmt Accounts.
Datenlecks: Zu breite Scopes oder falsche Validierung → Zugriff auf private Daten.
Missbrauch von APIs: Machine-to-Machine-Token gelangen in die falschen Hände.
Identitätsdiebstahl: Mix-Up-Attacken oder falsche Provider-Verknüpfungen.

Bug-Bounty-Programme zahlen für OAuth-Bugs oft hohe Summen, weil sie direkten Zugriff auf Accounts und sensible Daten erlauben.

Evolution: Warum OAuth 2.1 kam

Die Entwickler von OAuth haben erkannt, dass die vielen Optionen und Flexibilität von OAuth 2.0 auch die Hauptquelle für Fehler waren.

👉 Ziel von OAuth 2.1:

Den Standard vereinfachen.
Unsichere Flows abschaffen.
Klare Regeln für Entwickler schaffen.

Wichtige Änderungen in OAuth 2.1

1. Implicit Flow abgeschafft

Keine Tokens mehr in der URL.
Nur noch Authorization Code Flow (mit PKCE).

2. PKCE verpflichtend

Jeder Public Client muss PKCE nutzen.
Damit werden Code-Intercept-Angriffe verhindert.

3. Strengere Regeln für Redirect URIs

Nur noch exakte URIs erlaubt.
Keine Wildcards (*) oder dynamischen Parameter.

4. Kurzlebige Tokens

Empfehlung: Access Tokens nur wenige Minuten gültig.
Refresh Tokens nur mit zusätzlichen Schutzmechanismen.

5. Einheitliche Best Practices

OAuth 2.1 schreibt Best Practices vor, die bei 2.0 nur „empfohlen“ waren.

Zwingend HTTPS.
Kein Mix von Authorization und Authentication ohne OIDC.
Logging-Schutz für Tokens.

Verbindung zu OpenID Connect (OIDC)

Viele Entwickler nutzen OAuth als Login-System – was eigentlich nicht vorgesehen war.

👉 Lösung: OpenID Connect (OIDC)

Baut auf OAuth auf.
Liefert zusätzlich ein ID Token mit Benutzerinformationen.
Enthält Schutzmechanismen wie nonce gegen Replay-Angriffe.

OIDC ist heute der Standard, wenn es nicht nur um Autorisierung, sondern auch um Authentifizierung geht.

Die Zukunft: OAuth Beyond 2.1

OAuth entwickelt sich ständig weiter. Themen, die aktuell diskutiert werden:

Token Binding → Tokens an Geräte oder TLS-Verbindungen binden, um Diebstahl nutzlos zu machen.
DPoP (Demonstration of Proof-of-Possession) → Der Client muss beweisen, dass er wirklich Besitzer des Tokens ist.
Zero Trust-Ansätze → Tokens werden immer kürzer gültig, dafür dynamisch erneuert.