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
Häufig gestellte Fragen
Was ist eine Open-Redirect-Schwachstelle?
Ein Open Redirect ist ein Fehler, bei dem eine Webanwendung Nutzer an eine Ziel-URL sendet, die aus nicht validierter Eingabe stammt, in der Regel einem Query-Parameter wie ?next= oder ?url=. Da der Link auf einer vertrauenswürdigen Domain beginnt, behandeln der Browser des Opfers und jeder Link-Scan-Filter ihn als sicher, doch die Anwendung leitet sie dann an die Seite weiter, die der Parameter nennt - auch an die eines Angreifers. Sie wird als CWE-601 klassifiziert und liegt unter Broken Access Control in den OWASP Top 10. Der Fehler ist die fehlende Prüfung, nicht der Redirect selbst.
Warum sind Open Redirects gefährlich, wenn sie einen nur auf eine andere Seite schicken?
Weil die Gefahr im Vertrauen liegt, das die Startdomain leiht. Ein Phishing-Link, der https://trusted-bank.example/login?next=evil.example lautet, besteht den Blicktest, übersteht viele E-Mail-Filter und landet das Opfer auf einer überzeugenden gefälschten Login-Seite - und das alles, während er scheinbar von der echten Bank stammt. Open Redirects verketten sich auch zu größeren Angriffen: Sie können OAuth-Autorisierungscodes oder Token preisgeben, wenn das Redirect-Ziel vom Angreifer kontrolliert wird, und verwandeln so einen Fehler geringer Schwere in eine Kontoübernahme. Der Redirect ist der Zustellmechanismus, nicht der gesamte Exploit.
Sind URL-Shortener eine Open-Redirect-Schwachstelle?
Nein, nicht wenn sie korrekt gebaut sind - und die Unterscheidung ist der Punkt. Ein Open Redirect nimmt zur Anfragezeit ein beliebiges Ziel aus Nutzereingabe und leitet ohne Validierung dorthin weiter. Ein Kurzlink ordnet einen festen Code einem Ziel zu, das beim Erstellen des Links serverseitig festgelegt und gespeichert wurde; das Redirect-Ziel stammt nie aus der eingehenden Anfrage. Diese serverseitige Zuordnung ist genau die Verteidigung, die OWASP gegen Open Redirects empfiehlt. Ein Shortener wird nur dann zum Problem, wenn er ungeprüften Nutzern erlaubt, Links auf alles Mögliche zu erstellen, und ihnen einen Domain-Ruf leiht, den sie missbrauchen können - was ein Missbrauchs- und Moderationsproblem ist, kein Open-Redirect-Fehler.
Wie verhindert man Open-Redirect-Schwachstellen?
Der stärkste Fix besteht darin, überhaupt nie eine Ziel-URL aus der Anfrage zu akzeptieren. Lassen Sie den Client einen kurzen Namen, eine ID oder ein Token senden und ordnen Sie es serverseitig dem vollständigen Ziel zu - dasselbe Modell, das ein URL-Shortener verwendet. Wenn Sie wirklich eine URL akzeptieren müssen, validieren Sie sie gegen eine Allowlist vertrauenswürdiger Hosts statt gegen eine Denylist schlechter Hosts, weisen Sie alles zurück, das kein relativer Pfad oder keine genehmigte Domain ist, und seien Sie beim Parsen streng, damit Tricks wie //evil.example oder Backslashes nicht durchrutschen. Als letztes Mittel leiten Sie den Redirect über eine Zwischenseite, die das Ziel anzeigt, bevor der Nutzer weitergeschickt wird.
Wie nutzen Angreifer einen Open Redirect aus?
Sie finden einen Endpunkt, der einen URL-Parameter in einen Redirect spiegelt, basteln dann auf der vertrauenswürdigen Domain einen Link mit ihrer eigenen Seite in diesem Parameter und verteilen ihn per E-Mail, Anzeige oder Nachricht. Varianten umfassen die URL-Codierung der Nutzlast, um schwache Filter zu umgehen, die Verwendung protokollrelativer URLs wie //attacker.example, das Ausnutzen nur des Host-Teils unter Beibehaltung eines legitim aussehenden Pfads und den Missbrauch der OAuth-redirect_uri-Verarbeitung, um Token abzufangen. Der gemeinsame Nenner ist, dass das Opfer der ersten Domain vertraut und sie sieht und die zweite nie sieht, bis es zu spät ist.
Ist ein Open Redirect eine Schwachstelle hoher oder niedriger Schwere?
Für sich genommen wird ein Open Redirect oft als niedrig bis mittel eingestuft, weil er den Server nicht direkt kompromittiert - er schickt Nutzer woandershin. Doch die Schwere hängt davon ab, womit er sich verkettet. In der Nähe eines Authentifizierungsablaufs kann er OAuth-Token preisgeben und zur Kontoübernahme führen, was hohe Schwere ist; als Phishing-Hilfsmittel kann er einen realen Verlust von Zugangsdaten verursachen, den ein CVSS-Score nicht erfasst. Behandeln Sie ihn nach seiner Auswirkung im Kontext, nicht nach dem Grundlabel, und beheben Sie ihn ungeachtet dessen: Die Behebung ist günstig, das Missbrauchspotenzial ist es nicht.
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