Entra ID Redirect URI Hijacking: Wildcard-Antwort-URLs und der Implicit Flow

Was ist Entra ID Redirect URI Hijacking

Eine Entra ID Redirect URI – in der Microsoft-Dokumentation auch Antwort-URL genannt – ist der Endpunkt, an den die Microsoft Identity Platform einen Benutzer zusammen mit einem Token oder einem Autorisierungscode weiterleitet, nachdem er sich angemeldet und zugestimmt hat. Jede App-Registrierung, die den OAuth-2.0-Autorisierungscode-Flow, den Implicit-Grant-Flow oder OpenID Connect verwendet, muss ihre exakten Redirect-URIs vorab hinterlegen; Entra ID leitet nirgendwo anders hin um und liefert AADSTS50011, wenn der Wert in der Anmeldeanfrage nicht mit einem hinterlegten Wert übereinstimmt.

Dieser Abgleich ist die gesamte Sicherheitsgrenze. Drei Konfigurationsentscheidungen auf ein und derselben App-Registrierung schwächen sie so weit, dass ein Angreifer mit einem echten Token davonkommt statt die legitime App zu erreichen:

• Wildcard-Antwort-URLs (APP_REPLY_URL_WILDCARD) – ein Muster wie https://*.contoso.com statt einer exakten URL.
• HTTP-Antwort-URLs (APP_REPLY_URL_HTTP) – eine Redirect-URI, die nicht auf https beschränkt ist.
• Implicit Grant aktiviert (APP_IMPLICIT_GRANT_ENABLED) – die App-Registrierung lässt Entra ID weiterhin ein Zugriffs- oder ID-Token direkt im Browser zurückgeben, statt über einen Backchannel-Token-Austausch.

Jede dieser Einstellungen ist für sich allein High severity im EtcSec-Katalog. Kombiniert auf derselben App verwandeln sie einen einzelnen Phishing-Link in einen funktionierenden Weg zur Token-Exfiltration – und stehen neben anderen Risiken bei App-Registrierungen, die EtcSec verfolgt, etwa übermäßig privilegierten App-Registrierungen, veralteten Zugangsdaten und gefährlichen Graph-API-Berechtigungen.

Wie es funktioniert

Exakter Abgleich ist der Punkt, Wildcards hebeln ihn aus

Entra ID verlangt, dass Redirect-URIs mit https beginnen, mit einer engen Ausnahme für localhost während der lokalen Entwicklung – http://localhost/myapp ist gültig, http://contoso.com/callback nicht. Wildcards sind eine separate, optionale Lockerung der Abgleichsregel, nicht der Schema-Regel: Eine App-Registrierung, die nur für Konten mit Arbeits- oder Schulkonto vorgesehen ist, kann über den Manifest-Editor https://*.contoso.com registrieren und Entra ID dazu bringen, jede passende Subdomain als autorisiert zu behandeln. Microsofts eigene Best Practices und Einschränkungen für Redirect-URIs raten ausdrücklich davon ab: Nach RFC 6749 Abschnitt 3.1.2 muss ein Redirection-Endpunkt eine absolute URI sein, und wenn ein Wildcard-Eintrag zutrifft, entfernt Entra den Query-String und das Fragment aus dem Redirect – genau dort würde auch ein Implicit-Flow-Token mitreisen.

RFC 9700, die OAuth-2.0-Security-Best-Current-Practice der IETF, geht über ein bloßes „vermeiden" hinaus: Sie verlangt von Autorisierungsservern exaktes String-Matching für Redirect-URIs, mit der einzigen Ausnahme der Portnummer bei localhost-URIs nativer Apps. Die Begründung ist konkret – naive Wildcard-Implementierungen haben Angreifern erlaubt, etwas wie attacker.example/.somesite.example zu registrieren und einen Substring-Abgleich zu bestehen, und selbst eine korrekte Wildcard-Behandlung lässt Subdomain-Takeover als real gangbaren Weg übrig: Jede Subdomain, die ein Angreifer aufsetzen kann – ein verwaistes CNAME, ein vergessener Dev-Host – wird in dem Moment zu einem gültigen Redirect-Ziel, in dem sie auf das Muster passt.

