Open-Redirect-Schwachstellen zuverlässig verhindern

1. Warum eine Weiterleitung allein schon ein Sicherheitsrisiko ist

Der eigentliche Wert einer Open-Redirect-Schwachstelle für einen Angreifer liegt nicht in einem technischen Datenverlust, sondern im Vertrauensmissbrauch: Ein Link wie `https://vertrauenswuerdiger-shop.de/logout?next=https://boesartige-seite.de` beginnt für den Nutzer sichtbar mit der echten, vertrauten Domain, was klassische Phishing-Erkennungsmerkmale wie "prüfe die Domain in der Adresszeile" wirkungslos macht, da der Nutzer die Domain zunächst tatsächlich korrekt sieht, bevor die serverseitige Weiterleitung ihn stillschweigend auf eine andere Domain schickt.

Diese Eigenschaft macht Open Redirects besonders wertvoll für gezielte Phishing-Kampagnen, weil der schädliche Link durch E-Mail-Sicherheitsfilter, die häufig nur die Domain der ersten sichtbaren URL prüfen, oft unentdeckt hindurchrutscht, und weil selbst sicherheitsbewusste Nutzer, die tatsächlich auf die Domain achten, durch den korrekten ersten Teil der URL in falscher Sicherheit gewiegt werden. Gerade bei gezielten Angriffen gegen einzelne Mitarbeiter, etwa im Rahmen von Spear-Phishing-Kampagnen gegen die Buchhaltung oder die IT-Administration, ist dieser Vertrauensvorschuss oft der entscheidende Faktor, der über Erfolg oder Misserfolg des gesamten Angriffs entscheidet.

2. Ein typisches verwundbares Muster in Symfony

Das folgende Beispiel zeigt ein häufig anzutreffendes Muster: Nach einem erfolgreichen Login wird der Nutzer zu der URL weitergeleitet, die er vor der Anmeldung besuchen wollte, gespeichert im Query-Parameter `redirect`. Ohne Prüfung des Zielwerts kann ein Angreifer diesen Parameter mit einer beliebigen externen URL füllen.

<?php
declare(strict_types=1);

// VERWUNDBAR: Redirect-Ziel wird ungeprueft uebernommen
#[Route('/login-erfolgreich', name: 'app_login_erfolgreich')]
public function loginErfolgreich(Request $request): RedirectResponse
{
    $ziel = $request->query->get('redirect', '/dashboard');
    return new RedirectResponse($ziel);
}

// Angreifer-Link: https://echte-domain.de/login-erfolgreich
//                 ?redirect=https://boesartige-seite.de/fake-login

3. Die robusteste Lösung: eine explizite Allowlist erlaubter Ziele

Die zuverlässigste Absicherung besteht darin, Redirect-Ziele grundsätzlich gegen eine explizite Allowlist bekannter, erlaubter Domains oder, noch strenger, gegen eine feste Liste bekannter, interner Routennamen zu prüfen, statt zu versuchen, gefährliche externe URLs über eine Blockliste oder Musterprüfung auszuschließen. Blocklisten-Ansätze scheitern in der Praxis fast immer an cleveren Umgehungen, etwa durch alternative URL-Kodierungen, doppelte Schrägstriche oder ungewöhnliche Protokoll-Präfixe, während eine Allowlist strukturell unmöglich zu umgehen ist, weil jede nicht explizit erlaubte URL kategorisch abgelehnt wird.

Am sichersten ist es, Redirect-Ziele überhaupt nicht als freie URL, sondern als symbolischen Schlüssel entgegenzunehmen, der intern auf eine feste, im Code definierte Route aufgelöst wird, sodass ein Angreifer niemals eine tatsächliche URL, sondern höchstens einen ungültigen Schlüssel einschleusen kann, der dann auf ein sicheres Standardziel zurückfällt. Dieser Ansatz erfordert zwar etwas mehr Vorarbeit bei der Definition der erlaubten Ziel-Schlüssel, beseitigt die gesamte Schwachstellenklasse aber dauerhaft und vollständig, statt sie nur einzudämmen.

4. Sichere Implementierung mit Symfonys UriSigner oder Routennamen

Für Fälle, in denen tatsächlich eine relative URL innerhalb der eigenen Anwendung weitergegeben werden muss, etwa "zurück zur zuletzt besuchten Produktseite", genügt eine Prüfung, dass die URL relativ ist (nicht mit `http://`, `https://` oder `//` beginnt) und keine eingebettete, absolute URL über einen Umweg wie `/\evil.com` enthält, kombiniert mit einer expliziten Whitelist erlaubter Pfadmuster.

<?php
declare(strict_types=1);

// SICHER: nur relative Pfade erlaubt, keine Schema-Praefixe
#[Route('/login-erfolgreich', name: 'app_login_erfolgreich')]
public function loginErfolgreich(Request $request): RedirectResponse
{
    $ziel = $request->query->get('redirect', '/dashboard');

    $istSicherRelativ = str_starts_with($ziel, '/')
        && !str_starts_with($ziel, '//')
        && !str_starts_with($ziel, '/\\');

    if (!$istSicherRelativ) {
        $ziel = '/dashboard';
    }

    return new RedirectResponse($ziel);
}

5. Open Redirects als Baustein in OAuth-Angriffsketten

