Ihr SSO-Login-Callback hat einen Open Redirect (er leitet zu jeder in einem Parameter übergebenen URL weiter). Was ist das Risiko?
Kurzantwort
Ein Open Redirect in einem Authentifizierungsfluss erlaubt einem Angreifer, einen vertrauenswürdig wirkenden Login-Link zu basteln, der den Benutzer nach der Authentifizierung — und möglicherweise einen Autorisierungscode oder ein Token — an eine vom Angreifer kontrollierte Domain sendet und so Kontoübernahme und überzeugendes Phishing ermöglicht. Beheben Sie es, indem Sie exakte Redirect-URIs serverseitig streng per Allow-List freigeben und alles andere ablehnen. Es ist weder kosmetisch noch ein Performance-Problem, und HTTPS hilft nicht, weil das Ziel des Angreifers ebenfalls eine gültige HTTPS-Site sein kann.
Ein Open Redirect wird oft als geringfügig abgetan — bis er auf einem Authentifizierungs-Callback sitzt. Dort ist er kein Phishing-Ärgernis mehr, sondern ein Weg zur Kontoübernahme, denn das, was weitergeleitet wird, kann Anmeldedaten, einen Autorisierungscode oder ein Token transportieren.
Warum das Risiko hoch ist
In einem SSO/OAuth-Fluss authentifiziert sich der Benutzer, und der Provider schickt ihn an Ihren Callback zurück, der ihn dann weiterleitet. Ist dieses Weiterleitungsziel vom Angreifer kontrolliert (weil der Redirect-Parameter nicht validiert wird), passieren zwei schlimme Dinge:
- Phishing mit einer echten, vertrauenswürdigen Domain. Der bösartige Link startet bei Ihrer legitimen Login-URL, besteht also die „Ist das die echte Site?"-Prüfung des Benutzers und leitet ihn dann auf die Angreiferseite, um Anmeldedaten oder Zustimmung abzuernten.
- Token-/Code-Diebstahl. Reist der Autorisierungscode oder das Token durch die Weiterleitung (in der URL oder per Referer-/Fragment-Leck), erhält die Angreiferdomain ihn und kann ihn einlösen oder erneut abspielen, um das Konto zu übernehmen.
Die richtige Lösung
Geben Sie Redirect-URIs serverseitig streng per Allow-List frei, im Abgleich gegen einen exakten, vorab registrierten Satz von Werten — kein Präfix, kein Teilstring, keine „gleiche Domain"-Prüfung, die Angreifer alle umgehen (https://ihreseite.com.evil.com, //evil.com, Pfad-Tricks). Lehnen Sie alles ab, was nicht auf der Liste steht. Kombinieren Sie dies mit dem OAuth-state-Parameter (CSRF-Schutz) und PKCE, um den Fluss durchgängig zu härten.
Warum die anderen Antworten falsch sind
- „Rein kosmetisch" und „etwas langsamere Logins" schätzen die Schwere völlig falsch ein — der Fehler kann genau das Token durchlassen, das die Sitzung des Benutzers ist.
- „Kein Risiko, solange die Site HTTPS verwendet" missversteht die Bedrohung: HTTPS schützt die Verbindung, aber der Angreifer hostet seine Landeseite einfach auf seiner eigenen gültigen HTTPS-Site. Transportverschlüsselung tut nichts, um eine Weiterleitung auf ein bösartiges Ziel zu stoppen.
Der Interviewer ergründet, ob Sie erkennen, dass ein Open Redirect auf einem Auth-Pfad eine Primitive für Anmeldedatendiebstahl ist, und ob Sie zur Allow-List mit exakter Übereinstimmung greifen statt zu einem cleveren, aber umgehbaren Filter.
Wahrscheinliche Anschlussfragen
- Wie wird aus einem Open Redirect in einer OAuth-redirect_uri ein Diebstahl des Autorisierungscodes?
- Warum ist eine Allow-List mit exakter Übereinstimmung sicherer als ein Präfix- oder Domain-Abgleich?
- Welche Rolle spielen der state-Parameter und PKCE neben der redirect_uri-Validierung?