Der Implicit Grant übergibt das Token an jeden, der die URL besitzt

Der Autorisierungscode-Flow hält den Token-Austausch auf einem Backchannel: Der Browser sieht nur einen kurzlebigen Code, den die App anschließend Server-zu-Server gegen ein Token eintauscht. Der Implicit Grant überspringt diesen Schritt – Entra ID gibt das Zugriffs- oder ID-Token direkt in der /authorize-Antwort zurück, angehängt an das Fragment der Redirect-URI. Dieses Verhalten wird pro App-Registrierung über zwei Microsoft-Graph-Eigenschaften der web-Ressource der Anwendung gesteuert: implicitGrantSettings.enableIdTokenIssuance und implicitGrantSettings.enableAccessTokenIssuance. Ist eine der beiden true, kann die App einen token- oder id_token-Response-Type anfordern und ein Token ganz ohne serverseitigen Austausch zurückerhalten.

RFC 9700 Abschnitt 2.1.2 ist unmissverständlich in Bezug auf die Konsequenz: Clients „SHOULD NOT use the implicit grant … unless access token injection in the authorization response is prevented and the aforementioned token leakage vectors are mitigated." Die dort aufgeführten Leckage-Vektoren sind unspektakulär, aber real – ein Token in einem URL-Fragment kann in der Browser-Historie landen, bei Weiterleitungen vom User-Agent erneut angehängt werden oder über einen Referer-Header an eine Drittseite durchsickern, auf die die tokenführende Seite zufällig verlinkt. Hinzu kommt: Ein Implicit-Flow-Token hat keine Sender-Bindung – nichts bindet es an den Client, für den es ausgestellt wurde, also ist eine Kopie so gut wie das Original. Microsofts eigene Dokumentation zum Implicit-Grant-Flow ist aus einem anderen Blickwinkel zum selben Schluss gekommen – Browser, die Third-Party-Cookies blockieren, haben den stillen Renewal-Schritt des Flows kaputt gemacht – und rät Entwicklern inzwischen ausdrücklich davon ab, verweist auf RFC 9700 Abschnitt 2.1.2 und empfiehlt die Migration zum Autorisierungscode-Flow.

Die Angriffskette

Schritt 1 — Ein passendes Redirect-Ziel finden oder übernehmen

Trägt die Ziel-App-Registrierung APP_REPLY_URL_WILDCARD – etwa https://*.contoso.com/auth –, muss der Angreifer nicht die primäre Domain kompromittieren. Jede Subdomain, die aufgelöst wird, einschließlich einer aus einer verwaisten Dev-Umgebung oder einem DNS-Eintrag, der von einem stillgelegten Dienst übrig blieb, passt auf das Muster und wird zu einem legitim aussehenden Redirect-Ziel für Entra ID.

Schritt 2 — Ein Token statt eines Codes anfordern

Mit APP_IMPLICIT_GRANT_ENABLED auf der App baut der Angreifer eine Anmelde-URL gegen die echte client_id mit response_type=token (oder id_token token) und einer redirect_uri, die auf seinen passenden Endpunkt gesetzt ist, und verschickt sie als Phishing-Link. Das Opfer authentifiziert sich auf der echten Entra-ID-Anmeldeseite – es gibt kein gefälschtes Login-Formular zu erkennen –, und Entra ID leitet den Browser mit dem angehängten Token zurück zum Endpunkt des Angreifers.

Schritt 3 — Das Token im Klartext abfangen

Ist zusätzlich APP_REPLY_URL_HTTP vorhanden, oder protokolliert der vom Angreifer kontrollierte Endpunkt einfach, was er empfängt, kann das mit der URL mitreisende Token direkt abgefangen, von einem Proxy protokolliert oder über die von RFC 9700 dokumentierten Leckage-Vektoren offengelegt werden – Browser-Historie, Referer-Header bei ausgehenden Links von der Landingpage, oder erneutes Anhängen bei einer weiteren Weiterleitung.

Schritt 4 — Das Token ohne Client-Secret wiederverwenden

