OAuth-Schwachstellen und Angriffsmuster

OAuth-Authorization-Server müssen den Parameter redirect_uri strikt validieren. Wenn der Server Präfix- oder Wildcard-Matching zulässt (z. B. jede URL akzeptiert, die mit "https://app.example.com" beginnt), kann ein Angreifer eine Autorisierungsanfrage erstellen, die zu "https://app.example.com.attacker.com/steal" oder zu einem Open Redirect auf der legitimen Domain weiterleitet, und dadurch den Autorisierungscode stehlen.

Ohne CSRF-Schutz kann ein Angreifer einen OAuth-Flow initiieren und den Browser eines Opfers dazu bringen, die Autorisierung abzuschließen. Das Opfer autorisiert dadurch unbeabsichtigt den Client des Angreifers. Der Parameter "state" (RFC 6749) verhindert dies: Der Client erzeugt einen zufälligen State, fügt ihn in die Anfrage ein und überprüft im Callback, ob er übereinstimmt. Bei einer Abweichung wird der Flow abgebrochen.

Auf mobilen Plattformen können bösartige Apps dasselbe benutzerdefinierte URI-Schema wie ein legitimer OAuth-Client registrieren und nach der Benutzerauthentifizierung weitergeleitete Autorisierungscodes abfangen. PKCE (RFC 7636) bietet vollständigen Schutz: Der abgefangene Code ist ohne den Code-Verifier unbrauchbar, den nur die legitime App zu Beginn des Flows erzeugt hat.

Wenn ein ID-Token oder Access-Token in einem URL-Fragment oder einem Query-Parameter enthalten ist, wird die URL bei anschließenden Navigationen von dieser Seite im Referer-Header übertragen. Dadurch kann das Token an Analyse-Skripte oder CDN-Anbieter von Drittanbietern gelangen. Verwenden Sie immer den Authorization Code Flow mit Token-Übertragung über den Backchannel, damit Tokens nicht in URLs erscheinen.

Wenn ein Client mehrere OAuth-Provider unterstützt, können Mix-Up-Angriffe den Client dazu bringen, einen von Provider A erhaltenen Autorisierungscode an den Token-Endpunkt von Provider B zu senden. Der Client muss den Claim "iss" in ID-Tokens validieren und den Callback an den jeweiligen Provider binden, der den Flow initiiert hat. Verwenden Sie dazu den State-Parameter oder JARM (JWT-Secured Authorization Response Mode).

Server-Side Request Forgery (SSRF) zielt auf OAuth-Implementierungen ab, die serverseitige HTTP-Anfragen an die redirect_uri senden. Wenn der Authorization Server die redirect_uri zur Überprüfung abruft, kann ein Angreifer eine interne IP-Adresse (z. B. http://169.254.169.254/latest/meta-data/) angeben, um auf Metadaten der Cloud-Instanz oder interne Dienste zuzugreifen. Eine strikte Validierung der redirect_uri anhand einer Allowlist verhindert dies.

Viele Anwendungen verwenden den E-Mail-Claim aus einem OIDC-ID-Token, um Konten bei verschiedenen Providern zu verknüpfen. Wenn ein Angreifer eine E-Mail-Adresse kontrolliert, die dem Konto eines Opfers bei einem anderen Provider entspricht, kann er sich bei einem anderen Provider mit dieser E-Mail-Adresse registrieren und Zugriff auf das Konto des Opfers erlangen. Schutzmaßnahme: Verknüpfen Sie Konten ausschließlich anhand des Paars (iss, sub), niemals anhand der E-Mail-Adresse allein.

Angriffe durch Verwechslung von JWT-Algorithmen nutzen Implementierungen aus, die dem "alg"-Header vertrauen, um den Prüfalgorithmus auszuwählen. Angriff: Ändern Sie "alg" von "RS256" in "HS256" und signieren Sie das Token mit dem öffentlichen Schlüssel des Servers als HMAC-Secret (da der öffentliche Schlüssel öffentlich ist). Schutzmaßnahme: Geben Sie im Prüfcode immer den erwarteten Algorithmus explizit vor und vertrauen Sie niemals dem alg-Claim im Token-Header.

Angreifer registrieren bösartige OAuth-Clients mit Namen und Logos, die vertrauenswürdig wirken, und senden anschließend Phishing-Links an ihre Ziele. Das Opfer sieht einen echten OAuth-Zustimmungsbildschirm (gehostet von Google, Microsoft usw.) für eine bösartige Anwendung und gewährt ihr Zugriff. Schutzmaßnahme: Überprüfen Sie, ob die client_id der erwarteten Anwendung entspricht. Google und Microsoft bieten Programme zur Client-Verifizierung für legitime Apps an.

Eine Scope-Ausweitung tritt auf, wenn ein Client Tokens mit umfassenderen Berechtigungen erhält, als der Benutzer autorisiert hat. Implementierungsfehler, die die Scope-Validierung am Token-Endpunkt überspringen, Tokens mit zusammengeführten Scopes aus verschiedenen Anfragen zwischenspeichern oder nicht prüfen, dass der Scope im ausgestellten Token den autorisierten Scope nicht überschreitet, können alle zu einer Rechteausweitung über OAuth führen.

Schützen Sie OAuth-Implementierungen, indem Sie redirect_uri exakt abgleichen, PKCE für alle öffentlichen Clients verlangen, den state-Parameter zum CSRF-Schutz validieren, ID-Tokens anhand von (iss, sub) statt anhand der E-Mail-Adresse binden, die erwarteten JWT-Algorithmen explizit festlegen, minimale Scopes anfordern, kurzlebige Access-Tokens mit Refresh-Token-Rotation verwenden und das Erscheinungsbild von Zustimmungsbildschirmen auf das Risiko einer Markenimitation prüfen.

Wichtige OAuth-Angriffe: Open Redirect durch nachlässige redirect_uri-Validierung (exakten Abgleich verwenden), CSRF durch einen fehlenden state-Parameter, Abfangen von Codes auf Mobilgeräten (durch PKCE eingedämmt), Token-Leakage in URLs, Mix-Up-Angriffe bei mehreren Providern (iss validieren), SSRF durch serverseitig abgerufene redirect_uri, Kollisionen von E-Mail-Claims (iss+sub verwenden), Verwechslung von JWT-Algorithmen (erwarteten alg festlegen) und Phishing durch gefälschte Zustimmungsbildschirme.