Ein Open Redirect ist jede Seite Ihrer Website, die den Browser des Besuchers auf eine URL weiterleitet, die aus einer Benutzereingabe stammt und nicht geprüft wird. Das wirkt harmlos. In der Praxis erlaubt es Angreifern jedoch, einen Phishing-Link zu versenden, der Ihre echte Domain anzeigt. In einem OAuth-Setup kann es zudem Authorization Codes und Access Tokens preisgeben.
Warum eine Weiterleitung mehr als ein kosmetischer Fehler ist
CWE-601 beschreibt die Schwachstelle so: Eine Webanwendung akzeptiert benutzerkontrollierte Eingaben, die einen Link auf eine externe Seite festlegen, und verwendet diesen Link anschließend in einer Weiterleitung. Das Opfer folgt einem Link auf Ihre vertrauenswürdige Website und landet auf einer Seite, die der Angreifer kontrolliert. Das OWASP Cheat Sheet zeigt die typische Form:
http://example.com/example.php?url=http://malicious.example.comDer Servername im manipulierten Link ist mit dem der ursprünglichen Website identisch, wodurch der Phishing-Versuch glaubwürdiger wirkt. Die Perspektive der Nutzer behandelt unser Link-Checker.
Bei OAuth reicht dieselbe Schwachstelle noch weiter. RFC 9700 legt fest, dass Clients und Authorization Server keine URLs bereitstellen DÜRFEN, die den Browser auf beliebige, aus einem Query-Parameter entnommene URIs weiterleiten, weil Open Redirectors die Exfiltration von Authorization Codes und Access Tokens ermöglichen können.
Forwards sind ein verwandter Fall. Wählt eine Benutzereingabe ein internes Ziel aus, etwa in function.jsp?fwd=admin.jsp, kann eine manipulierte URL die Zugriffskontrolle umgehen und eine administrative Funktion erreichen. Die Anwendung muss prüfen, ob der Benutzer für das Ziel autorisiert ist.
Die Parameter finden
Die Namen variieren: url, fwd und returnUrl tauchen in den OWASP-Beispielen auf, Ihr Code enthält vermutlich weitere. Suchen Sie nach dem Muster, nicht nach dem Namen.
| Stack | Gefährliches Muster |
|---|---|
| Java | response.sendRedirect(request.getParameter("url")) |
| PHP | header("Location: " . $redirect_url) mit $_GET['url'] |
| C# .NET | Response.Redirect(url) mit request.QueryString["url"] |
| Rails | redirect_to params[:url] |
| Java Forward | getRequestDispatcher(fwd).forward(...) |
Ein erster Durchlauf mit grep liefert Ihnen eine Liste zum Durchsehen. Passen Sie Pfad und Dateitypen an Ihr Repository an.
grep -rnE 'sendRedirect\(|Redirect\(|redirect_to params|header::LOCATION' src/
grep -rn -A3 'header(.Location' src/Der zweite Befehl ist für PHP gedacht. Lesen Sie die Zeilen nach jedem Treffer: Fehlt nach header("Location... ein exit, läuft der Rest des Skripts weiter. Ein Browser, der die Weiterleitung ignoriert, zeigt dann unter Umständen den Rest der Seite an.
.NET-Teams sollten zuerst die Login-Actions prüfen. Laut Cheat Sheet sind ASP.NET-MVC-1- und -2-Websites besonders anfällig, und das dortige MVC-2-Beispiel LogOn leitet ohne jede Validierung auf returnUrl weiter. Die empfohlene Lösung ist der Wechsel auf MVC 3.
Die meisten Treffer sind harmlos. Bei jeder Weiterleitung, deren Argument weder ein String-Literal noch ein serverseitiger Lookup ist, stellen Sie eine Frage: Woher stammt der Wert? Cookies, versteckte Formularfelder, Header und Datenbankinhalte zählen alle dazu. Viele Open Redirects entstehen, weil Entwickler davon ausgingen, ein Cookie oder ein verstecktes Feld ließe sich nicht verändern.
Um einen Fund zu bestätigen, belassen Sie es nicht bei einer einzelnen externen Adresse. Senden Sie jede der folgenden Eingaben im Parameter und beobachten Sie den Location-Header:
http://malicious.example.comhttps://yoursite.example@malicious.example(Userinfo:yoursite.examplewird zum Benutzernamen)https://yoursite.example.malicious.example(ein Hostname, der mit Ihrem beginnt)https://malicious-yoursite.example(ein Hostname, der mit Ihrem endet)
Das Cheat Sheet nennt Userinfo und irreführende Hostnamen als Wege, Präfix- und Suffix-Prüfungen zu umgehen. Passiert eine dieser Eingaben die Prüfung, obwohl die einfache URL blockiert wurde, handelt es sich wahrscheinlich um einen String-Vergleich. Das ist eine Schlussfolgerung, kein Beweis, aber ersetzen Sie die Prüfung in jedem Fall.
Scanner finden einige dieser Fälle. Der OWASP Web Security Testing Guide weist darauf hin, dass solche Tools generisch sind und ihnen der anwendungsspezifische Kontext fehlt. Verifizieren Sie deshalb jeden Fund manuell.
Beheben, nach Priorität geordnet
- Nicht auf Basis von Benutzereingaben weiterleiten. Ist das Ziel im Code fest hinterlegt, kann ein Angreifer es nicht ändern.
- IDs serverseitig auf Ziele abbilden. Der Benutzer liefert einen kurzen Namen oder eine ID, der Server schlägt die vollständige URL nach und weist alles andere ab. Stellen Sie sicher, dass sich die IDs nicht durchprobieren lassen, sonst kann ein Besucher alle Ziele enumerieren.
- Für lokale Rücksprünge den Framework-Helper nutzen. In ASP.NET Core sind das
LocalRedirectoderIsLocalUrl, die nicht lokale Ziele ablehnen. - Externe Ziele per Allowlist freigeben. Verwenden Sie einen gepflegten URL-Parser und vergleichen Sie das geparste Schema, den kanonischen Host und den effektiven Port mit einer expliziten Liste. Schränken Sie den Pfad ein, wenn nur bestimmte Endpunkte erlaubt sind.
- Optional einen Nonce verlangen. CWE beschreibt einen unvorhersehbaren, von der Anwendung erzeugten Nonce bei jeder Redirect-Anfrage, wobei Anfragen ohne Nonce abgelehnt werden. XSS kann ihn umgehen, er ergänzt also eine Lösung, ersetzt sie aber nicht.
Regeln für die Allowlist-Prüfung:
- Userinfo und mehrdeutige Eingaben ablehnen.
- Mit der validierten URL weiterleiten, nicht mit einer Version, die Sie anschließend noch umformen.
- Niemals rohe Präfix- oder Suffix-Vergleiche verwenden. Das Cheat Sheet nennt GitLab als Fall, in dem Userinfo und irreführende Hostnamen solche Prüfungen ausgehebelt haben.
Eine Denylist schlechter Werte ist als primäre Verteidigung schwach, auch wenn CWE sie zur Erkennung von Angriffen gelten lässt. Setzen Sie stattdessen auf "accept known good".
Müssen Nutzer Ihre Website verlassen, bietet eine Zwischenseite, die das Ziel nennt und einen Klick verlangt, eine zusätzliche Schutzschicht. Vermeiden Sie beim Bau dieser Seite XSS.
Die OAuth-Seite
RFC 9700 verlangt, dass Authorization Server die Redirection-URIs der Clients per exaktem String-Vergleich mit den vorab registrierten abgleichen, mit Ausnahme der Portnummern bei localhost-Redirection-URIs nativer Apps. Meine Lesart, kein RFC-Text: Der exakte Vergleich belegt, dass der Callback der registrierte ist. Stellt der registrierte Host aber zugleich einen Open Redirector bereit, kann der Code weiterwandern. Für Details verweist der RFC auf seinen Abschnitt 4.11. Lesen Sie ihn, bevor Sie sich auf meine Zusammenfassung verlassen.
Wo Sie anfangen
- Lassen Sie die grep-Muster von oben über Ihren Code laufen und listen Sie jede Weiterleitung und jeden Forward auf, dessen Ziel aus einer Anfrage, einem Cookie oder einem gespeicherten Wert stammt. Prüfen Sie zuerst die Login- und OAuth-Callback-Handler.
- Prüfen Sie PHP-Treffer auf ein fehlendes
exitund .NET-Projekte auf Login-Actions in MVC 1 oder 2. - Testen Sie jeden Treffer mit den vier Eingaben oben, einschließlich der Userinfo-Form, und halten Sie fest, welche den Browser von Ihrer Domain wegschicken.
- Ersetzen Sie vom Benutzer gelieferte URLs, wo möglich, durch serverseitiges ID-Mapping, nutzen Sie für Rücksprungadressen reine Local-Helper des Frameworks und für die wenigen nötigen externen Ziele eine Allowlist auf Basis geparster URLs.
- Prüfen Sie Ihre OAuth-Client-Registrierungen auf exakte Redirect-URIs und stellen Sie sicher, dass keiner Ihrer Hosts einen Open Redirector bereitstellt.
- Nehmen Sie einen Redirect-Test in Code-Reviews und in den Umfang Ihrer Penetrationstests auf, damit der Fehler nicht zurückkehrt.