Weil der Implicit Grant ein Bearer-Token ohne Sender-Bindung ausstellt, verwendet der Angreifer es direkt gegen Microsoft Graph oder die Ressource, für die es vorgesehen war, als das Opfer, solange es gültig bleibt. In diesem Flow gibt es kein Refresh-Token, daher ist das Zeitfenster durch die Lebensdauer des Access-Tokens begrenzt – aber zwischen Abfangen und Wiederverwendung steht sonst nichts. Das ist ein anderer Mechanismus als OAuth-Consent-Phishing, das einen Benutzer dazu verleitet, eine bösartige App zu autorisieren, statt ein für eine legitime App bestimmtes Token abzufangen – aber beide enden damit, dass ein Angreifer eine gültige Anmeldeinformation für Ihren Tenant in der Hand hält.

Erkennung

Redirect-URI-Konfiguration und Implicit-Grant-Einstellungen liegen im Anwendungsobjekt, nicht in Sign-in-Aktivitätsprotokollen – das ist also eine Bestandsprüfung gegen Microsoft Graph, keine SIEM-Abfrage:

Im Microsoft Entra Admin Center ist dieselbe Information pro App unter App-Registrierungen → [App] → Authentifizierung sichtbar: die Redirect-URI-Liste der Plattform Web, und die Kontrollkästchen Implicit Grant und Hybridflows für ID-Token und Zugriffstoken.

Remediation

1. Wildcard-Redirect-URIs durch exakte, absolute URIs ersetzen. Jeden echten Callback-Endpunkt einzeln auflisten statt eines Musters. Wird die Zahl der Subdomains dadurch unhandlich, dokumentiert Microsoft eine Alternative mit State-Parameter: eine einzige gemeinsame, CSRF-geschützte Redirect-URI plus ein app-spezifischer state-Wert statt eines Wildcard-Abgleichs.
2. Jede nicht-localhost-http://-Redirect-URI entfernen. Entra ID lehnt neue nicht-https-Einträge außerhalb von localhost bereits ab, aber ältere App-Registrierungen können noch einen Eintrag aus der Zeit vor dieser Einschränkung tragen; web.redirectUris direkt prüfen, statt anzunehmen, das Admin Center hätte das bei der Erstellung blockiert.
3. Implicit Grant deaktivieren. Sowohl implicitGrantSettings.enableIdTokenIssuance als auch enableAccessTokenIssuance auf false setzen (oder die beiden Kontrollkästchen im Portal deaktivieren), außer eine Legacy-Integration hängt ausdrücklich davon ab.
4. Zum Autorisierungscode-Flow mit PKCE migrieren. RFC 9700 Abschnitt 2.1.1 verlangt PKCE für öffentliche Clients und empfiehlt es für vertrauliche Clients; Microsofts MSAL-Bibliotheken implementieren den Code-Austausch und die PKCE-Challenge bereits, das ist also meist ein Bibliothekswechsel statt eines Protokoll-Implementierungsprojekts.
5. Die Plattform nach der Migration erneut prüfen. Eine Single-Page-App, die weiterhin einen reinen Browser-Flow benötigt, sollte zum Autorisierungscode-Flow mit PKCE auf der Plattform SPA wechseln, nicht auf Web mit aktiviertem Implicit Grant bleiben.

Wie EtcSec das erkennt

EtcSec liest bei jedem Azure-Audit über Microsoft Graph die web.redirectUris und web.implicitGrantSettings jeder App-Registrierung und meldet APP_REPLY_URL_WILDCARD für jeden Wildcard-Eintrag, APP_REPLY_URL_HTTP für jeden nicht-localhost-http://-Eintrag und APP_IMPLICIT_GRANT_ENABLED, wenn eines der beiden Implicit-Grant-Flags true ist – alle drei beschränkt auf die Plattform Web, wie oben angemerkt. Diese Gruppe ist Teil einer umfassenderen Prüfung; den vollständigen Katalog über App-Registrierungen hinaus finden Sie in unserem praktischen Leitfaden zur Prüfung der Microsoft Entra ID-Sicherheit.