Besonders kritisch werden Open-Redirect-Schwachstellen im Zusammenspiel mit OAuth- oder OpenID-Connect-Flows, weil ein OAuth-Autorisierungsserver dem Nutzer nach erfolgreicher Anmeldung ein sensibles Access-Token oder einen Autorisierungscode über eine Redirect-URI zurückgibt. Enthält die eigene Anwendung eine Open-Redirect-Schwachstelle, kann ein Angreifer diese als Sprungbrett nutzen, um den OAuth-Autorisierungsserver dazu zu bringen, das sensible Token zunächst an die eigene, vertrauenswürdige Domain zu senden, von wo aus die Open-Redirect-Lücke es dann unbemerkt an die Domain des Angreifers weiterreicht.

Diese Angriffskette funktioniert selbst dann, wenn der OAuth-Provider die Redirect-URI selbst streng gegen eine registrierte Liste prüft, weil die registrierte, vertrauenswürdige Redirect-URI ja tatsächlich zur eigenen Domain gehört, die anschließende, interne Weiterleitung aber vom OAuth-Provider gar nicht mehr kontrolliert werden kann. Deshalb gilt eine Open-Redirect-Schwachstelle in einer Anwendung, die selbst OAuth-Client ist, als deutlich kritischer als in einer Anwendung ohne OAuth-Integration.

Diese Angriffskette ist in der Sicherheitsliteratur unter dem Namen Token-Leakage-über-Open-Redirect dokumentiert und war in der Vergangenheit die Ursache mehrerer real gemeldeter Schwachstellen bei großen Anbietern, weshalb OAuth-Spezifikationen wie RFC 9700 inzwischen explizit empfehlen, Redirect-URIs möglichst exakt statt nur präfixbasiert zu registrieren und abzugleichen, um genau diese Kombination aus vertrauenswürdiger Domain und offener Weiterleitungslücke von vornherein auszuschließen.

6. Open Redirects systematisch testen

Ein systematischer Test durchsucht den Anwendungscode nach allen Stellen, an denen eine `RedirectResponse` (oder ein äquivalenter Mechanismus) mit einem aus der Anfrage stammenden Wert erzeugt wird, etwa über eine Codesuche nach `RedirectResponse` in Kombination mit `$request->query` oder `$request->get`. Für jeden Fundort sollte anschließend geprüft werden, ob eine externe URL wie `https://angreifer-kontrollierte-domain.de` als Redirect-Ziel akzeptiert und tatsächlich als 3xx-Weiterleitung mit dieser fremden Domain im `Location`-Header ausgeliefert wird.

Automatisierte Security-Scanner wie OWASP ZAP enthalten spezialisierte Prüfregeln für Open Redirects, die systematisch bekannte Umgehungstechniken (etwa `//angreifer.de`, `/\angreifer.de`, doppelt URL-kodierte Schrägstriche) gegen jeden erkannten Redirect-Parameter durchprobieren, was eine gute Ergänzung zur manuellen Codeanalyse darstellt.

7. Eine Warn-Zwischenseite als zusätzliche Schutzebene

Für Anwendungsfälle, in denen tatsächlich zu einer vom Nutzer oder einem Drittanbieter angegebenen externen URL weitergeleitet werden muss, etwa bei Affiliate-Links oder externen Zahlungsanbietern, reduziert eine explizite Zwischenseite ("Sie verlassen jetzt unsere Website und werden zu [externe-domain.de] weitergeleitet") das Risiko erheblich, weil der Nutzer die tatsächliche Zieldomain vor der Weiterleitung sieht und die stillschweigende, unmittelbare Umleitung entfällt, auf der Phishing-Angriffe eigentlich basieren.

Diese Zwischenseite ist kein Ersatz für eine technische Ziel-Validierung, sondern eine zusätzliche, nutzerorientierte Verteidigungsebene, die besonders in Fällen greift, in denen eine vollständige Allowlist aller legitimen externen Ziele aus fachlichen Gründen nicht praktikabel ist.

8. Missbrauchsversuche protokollieren und überwachen

Selbst mit einer robusten Allowlist lohnt es sich, jeden abgelehnten Redirect-Versuch mit einem nicht erlaubten Ziel strukturiert zu protokollieren, da eine plötzliche Häufung solcher Ablehnungen für einen bestimmten Nutzer oder eine bestimmte IP-Adresse auf einen aktiven Erkundungsversuch eines Angreifers hindeuten kann, der gezielt nach einer noch nicht abgesicherten Redirect-Stelle in der Anwendung sucht. Ein einfaches Alert-Regelwerk, das bei mehreren abgelehnten Redirect-Zielen innerhalb kurzer Zeit von derselben Quelle auslöst, liefert oft einen frühen Hinweis auf gezielte Angriffsversuche, lange bevor ein tatsächlich erfolgreicher Phishing-Vorfall gemeldet wird.

Dieses Logging ist außerdem wertvoll, um im Nachhinein zu rekonstruieren, ob ein gemeldeter Phishing-Vorfall tatsächlich über eine Open-Redirect-Schwachstelle der eigenen Anwendung lief, was für die Kommunikation mit betroffenen Nutzern und für die Priorisierung nachfolgender Sicherheitsmaßnahmen entscheidend sein kann. Idealerweise fließen diese Logs in dasselbe zentrale Monitoring-System wie andere sicherheitsrelevante Ereignisse, etwa fehlgeschlagene Login-Versuche oder abgelehnte CSRF-Token, damit ein Sicherheitsteam Muster über verschiedene Angriffsvektoren hinweg erkennen kann, statt jede Ereignisquelle isoliert zu betrachten.

9. Schutzansätze im Überblick

Die folgende Tabelle vergleicht die vorgestellten Schutzansätze gegen Open Redirects.

10. Zusammenfassung

11. FAQ: Open Redirect: Das Wichtigste auf einen Blick