Dipl.-Inform. Carsten Eilers

Ein von Wang Jing beschriebener "Covert Redirect" liegt vor, wenn eine Webanwendung einen Parameter für eine Weiterleitung verwendet, ohne dessen Inhalt ausreichend zu prüfen. Das erinnert Sie an einen "Open Redirect", bei dem das Ziel der Weiterleitung gar nicht geprüft wird? Das ist völlig richtig, denn ein "Covert Redirect" ist im Grunde ein "Open Redirect, über Bande gespielt": Die vom "Covert Redirect" betroffene Website leitet den Benutzer auf eine Website weiter, die selbst von einem "Open Redirect" betroffen ist. Und von dieser Website aus wird er dann zur bösartigen Website weitergeleitet.

Das lässt sich mit einem Beispiel besser erklären. Beteiligt sind drei Websites:

1. www.covert.example enthält die "Covert Redirect"-Schwachstelle: Das Skript
   /covertredirect.php?ziel=
   leitet den Benutzer zu einer vertrauenswürdigen Website weiter.
2. www.open.example ist so eine vertrauenswürdige Website und enthält die "Open Redirect"-Schwachstelle: Das Skript
   /openredirect.php?ziel=
   leitet den Benutzer zu jeder Website weiter.
3. www.boese.example ist die bösartige Website des Angreifers.

Für einen Angriff muss der Angreifer sein Opfer dazu bewegen, den Link

http://www.covert.example/covertredirect.php?ziel=
                 www.open.example/openredirect.php?ziel=
                 www.boese.example/angriff.php

anzuklicken. www.covert.example prüft das Ziel der Weiterleitung nicht ausreichend und erkennt nur das erlaubte Ziel www.open.example, zu dem der Benutzer weiter geleitet wird. Von dort wird er dann sofort zu www.boese.example weiter geleitet.

Zwei Wege führen zum Ziel

Für die Prüfung des Weiterleitungsziels hat Wang Jing zwei Methoden besonders herausgestellt.

Manche Websites vergleichen das Redirect-Ziel mit einer Whitelist zulässiger Domains. Ist das Weiterleitungsziel auf der Liste, wird die Weiterleitung durchgeführt. Das Beispiel zeigt im Grunde so einen Fall: www.covert.example/covertredirect.php prüft, ob www.open.example auf der Whitelist steht. Da das der Fall ist, wird der Benutzer zu
www.open.example/openredirect.php?ziel=www.boese.example/angriff.php
weiter geleitet. Und von dort wird er dann sofort zu www.boese.example/angriff.php weiter geleitet.

Beispiel für Websites, die diese Methode nutzen, sind ebay.com und wordpress.com.

Andere Websites prüfen das Vorhandensein eines Tokens, dass den vertrauenswürdigen Weiterleitungszielen zugewiesen wurde. Ist das Token im URL vorhanden und der Domain des Ziels zugewiesen, wird die Weiterleitung durchgeführt. Im obigen Beispiel sähe der URL dann zum Beispiel so aus:

http://www.covert.example/covertredirect.php?ziel=
                 www.open.example/openredirect.php?ziel=
                 www.boese.example/angriff.php
                 &token=[covert.example zugewiesener Tokenwert]

www.covert.example/covertredirect.php prüft, ob das Token im Parameter token der Domain www.open.example zugewiesen wurde. Da dass hier der Fall ist, wird der Benutzer zu
www.open.example/openredirect.php?ziel=www.boese.example/angriff.php
weitergeleitet, von wo aus der sofort zu www.boese.example/angriff.php weiter geleitet wird.

Beispiele für betroffene Websites, die diese Methode nutzen, sind amazon.com und nytimes.com.

Wie verhindert man die Angriffe?

Die Lösung ist ganz einfach: Die Webanwendungen dürfen keine Weiterleitungen zu Websites erlauben, die selbst wiederum offene Redirects erlauben. Das klingt einfach, ist es aber nicht, denn

1. weiß man vielleicht gar nicht, dass das Weiterleitungsziel eine "Open Redirect"-Schwachstelle enthält und
2. muss man vielleicht sogar zu Websites weiterleiten, die bewusst einen offenen Redirect verwenden.

Am einfachsten ist es, wenn man sagt, wer an der Schwachstelle Schuld ist muss sie auch beseitigen. Darüber, wer Schuld an der Schwachstelle ist, kann man aber prima streiten.
Ist es die vom "Covert Redirect" betroffene Website www.covert.example, da sie zur von der "Open Redirect" betroffenen Website www.open.example weiter leitet?
Oder ist es www.open.example, da es ohne die "Open Redirect"-Schwachstelle ja gar kein "Covert Redirect" gäbe?

Ich tendiere zur Antwort "Das kommt darauf an!". Und zwar darauf, ob das "Open Redirect" eine Schwachstelle oder eine absichtliche Funktion ist.
Ist es eine Schwachstelle, kann man www.open.example durchaus vorwerfen, auch www.covert.example quasi mit ins Verderben zu reißen.
Ist es ein Feature, muss sich www.covert.example vorwerfen lassen, dass sie ja den Redirect zur offenen Redirect-Funktion zulässt. Immerhin könnte sie die ja verhindern und schon gäbe es den "Covert Redirect" nicht mehr.

Am sichersten fährt man natürlich, wenn man gar keine Redirects zu anderen Websites zulässt. Lassen die sich gar nicht vermeiden, sollte man zumindest versuchen, die Ziele so weit wie irgend möglich einzugrenzen. Außerdem ist es eine gute Idee, sämtliche Parameter vor der Weiterleitung zu löschen, siehe auch den Text zum "Covert Redirect" in Verbindung mit OAuth 2.0 und OpenID.

Carsten Eilers