Ein Open Redirect ist eine Schwachstelle, bei der eine Webanwendung eine Ziel-URL aus nicht validierter Nutzereingabe nimmt - in der Regel einem Query-Parameter wie ?next= oder ?url= - und den Browser dorthin weiterleitet, ohne sie zu prüfen. Der Link beginnt auf einer Domain, der das Opfer vertraut, sodass er die Prüfung besteht, und landet sie dann leise woanders. Der Fix besteht nicht darin, das Weiterleiten zu beenden. Er besteht darin, der Anfrage nicht mehr entscheiden zu lassen, wohin der Redirect führt.
Diese Unterscheidung ist wichtig, weil Redirects überall sind und die meisten von ihnen in Ordnung sind. Sich einloggen und auf die gewünschte Seite zurückspringen, an einen Zahlungsanbieter übergeben, ein OAuth-Callback - alles normal, alles Redirects. Der Fehler, katalogisiert als CWE-601 und in den OWASP Top 10 unter Broken Access Control eingeordnet, ist speziell der Fall, in dem das Ziel aus nutzergesteuerter Eingabe stammt und nichts es zuerst validiert. Ein Angreifer liefert seine eigene URL, die vertrauenswürdige Seite leitet dorthin weiter, und das Vertrauen überträgt sich mit dem Klick.
Ich verbringe meine Tage auf dem Redirect-Pfad, daher ist dies ein Thema, zu dem ich Meinungen habe. Kurzlinks sind per Definition Redirects, was "ist ein Shortener nur ein Open Redirect?" zu einer fairen Frage macht - und die Antwort, richtig gemacht, ist ein klares Nein. Wir kommen unten dahin. Falls Ihnen die Redirect-Mechanik neu ist, ist Arten von Redirects die Einführung, und wie URL-Shortener funktionieren behandelt die Grundlagen der Redirect-Tiers.
Was ein Open Redirect tatsächlich ist#
Reduzieren Sie es auf den Mechanismus. Eine Seite akzeptiert einen Parameter, der angibt, wohin es als Nächstes gehen soll, und verwendet ihn in einem HTTP-Redirect, ohne zu bestätigen, dass er auf einen erlaubten Ort zeigt.
https://trusted.example/login?next=https://evil.example/fake-login
Das Opfer sieht vorne trusted.example und klickt. Nach dem Login liest die Anwendung next und gibt einen Redirect zu evil.example aus. Der Browser gehorcht, denn ein Redirect ist nur ein Location-Header und ein 3xx-Status - die HTTP-Spezifikation definiert dieses Verhalten unverblümt, und der Browser hat keine Möglichkeit zu wissen, dass dieses bestimmte Ziel feindlich ist. Der Nutzer, der zusieht, wie sich die Adressleiste ändert, nachdem er dem Link bereits vertraut hat, bemerkt es oft nicht.
OWASP beschreibt die Kerngefahr unverblümt: Der Servername im veränderten Link ist mit der ursprünglichen Seite identisch, was einem bösartigen Redirect Glaubwürdigkeit verleiht. Die Schwachstelle ist nicht, dass die Seite weiterleitet. Sie ist, dass ein Außenstehender das Ziel gewählt hat.
Warum ein "harmloser" Redirect eine echte Bedrohung ist#
Der Reflex ist, mit den Schultern zu zucken: Na ja, er schickt jemanden auf eine andere Website, wo ist der Schaden. Der Schaden ist geliehenes Vertrauen, und es skaliert.
Phishing ist der prominenteste Einsatz. Ein Link, der mit einer Bank, einem SaaS-Login oder einem Behördenportal beginnt, segelt an der schnellen Sichtprüfung vorbei, die die meisten Menschen vornehmen, und an einer überraschenden Anzahl automatisierter Filter, die nur die führende Domain inspizieren. Das Opfer kommt bei einer pixelgenauen Fälschung der erwarteten Login-Seite an, auf einer Domain, die einen Sprung zuvor richtig aussah, und tippt sein Passwort ein. Keine Malware, keine exotische Nutzlast - nur ein Redirect und ein Klon.
Es wird schlimmer, wenn Redirects nahe der Authentifizierung sitzen. Ein Open Redirect in einem OAuth-Ablauf kann einen Autorisierungscode oder ein Token an eine vom Angreifer kontrollierte redirect_uri preisgeben, was einen "geringfügigen" Fehler zu einer vollständigen Kontoübernahme eskaliert. Deshalb sind Open Redirects ein fester Bestandteil von Bug-Bounty-Berichten statt einer Fußnote. Derselbe Trick wäscht auch Reputation: Spammer und Malware-Betreiber lieben es, über eine vertrauenswürdige Domain zu springen, weil so ihr echter Link an Blocklists vorbeikommt. Wir behandeln die breitere Kategorie in der Sicherheits-Checkliste für URL-Shortener und den Vertrauensaspekt aus Sicht des Besuchers in Sind URL-Shortener sicher.
Wie man Open Redirects verhindert#
Es gibt eine Hierarchie von Fixes, und an ihrer Spitze steht der, der das Problem tatsächlich beendet. Der Cheat Sheet von OWASP ordnet sie ein, und die Reihenfolge lohnt es, befolgt zu werden.
- Nehmen Sie überhaupt keine URL aus der Anfrage. Lassen Sie den Client einen kurzen Namen, eine ID oder ein Token senden und es serverseitig zum vollständigen Ziel auflösen. OWASP nennt dies den höchsten Schutzgrad, weil die eingehende Anfrage kein beliebiges Ziel mehr benennen kann. Falls dieses Muster vertraut klingt, sollte es das: So funktioniert ein URL-Shortener.
- Allowlist, nicht Denylist. Wenn Sie ein Ziel akzeptieren müssen, prüfen Sie es gegen eine Liste vertrauenswürdiger Hosts oder eine strenge Regex. Allow-Listing scheitert geschlossen - alles, was nicht ausdrücklich erlaubt ist, wird abgelehnt. Deny-Listing scheitert offen, und Angreifer werden dafür bezahlt, die Einträge zu finden, die Sie vergessen haben.
- Parsen Sie streng. Weisen Sie protokollrelative URLs (
//evil.example) zurück, normalisieren Sie Backslashes, decodieren Sie, bevor Sie validieren, und behandeln Sie den Host - nicht nur das String-Präfix - als das zu prüfende Element. Die meisten Filterumgehungen leben in nachlässigem Parsen. - Zeigen Sie eine Zwischenseite als Rückfallebene. Wenn ein Redirect auf eine externe Seite unvermeidbar ist, leiten Sie ihn über eine Seite, die das Ziel benennt und den Nutzer um Bestätigung bittet. Es ist Reibung, aber sie verwandelt einen stillen Redirect in einen informierten.
Das wiederkehrende Thema ist, dass sichere Redirects vom Server entschieden werden, aus Daten, denen der Server bereits vertraut - nie von irgendeiner Zeichenkette, die in der Query ankam.
Wenn Sie Redirects in ein Produkt einbauen und diesen Fehlerfall lieber nicht selbst besitzen möchten, ordnet Elidos Entwicklerplattform Codes von Haus aus serverseitig Zielen zu - beginnen Sie mit dem API-Schnellstart und basteln Sie nie wieder von Hand einen ?url=-Parameter.
Warum Kurzlinks die Verteidigung sind, nicht der Fehler#
Hier ist der Teil, der Menschen überrascht. Ein korrekt gebauter URL-Shortener ist die Musterimplementierung von OWASPs Open-Redirect-Fix Nummer eins.
Wenn ein Kurzlink erstellt wird, wird sein Ziel serverseitig validiert und gespeichert, gebunden an einen kurzen Code. Wenn jemand ihn besucht, schlägt das Redirect-Tier diesen Code nach und leitet zum gespeicherten Ziel weiter. Das Ziel stammt nie aus der eingehenden Anfrage - der Besucher kann kein ?url= anhängen und den Link woandershin umbiegen, weil es keinen solchen Parameter zum Umbiegen gibt. Das ist genau die Token-zu-URL-Zuordnung, die OWASP empfiehlt, millionenfach pro Tag in Produktion laufend. Architektonisch lebt das in unserem Edge-Redirect-Tier, und das Latenzbudget, das dafür zahlt, ist Gegenstand von p95 unter 15 ms für Redirects erreichen.
Die ehrliche Einschränkung: Ein Shortener kann immer noch missbraucht werden, nur nicht über einen Open Redirect. Wenn eine Plattform jedem erlaubt, ohne Scanning oder Moderation Links auf alles Mögliche zu prägen, werden Angreifer ihren Domain-Ruf nutzen, um ihre eigenen bösartigen Ziele zu tarnen - weshalb verantwortungsvolle Shortener Ziele scannen und Missbrauchsrichtlinien durchsetzen. Das ist ein Problem der Inhaltsmoderation, verschieden vom Eingabevalidierungsfehler, um den es in diesem Artikel geht, und sollte nicht vermengt werden. Die verwandte Praxis, ein Ziel absichtlich zu verbergen, wird in Link-Cloaking und URL-Masking erklärt behandelt, und der Social-Engineering-Verwandte von all dem - feindliche QR-Codes - in Sind QR-Codes sicher.
Die Kernaussage in einer Zeile#
Wenn Ihr Code ein Ziel aus der Anfrage liest und dorthin weiterleitet, haben Sie einen Open Redirect, der nur darauf wartet, gefunden zu werden. Ordnen Sie stattdessen eine ID einem serverseitigen Ziel zu, setzen Sie alles, dessen Übernahme aus Eingabe Sie nicht vermeiden können, auf eine Allowlist, und parsen Sie, als rechneten Sie damit, angegriffen zu werden. Redirects sind nicht das Risiko. Der Anfrage die Wahl zu lassen, wohin sie führen, ist es. Der Unterschied zwischen einem 301 und einem 302 in 301 vs. 302 Redirects ist eine Fußnote neben dieser einen Regel.
Verwandtes im Blog#
Elido testen
URL einfügen, kurzer Link in Sekunden
Kein Konto nötig. Link bleibt 30 Tage aktiv. Konto erstellen, um ihn dauerhaft zu behalten.
Kostenlos, keine Anmeldung erforderlich · 2 pro Tag