Open Redirect

Nahezu jede Anwendung leitet Besucher irgendwann weiter: nach der Anmeldung zurück auf die ursprünglich aufgerufene Seite, nach dem Bezahlen auf eine Bestätigung. Woher dieses Ziel stammt, steht meist in einem Parameter mit einem Namen wie returnUrl oder next. Übernimmt die Anwendung den Wert ungeprüft, entscheidet nicht sie, sondern der Verfasser des Links, wo der Besucher ankommt.

Was ist ein Open Redirect?

Ein Open Redirect ist eine Schwachstelle, bei der eine Anwendung einen Besucher an eine Adresse weiterleitet, die vollständig aus der Eingabe stammt, ohne zu prüfen, ob diese Adresse zur eigenen Domain gehört. Der Angreifer schleust keinen Code ein und bricht nichts auf; er leiht sich lediglich den guten Namen Ihrer Domain, damit jemand anderswo ankommt.

Stellen Sie sich einen Wegweiser in Ihrer Eingangshalle vor, den Besucher selbst beschriften dürfen. Wer ihn liest, vertraut ihm, weil er in Ihrer Halle steht, auch wenn ein ganz anderes Gebäude darauf steht. Der Link, den das Opfer erhält, beginnt mit Ihrer Domain, und genau darauf schauen ein E-Mail-Filter, ein Linkscanner und das Auge des Empfängers.

In der Praxis heißt der Parameter returnUrl, next, redirect, url, dest oder continue, und er existiert fast immer aus gutem Grund: Wer ohne Sitzung auf eine geschützte Seite gerät, wird mit der ursprünglichen Seite in diesem Parameter zur Anmeldemaske geschickt. Das Problem beginnt erst, wenn der Parameter eine vollständige URL (Uniform Resource Locator) enthalten darf statt eines Pfades innerhalb Ihrer eigenen Anwendung.

Wie funktioniert ein Open-Redirect-Angriff?

Nehmen wir eine Anmelderoute, die den Benutzer nach der Authentifizierung auf die im Parameter genannte Seite zurückschickt.

Verwundbar:

app.post("/login", async (req, res) => {
  const user = await authenticate(req.body.username, req.body.password);
  if (!user) return res.status(401).render("login");

  req.session.userId = user.id;

  // Das Ziel stammt unmittelbar aus dem Query String
  res.redirect(req.query.returnUrl || "/dashboard");
});

Der Angreifer formuliert einen Link, der mit Ihrer eigenen Domain beginnt und deshalb an den meisten Filtern vorbeikommt:

GET /login?returnUrl=https://app-example.attacker.test/sitzung HTTP/1.1
Host: app.example.com

Das Opfer meldet sich bei Ihnen an und wird mit einem 302 an den Angreifer weitergeschickt. Dort wartet eine Kopie Ihrer Anmeldemaske mit dem Hinweis, die Sitzung sei abgelaufen. Das Opfer tippt sein Passwort erneut ein, diesmal bei jemand anderem.

Der erste Reflex ist eine Prüfung des ersten Zeichens: Beginnt der Wert mit einem Schrägstrich, wird es schon ein Pfad innerhalb der Anwendung sein. Diese Annahme trägt nicht, denn ein Browser zerlegt eine Adresse nach mehr Regeln, als Entwickler üblicherweise im Kopf haben:

• //evil.example ist kein Pfad, sondern eine protokollrelative URL. Der Browser ergänzt das Schema der aktuellen Seite und landet auf https://evil.example, obwohl der Wert mit einem Schrägstrich beginnt.
• /\evil.example und \/evil.example bewirken dasselbe, weil Browser einen Backslash in diesem Teil der Adresse wie einen Schrägstrich behandeln.
• https://app.example.com@evil.example/ führt zu evil.example. Alles vor dem At-Zeichen sind Benutzerinformationen und kein Host, für einen Menschen liest sich der Link jedoch wie Ihre Domain.
• https://app.example.com.evil.example/ unterläuft jede Prüfung, die nur nachsieht, ob Ihr Domainname irgendwo im Wert vorkommt.

Deutlich gefährlicher wird die Weiterleitung, sobald sie in einem OAuth-Ablauf steckt. Ein Authorization Server akzeptiert nur vorher registrierte redirect_uri-Werte, gerade damit kein Token bei einem Fremden landet. Enthält eine solche Adresse einen Open Redirect, ist die Registrierung wertlos: Der Authorization Code oder das Token gelangt ordnungsgemäß an Ihre Domain, und Ihre eigene Weiterleitung reicht ihn an den Angreifer weiter.

Die sichere Variante lässt den Benutzer keine Adresse mehr wählen, sondern einen Schlüssel, den die Anwendung serverseitig auf einen festen Pfad abbildet.

Sicher:

// Feste Ziele; der Benutzer sendet nur den Schlüssel
const RETURN_TARGETS = new Map([
  ["dashboard", "/dashboard"],
  ["rechnungen", "/konto/rechnungen"],
  ["berichte", "/berichte/uebersicht"]
]);

app.post("/login", async (req, res) => {
  const user = await authenticate(req.body.username, req.body.password);
  if (!user) return res.status(401).render("login");

  req.session.userId = user.id;
  const key = String(req.query.next ?? "");
  res.redirect(RETURN_TARGETS.get(key) ?? "/dashboard");
});

Ist eine feste Liste zu eng, akzeptieren Sie ausschließlich relative Pfade und prüfen Sie diese mit einem echten URL-Parser gegen Ihre eigene Origin:

const BASE = "https://app.example.com";

function sichererPfad(wert) {
  // Genau ein führender Schrägstrich, kein zweiter und kein Backslash dahinter
  if (typeof wert !== "string" || !/^\/[^/\\]/.test(wert)) return "/dashboard";

  const ziel = new URL(wert, BASE);
  return ziel.origin === BASE ? ziel.pathname + ziel.search : "/dashboard";
}

Welche Auswirkungen hat ein Open Redirect?

Für sich genommen bleiben die Auswirkungen überschaubar. Es fließen keine Daten ab, in Ihrer Datenbank ändert sich nichts, und der Angreifer erhält keinen Zugang zu Ihren Systemen. Was er gewinnt, ist Glaubwürdigkeit: Ein Phishing-Link, der mit der Domain Ihrer Bank oder Ihres Portals beginnt, wird häufiger angeklickt und kommt öfter durch einen Mail-Filter als ein Link auf eine unbekannte Adresse. In dieser Form lautet die Einstufung niedrig.

Auf mittel steigt sie, sobald die Weiterleitung in einer Kette sitzt. In einem OAuth-Ablauf kann sie einen Authorization Code oder ein Access Token nach außen tragen und damit zur vollständigen Kontoübernahme führen. Dasselbe gilt für einmalig gültige Links aus einer Mail zum Zurücksetzen des Passworts und für Tokens, die im Referer-Header zum nächsten Host mitreisen. Zeigt die Weiterleitung nicht auf einen externen Host, sondern auf javascript: oder data:, und wird sie clientseitig ausgeführt, liefert sie zusätzlich Cross-Site Scripting. Geschäftlich bedeutet das Rufschaden und im schlimmsten Fall einen Eintrag Ihrer Domain auf der Sperrliste eines Browsers oder Mail-Anbieters.

Wie erkennen Sie einen Open Redirect?

Beginnen Sie mit einer Bestandsaufnahme aller Stellen, an denen die Anwendung ein Ziel aus einer Eingabe bezieht. Suchen Sie im Code nach redirect, nach dem Setzen des Location-Headers und clientseitig nach Zuweisungen an location.href, nach location.replace und nach Meta-Refresh-Tags. Durchsuchen Sie anschließend Verkehr und Protokolle nach Parameternamen wie returnUrl, next, url und dest, auch in POST-Bodies.

Getestet wird, indem Sie den Wert durch eine Domain ersetzen, die Sie selbst kontrollieren, und die Antwort abrufen, ohne der Weiterleitung zu folgen, etwa mit curl -i, sodass Sie den Location-Header unmittelbar sehen. Wird der Wert abgewiesen, arbeiten Sie die Umgehungen von oben ab: den doppelten Schrägstrich, die Backslash-Varianten, das At-Zeichen und Ihren Domainnamen als Subdomain. Übersehen Sie die clientseitigen Fälle nicht, bei denen die Weiterleitung in JavaScript ausgeführt wird.

Scanner melden den Lehrbuchfall, erzeugen dabei aber viel Rauschen und übersehen Weiterleitungen hinter einer Anmeldemaske oder mitten in einem mehrstufigen Prozess. AssistSec prüft Open Redirects im Rahmen eines Penetrationstests und betrachtet dabei auch die Kette: ob sich die Weiterleitung nutzen lässt, um ein Token oder einen einmalig gültigen Link nach außen zu ziehen.

Wie verhindern Sie einen Open Redirect?

• Übergeben Sie Schlüssel statt Adressen. Lassen Sie den Benutzer eine kurze Kennung senden, die der Server auf einen festen Pfad abbildet. Was nicht in Ihrer Liste steht, führt zum Standardziel.
• Akzeptieren Sie ausschließlich relative Pfade. Weisen Sie jeden Wert mit Schema, Host oder At-Zeichen ab und normalisieren Sie das Ergebnis, bevor es in den Location-Header gelangt.
• Lehnen Sie doppelte Schrägstriche und jeden Backslash ausdrücklich ab. Das sind die beiden Umgehungen, die eine Prüfung des ersten Zeichens in praktisch jedem Browser überstehen.
• Validieren Sie mit einem URL-Parser, niemals mit einer Textsuche. Vergleichen Sie die vollständige Origin, also Schema, Host und Port zusammen.
• Behandeln Sie redirect_uri, Wiederherstellungslinks und SSO-Rücksprungpunkte als eigenen Fall. Vergleichen Sie sie exakt mit einem registrierten Wert und erlauben Sie weder Platzhalter noch freie Pfadanhänge.
• Zeigen Sie eine Zwischenseite, wenn eine externe Weiterleitung wirklich nötig ist. Nennen Sie das Ziel und lassen Sie den Besucher bestätigen.