Wissen › Open Redirect / Unvalidated Redirect
Open Redirect / Unvalidated Redirect
Eine Weiterleitung übernimmt ein ungeprüftes Ziel aus dem Request und schickt Besucher auf eine fremde Domain.
Lies den Artikel und beantworte am Ende 9 Fragen. Erst wenn alle richtig beantwortet sind, ist die Lektion im Training erledigt.
Von einem Open Redirect spricht man, wenn eine Anwendung ein Weiterleitungsziel aus dem Request übernimmt, ohne ausreichend zu prüfen, wohin umgeleitet wird. Angreifer hängen eine fremde Zieladresse an einen vertrauenswürdigen Link – das Opfer sieht die bekannte Domain, landet aber woanders. Das ist die klassische Grundlage für glaubwürdiges Phishing.
Wie der Angriff funktioniert
- Ein Link wie /weiter?ziel=… oder ?redirect_url=… übernimmt das Ziel direkt aus dem Request.
- Die Prüfung ist oft eine Blockliste (verbotene Zeichen/Präfixe) statt einer Freigabeliste erlaubter Hosts – und Blocklisten lassen sich umgehen.
- Browser normalisieren den Backslash: /\fremd.example wird zu //fremd.example (protokoll-relativ) und zeigt nach extern, obwohl es wie ein lokaler Pfad aussieht.
Varianten
Beispiel
Der Unterschied ist die Zielprüfung – Blockliste vs. Freigabeliste:
// verwundbar: Ziel aus dem Request, nur per Blockliste (sanitizeLocalUrl),
// Rückgabewert roh als Location
$ziel = (string)($request->getQueryParams()['ziel'] ?? '');
$ziel = GeneralUtility::sanitizeLocalUrl($ziel); // /\evil.example kommt durch
if ($ziel !== '') { return new RedirectResponse($ziel, 303); }
// sicher: gegen feste Freigabeliste prüfen
$erlaubt = ['/tauchen', '/kontakt'];
if (in_array($ziel, $erlaubt, true)) { return new RedirectResponse($ziel, 303); }Mögliche Auswirkungen
- Phishing: Das Opfer vertraut dem bekannten Link und wird auf eine gefälschte Seite geleitet.
- Diebstahl von Tokens/Sessions, wenn nach Login/OAuth auf ein angreifergewähltes Ziel umgeleitet wird.
- Umgehung von Link- und Spam-Filtern, weil die sichtbare Domain vertrauenswürdig ist.
Selbst prüfen: Sind meine Weiterleitungen dicht?
Jede Stelle, an der ein Request-Wert zum Weiterleitungsziel wird, lässt sich gegen die gleiche kurze Checkliste halten. Der Leitgedanke: Freigabeliste statt Blockliste, und das Ziel serverseitig gegen die eigene Domain abgleichen.
1. Freigabeliste statt Blockliste?
Prüfe Ziele gegen eine feste Liste erlaubter Hosts/Pfade. Blocklisten (verbotene Zeichen/Präfixe) lassen sich durch Normalisierung des Browsers umgehen und sind kein verlässlicher Schutz.
2. Wird das Ziel absolut aufgelöst?
Ein Ziel serverseitig zu einer absoluten URL auflösen und den Host explizit gegen die eigene(n) Domain(s) abgleichen, statt den Request-String roh als Location-Header zu senden.
3. Lässt sich die URL durch einen Key ersetzen?
Am robustesten ist es, gar keine vom Nutzer gelieferte URL weiterzureichen, sondern einen internen Key/eine ID auf ein fest hinterlegtes Ziel abzubilden.
4. Sind Core und Extensions aktuell?
Weiterleitungs-Helfer des Cores hatten eigene Lücken (z. B. sanitizeLocalUrl bis 11.5.50, CVE-2026-47347). Aktueller Stand (hier ≥ 11.5.51 ELTS) schließt die bekannten Fälle.
Worauf du in TYPO3 achten musst
In TYPO3 entstehen Open Redirects überall dort, wo ein Request-Parameter als Weiterleitungsziel dient – in eigener Glue-Logik ebenso wie in Extensions. Der Core stellt mit GeneralUtility::sanitizeLocalUrl() einen Helfer bereit, der aber nur so sicher ist wie seine Verwendung.
sanitizeLocalUrl ist kein Freifahrtschein
Bis 11.5.50 prüfte die Funktion per Blockliste; Pfade wie /\host wurden fälschlich als lokal akzeptiert (CVE-2026-47347). Der Fix in 11.5.51 ELTS stellt auf eine strikte Freigabeliste um.
Rückgabewert nicht roh weiterverwenden
Selbst ein korrekt geprüftes Ziel sollte serverseitig absolut aufgelöst und gegen erlaubte Hosts/Pfade abgeglichen werden, statt den String direkt als Location zu senden.
felogin & Co.
felogins redirect_url läuft durch denselben Validator. Dass das v11-felogin die Location zusätzlich absolutiert, entschärft den /\-Trick dort zufällig – verlass dich nicht darauf, sondern prüfe Ziele explizit.
Schutzmaßnahmen
- Weiterleitungsziele gegen eine feste Freigabeliste erlaubter Hosts/Pfade prüfen – nie nur per Blockliste.
- Das Ziel serverseitig absolut auflösen und den Host explizit gegen die eigene(n) Domain(s) abgleichen.
- Nach Möglichkeit keine user-gelieferten URLs weiterreichen, sondern interne Keys/IDs auf feste Ziele mappen.
- Core/Extensions aktuell halten (hier: ≥ 11.5.51 ELTS für den sanitizeLocalUrl-Fix).
Lektion abschließen: 9 Fragen beantworten
Diese Lektion gilt im Training erst als erledigt, wenn du alle 9 Fragen zu diesem Artikel richtig beantwortet hast – von leicht bis knifflig. Dafür brauchst du ein Konto, damit dein Fortschritt gespeichert wird.
Interaktiv üben
In der Lernplattform kannst du diese Schwachstellenklasse an einer echten, isolierten TYPO3-Instanz nachvollziehen: