Was ist ein Open Redirect?

Ein Open Redirect entsteht, wenn eine Anwendung das Ziel einer Weiterleitung aus beeinflussbaren Eingaben übernimmt, ohne es auf einen zulässigen Ort zu beschränken. Ein Link auf der echten Unternehmensdomain kann Besucher dadurch unmittelbar zu einer fremden Website führen. Typische Parameter heißen next, returnUrl, continue oder redirect.

Wie funktioniert ein Open Redirect?

Nach Login oder Logout soll eine Anwendung zur vorherigen Seite zurückkehren. Übergibt der Client dafür eine vollständige URL, kann ein Angreifer seine eigene Domain einsetzen und den präparierten Link verbreiten. Der Browser ruft zunächst die legitime Seite auf und folgt dann einem HTTP-Redirect oder einer clientseitigen Weiterleitung. Varianten entstehen über JavaScript, Meta Refresh, Router, Fehlerseiten und mehrere verkettete Redirects.

Warum ist eine Weiterleitung sicherheitsrelevant?

Die gewöhnliche Weiterleitung kompromittiert den Server nicht direkt. Ihr Risiko hängt von Kontext, Reichweite der vertrauenswürdigen Domain und möglicher Verkettung ab. Eine Warnseite kann Nutzer informieren, behebt aber keine unsichere Zielauswahl.

Was ist bei OAuth und SSO anders?

OAuth und OpenID Connect nutzen registrierte Redirect URIs, an die der Autorisierungsserver nach der Anmeldung zurückleitet. Eine zu breite, per Präfix geprüfte oder selbst wiederum offene URI kann Autorisierungscodes oder Tokens an einen Angreiferpfad bringen. Diese Prüfung muss exakten Vorgaben des Protokolls und Providers folgen; ein allgemeiner Open Redirect innerhalb eines Clients kann die Kette verschärfen. Sensible Werte gehören außerdem nicht unnötig in URLs, Referrer oder Logs.

Warum scheitern einfache URL-Prüfungen?

Ein String kann mit https://firma.example beginnen und dennoch auf firma.example.attacker.tld zeigen. Andere Sonderfälle sind Benutzerinformationen vor @, Protokoll-relative URLs mit //, Backslashes, kodierte Trennzeichen, internationale Domainnamen, Ports, eingebettete URLs und mehrfache Dekodierung. Unterschiedliche Parser in Proxy, Framework und Browser können denselben Wert abweichend verstehen.

Wie werden Redirects sicher umgesetzt?

1. Feste Ziele bevorzugen: Eine kurze Kennung wie dashboard serverseitig auf eine bekannte interne Route abbilden.
2. Relative Pfade begrenzen: Nur Pfade der eigenen Anwendung erlauben und protokollrelative sowie absolute Werte ablehnen.
3. Komponenten parsen: Wenn externe Ziele nötig sind, Schema, normalisierten Host und Port exakt gegen eine kleine Positivliste prüfen.
4. Keine Header übernehmen: Host- und Proxy-Header nur aus vertrauenswürdiger Infrastruktur zur URL-Erzeugung verwenden.
5. Authentifizierungsziele fest registrieren: Redirect URIs bei OAuth/SSO so exakt wie möglich hinterlegen.
6. Weiterleitungen protokollieren: Auffällige externe Ziele erkennen, ohne Tokens oder personenbezogene Daten mitzuschreiben.

Codebeispiel: Zielbezeichner statt freie URL

Verwundbar:

return redirect($request->query('next'));

Sicherer:

$destinations = [
    'account' => route('account.index'),
    'orders' => route('orders.index'),
];

$target = $destinations[$request->query('next')] ?? route('home');
return redirect()->to($target);

Müssen externe Ziele unterstützt werden, braucht es eine URL-Parser-basierte Positivliste aus Schema, exaktem Host und gegebenenfalls Port. Ein Präfix- oder Teilzeichenkettenvergleich ist dafür nicht ausreichend.

Wie werden sie getestet?

Tester erfassen alle Weiterleitungsparameter in Login, Logout, Fehlern, Einladungen und E-Mail-Links. Sie prüfen absolute, relative, protokollrelative, kodierte und parserkritische Ziele sowie verkettete Redirects. Entscheidend ist das tatsächliche Ziel im Browser und nicht nur der Statuscode. OAuth- und SSO-Flows werden mit Testkonten und kontrollierten Callback-Zielen untersucht, ohne echte Tokens offenzulegen.