Articles

7. Open Redirects – Wenn eine kleine Umleitung zum großen Risiko wird

Planted October 13, 2025

Logo

Ein kleiner Parameter mit großer Wirkung

Kürzlich bin ich bei einer Sicherheitsanalyse auf eine Schwachstelle gestoßen, die auf den ersten Blick unspektakulär wirkt – aber erhebliche Folgen haben kann. In einem Login-Endpoint eines großen europäischen Anbieters war es möglich, den Weiterleitungsparameter redirect_to so zu manipulieren, dass Nutzer nach erfolgreicher Anmeldung auf eine beliebige externe Domain umgeleitet wurden.

Solche sogenannten Open Redirects gehören zu den eher „stillen“ Schwachstellen im Web. Sie ermöglichen keine direkte Übernahme eines Systems – wohl aber das Ausnutzen von Vertrauen, was im Kontext von Phishing, Social Engineering oder Session Hijacking gravierende Konsequenzen haben kann.

Wie die Schwachstelle funktionierte

Der Login-Flow war eigentlich sauber gedacht:

Nach der Authentifizierung sollte der Benutzer automatisch zur ursprünglich gewünschten Seite zurückkehren – gesteuert über den GET-Parameter redirect_to. Ein ganz normaler Ablauf, wie er in vielen Webanwendungen vorkommt:

https://www.example.com/api/auth/signin/service-login?redirect_to=https://www.example.com/home

Das Problem:

Der Server überprüfte nicht streng genug, wohin die Weiterleitung tatsächlich führen durfte. Durch geschicktes Encoding ließen sich Zeilenumbrüche (%0a%0d) einfügen, die von manchen Systemen als Trennung interpretiert werden. Das führte dazu, dass ein zweiter Link nachgeladen wurde – in diesem Fall eine externe Domain.

Beispiel (vereinfacht):

https://www.example.com/api/auth/signin/service-login?redirect_to=https://www.example.com%0a%0dhttps://malicious.example.org

Das Ergebnis:

Nach erfolgreichem Login landete der Browser nicht auf der legitimen Zielseite, sondern auf der zweiten URL – also einer völlig anderen Domain.

Warum das gefährlich ist

Die Tücke eines Open Redirects liegt nicht in der Technik, sondern im Vertrauen der Nutzer. Ein Link, der mit https://www.example.com beginnt, wirkt sicher und legitim. Ein Angreifer kann genau diesen Effekt ausnutzen – etwa, um Nutzer auf eine täuschend echte Phishing-Seite zu locken.

Die möglichen Angriffsvektoren:

  • Phishing: Nutzer werden nach der Anmeldung auf gefälschte Login- oder Datensammelseiten umgeleitet.
  • Session Theft: In seltenen Fällen kann die Weiterleitung genutzt werden, um Redirect-Daten oder Tokens abzugreifen.
  • Trust Abuse: Da der Angriff von einer scheinbar sicheren Domain ausgeht, wird er deutlich seltener hinterfragt.
  • Chaining: In Kombination mit anderen Schwachstellen (z.B. XSS oder OAuth-Misskonfigurationen) kann der Schaden potenziert werden.

Open Redirects sind also keine bloße „Bagatelle“ – sie sind ein idealer Einstiegspunkt für gezielte Angriffe.

Technischer Überblick

  • Typ: Open Redirect (CWE-601)
  • Vulnerabler Parameter: redirect_to
  • Payload: %0a%0d (CRLF-Injection)
  • Schweregrad: Mittel (CVSS 4.0)
  • Angriffsvektor: Remote, keine besondere Berechtigung nötig
  • Auswirkung: Umleitung auf externe Seiten, erhöhtes Phishing-Risiko.

Wie man es richtig macht

Die Lösung ist technisch simpel, verlangt aber Konsequenz in der Umsetzung. Empfehlenswerte Maßnahmen:

  1. Whitelist-Ansatz: Nur Weiterleitungen auf eigene, vertrauenswürdige Domains zulassen (z.B. *.example.com).
  2. Striktes URL-Parsing: Eingaben nach RFC3986 validieren und encodierte Zeilenumbrüche (%0a, %0d) sowie doppelte https://-Sequenzen entfernen.
  3. Fallbackverhalten: Wenn redirect_to fehlt oder ungültig ist, auf eine sichere Standardseite (z.B. /dashboard) umleiten.
  4. Protokollierung: Verdächtige Redirect-Versuche (externe Domains, ungewöhnliche Encodings) erfassen und überwachen.
  5. Framework-Features nutzen: Viele Webframeworks bieten Funktionen zur sicheren Handhabung von Redirects — diese nutzen, statt eigene, fehleranfällige Implementationen zu schreiben.

Zusätzlich lohnt sich eine kleine Test-Suite für Auth-Flows, die Manipulationen an Redirect-Parametern automatisiert prüft.

Fazit

Ein Open Redirect mag auf den ersten Blick banal erscheinen — kein Datenleck, keine Remote Code Execution.

Doch im richtigen Kontext kann er zum Einfallstor für Phishing-Kampagnen, Token-Leaks oder Markenmissbrauch werden. Die Gefährdung entsteht vor allem durch das Vertrauen der Nutzer in scheinbar legitime URLs.

Der gemeldete Befund wurde vom verantwortlichen Team bestätigt und akzeptiert, was zeigt, dass selbst vermeintlich kleine Probleme geprüft und belohnt werden — ein gutes Beispiel für funktionierende Sicherheitsprozesse und den Nutzen verantwortlicher Meldungen.

Reward