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.
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.
Beispiel
Der Unterschied ist die Zielprüfung – Blockliste vs. Freigabeliste:
// verwundbar: nur "lokal?" per Blockliste, Ergebnis roh als Location
$ziel = GeneralUtility::sanitizeLocalUrl($_GET['ziel']); // /\evil.example kommt durch
if ($ziel !== '') { header('Location: ' . $ziel); }
// sicher: gegen feste Freigabeliste prüfen
$erlaubt = ['/tauchen', '/kontakt'];
if (in_array($ziel, $erlaubt, true)) { header('Location: ' . $ziel); }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.
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).
Interaktiv üben
In der Lernplattform kannst du diese Schwachstellenklasse an einer echten, isolierten TYPO3-Instanz nachvollziehen: