Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Ratgeber

Unterschätzte Sicherheitslücke bei Facebook & Co: Wie böse ist target=_blank?

Über das simple HTML-Attribut target=_blank lassen sich Phishing-Angriffe durchführen. Das Problem ist bekannt, wurde aber jahrelang ignoriert. t3n erklärt, was dahintersteckt.

target=“_blank”: Wenn die aufgerufene Seite die aufrufende übernimmt

Man mag es kaum glauben, aber es stimmt tatsächlich. Über Links, die via target=_blank geöffnet werden, lassen sich Phishing-Angriffe starten. Das ist gar nicht kompliziert und schnell erklärt.

Jedes Mal, wenn ein neues Browserfenster aus einem bestehenden Browserfenster geöffnet wird, tritt das Objekt window.opener in Aktion. Dieses bedingt, dass der aufgerufenen Seite eine Referenz zur aufrufenden Seite übergeben wird. Diese Information kann die aufgerufene Seite nun etwa dazu nutzen, den Inhalt des aufrufenden Browserfensters zu manipulieren.

Ein Beispiel: Du surfst auf Facebook und klickst dort auf einen Link zu einer Seite mit echt total süßen Katzenbildchen. Der Betreiber dieser Seite sei in unserem Beispiel der Bösewicht. Denn der hat den Link selbst gepostet und so präpariert, dass bei einem Klick darauf nicht nur ein neuer Tab mit der Seite mit den echt total süßen Katzenbildchen geöffnet wird. Vielmehr wird gleichzeitig, und mit ziemlicher Sicherheit ohne dass du es bemerkst (ich habe es getestet), der Inhalt der aufrufenden Seite, also in diesem Falle Facebook, geändert. Das geschieht im Hintergrund. Du siehst ja schon der Seite mit den echt total süßen Katzenbildchen beim Öffnen zu.

Vorsicht: diese süßen Kätzchen könnten für ein perfides Spiel missbraucht worden sein. (Foto: Pixabay.vom)
Vorsicht: diese süßen Kätzchen könnten für ein perfides Spiel missbraucht worden sein. (Foto: Pixabay.com)

Der fiese Trick: Die Seite, der du vertraust, wurde geändert

Wenn du also jetzt den Tab mit den echt total süßen Katzenbildchen schließt und glaubst, du kämst zurück zu Facebook, weil du ja schließlich auch von dort gekommen bist, sitzt du in der Falle. Denn der Bösewicht hat eine Seite geöffnet, die der Login-Seite von Facebook täuschend ähnlich ist und nun deine Login-Daten abfragt.

Da du - wie gesagt - der Meinung bist, du kämst ja exakt von dort, wird dich die Frage nach den Login-Daten wahrscheinlich nicht mal sonderlich irritieren. Du wirst sie eingeben und dann vom Bösewicht tatsächlich wieder auf deinen Account weitergeleitet werden. Das ist einfach, denn der war ja gar nicht geschlossen worden. Du merkst nichts, der Bösewicht hat deine Facebook-Daten und wird nun versuchen, auch deine andere Dienste zu kompromittieren. Das ist die mit Abstand häufigste Art, wie Phisher Erfolg haben. Sie nehmen das Passwort und probieren es einfach bei allen möglichen anderen Diensten aus. Die meisten Menschen sind faul, so dass die Erfolgschance recht hoch ist.

Anders als manchmal behauptet, ist es nicht möglich, direkt JavaScript über den manipulierten Link auszuführen. Das wäre dann in der Tat keine Sicherheitslücke, sondern ein riesiger Daten-GAU.

Betroffen sind alle Websites, aber soziale Medien sind besonders anfällig

Neben Facebook ist auch Twitter von der Lücke betroffen. Twitter allerdings nur, wenn der Safari-Browser verwendet wird, Facebook in jedem Falle. Generell weisen alle Websites, die mit dem Attribut target=_blank arbeiten, die Lücke auf. Gefährlich wird es indes in der Regel nur da, wo sogenannter User-generated Content in großem Stil ins Spiel kommt. Damit sind gerade die sozialen Medien ein prädestiniertes Ziel dieser Angriffsmethode.

Prinzipiell ein guter Tipp, nur leider auf keiner mir bekannten Tastatur vorhanden. (Foto: Pixabay.com)
Prinzipiell ein guter Tipp, nur leider auf keiner mir bekannten Tastatur vorhanden. (Foto: Pixabay.com)

Effektiv dagegen tun kannst du nichts, denn es handelt sich um ein ganz normales Browser-Verhalten. So wären also die Browser-Hersteller aufgefordert, sich dieser Lücke anzunehmen. JavaScript abschalten wäre ein Option, führt aber dazu, dass du etwa Facebook nur noch über die mobile Website nutzen kannst.

Target=“_blank” - die Lösung ist ganz einfach, aber…

Neben den Browser-Herstellern stehen zudem die Seitenbetreiber in der Pflicht, denn über den simplen Linkzusatz rel="noopener noreferrer" setzt man das Objekt window.opener auf Null und der Rückgriff auf das aufrufende Fenster, respektive den aufrufenden Tab, ist unterbunden. Stellt diese nachträgliche Änderung einen Seitenbetreiber eventuell aufgrund der schieren Vielzahl der Links vor Probleme, kann er sich mit einem entsprechenden Script helfen, das dann allerdings, anders als etwa Twitters im Safari-Browser, auch funktonieren sollte.

Bei Facebook scheint noch ein ganz anderer Komplexitätsgrad erreicht zu sein. Denn dort sieht man sich offenbar überhaupt nicht in der Lage, das Problem schnell zu lösen. Gegenüber Tech.Mic gab Facebook zu Protokoll, dass man Kontakt zu den Browser-Herstellern aufgenommen habe, um denen bei einer entsprechenden Lösung zu helfen. Im übrigen seien leistungsfähige Algorithmen im Einsatz, die verdächtige URLs identifizieren und ausschalten können.

Na ja. Da hat Entwickler Ben Halpern aber andere Erfahrungen gemacht. Nach seinem Bericht hat Instagram die Sicherheitslücke bei sich übrigens direkt geschlossen.

Handlungsempfehlung: Wenn du in sozialen Netzen wie Facebook einen Link anklickst, sei dir der potenziellen Gefahr bewusst. Achte darauf, was mit der aufrufenden Seite passiert. Kommst du von echt total süßen Katzenbildchen zurück und findest dich vor einem angeblichen Facebook-Login wieder, dann lass die Finger davon und gib nicht deine Daten ein. Schließe stattdessen den Tab und rufe das Netzwerk in einem neuen Tab ganz neu auf.

Die verwendete Schreibweise des Attributs target=_blank ist so nicht richtig. Es fehlt ein Anführungszeichen vor dem Unterstrich und nach dem k. Leider nimmt WordPress das Attribut bei korrekter Schreibweise komplett aus dem Text, so dass ich mich im Sinne der Lesbarkeit des Textes entschieden habe, mit der Falschschreibung zu leben.

Bitte beachte unsere Community-Richtlinien

7 Reaktionen
BWelzel

Gibt es jetzt eine Kategorie: "Basiswissen für Nichtwisser" bei T3N? Bereits der Titel ist auf SPON-Niveau, die Begründung "habe ich selbst getestet" dann schon fast wieder witzig.

Wie wäre es mit einem Artikel über die gigantische Sicherheitslücke welche vor dem Bildschirm sitzt?

Fakt ist: Es gibt in diesem Fall gar keine technische "Sicherheitslücke". Nur ein Nutzer der seine Zugangsdaten einfach irgendwo eingibt. Es ist doch absolut egal wie ich auf eine Seite komme, bevor ich mein Passwort auf die Reise schicke muss ich mir erst einmal sicher sein wer auf der Gegenseite sitzt. Der Artikel ist nach meiner Meinung einfach nur Click-Bait, Hype und für T3N schlicht unwürdig...

Der Artikel hat dennoch etwas Gutes. Er nimmt ein Problem vorweg, was in Zukunft akut werden könne: das Web App Manifest des w3c (https://w3c.github.io/manifest/) und der gigantisch Denkfehler im Zusammenhang mit "display modes" und standalone. Ich wette das auf uns eine Welle aus Facebook und Twitter Web-Apps zukommt, welche durch geschicktes manipulieren von Links auf mobilen Geräten massenweise Zugangsdaten erbeuten werden. Und da liegt dann wirklich eine Sicherheitslücke (im Konzept) vor...

Antworten
Christian

HTML5 Attribute können sehr wohl ohne Anführungszeichen geschrieben werden solang sie keine ,=,",',` oder Leerzeichen beinhalten. Somit ist die Schreibweise target=_blank richtig - wenn auch nicht optimal.

Antworten
Christian

Die kommetarfunktion verschluckt leider kleiner und größer als Zeichen - die gehören auch noch in die Liste der nicht erlaubten Zeichen.

Antworten
Oink

D.h. window.opener ist das Sicherheitsrisiko, nicht target=_blank. Hier sind eindeutig die Browserhersteller im Zugzwang, wenn eine Fremddomain den opener beinflussen kann. Sollte kein Problem für die sein, da AJAX Request auch sowas haben und früher gab es dort auch keine Domain Einschränkung.

Das Problem wurde übrigens schon 2013 als Bug für Chrome gemeldet:
https://bugs.chromium.org/p/chromium/issues/detail?id=168988

Antworten
jztzjztjrhrtrt

Viel Aufregung um nichts.

Antworten
Dieter Petereit

Das Problem ist sogar noch viel älter als 2013. Aber erst die fortschreitende JavaScriptisierung des Web und das sprunghafte Ansteigen des user-generated Content macht es zum echten Risiko. Weshalb ich es übrigens auch im Beitrag erwähnte.

Antworten
Rene Woerz

"Hier sind eindeutig die Browserhersteller im Zugzwan" - und genau die scheißen darauf :D https://sites.google.com/site/bughunteruniversity/nonvuln/phishing-with-window-opener

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.