Offene Weiterleitungen: prüfen, wohin ein next-Parameter führen darf

Worum es geht

Login-Seiten, Logout-Handler, Sprachumschalter und OAuth-Callbacks nehmen häufig einen Parameter next, returnUrl oder redirect entgegen und schicken den Browser danach dorthin. Ungeprüft verwendet, ist https://example.org/login?next=https://evil.example/ ein Link auf der eigenen Domain, der auf der Seite des Angreifers endet; das OWASP Cheat Sheet merkt an, dass der Phishing-Versuch vertrauenswürdiger wirkt, weil der Servername im Link der vertrauenswürdige ist. Das Cheat Sheet behandelt auch Forwards: Ein serverseitiger Dispatch zu einem aus der Anfrage entnommenen Pfad kann die Zugriffskontrolle umgehen.

Warum es wichtig ist

Offene Weiterleitungen sind für sich genommen von begrenztem Nutzen, aber ein Baustein: Sie leihen Phishing-Mails die Reputation der eigenen Domain, RFC 9700 beschreibt, wie ein offener Redirector bei einem Client dazu genutzt werden kann, Autorisierungscodes und Tokens abfliessen zu lassen, und sie hebeln Regeln wie „nur Links auf unsere Domain“ in Mailfiltern und Content-Richtlinien aus.

So wird es angewendet

• Am besten gar kein vom Nutzer geliefertes Ziel verwenden: den vorgesehenen Rücksprungort in der Session halten oder eine kurze Kennung serverseitig auf eine URL abbilden (die ersten Empfehlungen des Cheat Sheets), dabei auf das Durchzählen von Kennungen achten.
• Muss eine URL akzeptiert werden, eine Positivliste verwenden, die das Cheat Sheet einer Negativliste vorzieht: nur relative Pfade akzeptieren, die mit einem einzelnen / beginnen (//host, /\host und alles mit einem Schema ablehnen), oder sie parsen und Schema und Host mit einer expliziten Liste erlaubter Ursprünge vergleichen.
• Mit dem URL-Parser der Plattform parsen und dann die Teile validieren. Die Python-Dokumentation hält fest, dass urlsplit() und urlparse() die Eingabe nicht validieren, statt einer Exception auch leere Komponenten zurückgeben können, und dass Code mit sicherheitsrelevanten Auswirkungen prüfen sollte, ob Schema, Host und Pfad sinnvoll sind, bevor er ihnen vertraut.
• Vor dem Vergleich normalisieren: Prozent-Encoding einmal dekodieren, den Host in Kleinbuchstaben umwandeln, Leerraum und Steuerzeichen entfernen, Userinfo-Formen (user@host) ablehnen.
• In OAuth-Abläufen redirect_uri durch exakten Abgleich mit registrierten Werten vergleichen, nicht per Präfix oder Muster: RFC 9700 rät zu exaktem Abgleich der Redirection-URI und hält fest, dass Webserver, die Redirection-URIs hosten, keine offenen Redirectors bereitstellen dürfen.
• Eine Testliste von Umgehungsmustern führen (//evil.example, https:evil.example, /\evil.example, https://example.org.evil.example, https://example.org@evil.example) und für jedes prüfen, dass es abgelehnt wird.

Stolpersteine

Eine Prüfung mit startswith("https://example.org"): Sie passt auch auf https://example.org.evil.example. Vor dem Dekodieren validieren und erst danach weiterleiten. Jede Subdomain erlauben, wenn eine Subdomain Nutzerinhalte hostet. Der Parser des Validators und der Parser des Browsers können sich unterscheiden: Die Python-Dokumentation merkt an, dass ihre Funktionen Aspekte sowohl des WHATWG URL Standard als auch von RFC 3986 aufgreifen, ohne mit einem der beiden vollständig übereinzustimmen – daher testen, was der Browser mit dem akzeptierten Wert macht, nicht nur, was der Server damit meint.