Websicherheit und CSP-Header

Heute habe ich mal wieder etwas mit JavaScript herumgespielt, dabei ist mir aufgefallen, dass es möglich ist einen redirect auf einer Fremden URL zu erzeugen.  Natürlich bin ich nicht der Erste, dem das auffällt, ich wollte aber trotzdem mal darüber schreiben, da es für mich in Sachen Sicherheitsvorkehrungen im Web eine Art Weckruf war.
Wie das geht? Es ist recht simpel, wenn ich mittels js eine beliebige Webseite in einem neuen Tab öffne, kann ich an diese Funktion eine weite Funktion mit Timeout anhängen. Innerhelb dieses Timeouts kann ich nun einen redirect auf eine völlig andere Adresse veranlassen. Der redirect kann dabei beliebig lange nach Öffnen des neuen Tabs erfolgen. Tatsächlich kann der redirect sogar stattfinden, wenn auf dem neuen Tab die Domain gewechselt wurde.  Wenn allerdings bevor der Timeout abgelaufen ist, der Ursprungstab geschlossen wurde, findet selbstverständlich kein redirect statt, da zusammen mit dem Tab auch sein Storage sowie alle laufenden Prozesse beendet werden.

<button id="button" onclick="link()">Auf zur besten Webseite</button>

<script>

var link = function(){
    var a = window.open("https://mcglobus.de")

    setTimeout(function(){a.location = "https://nicht-mcglobus.lol"}, 80000)
}
</script>

Natürlich habe ich mich direkt gefragt, wie so etwas missbraucht werden könnte. Eine denkbare Möglichkeit wäre es, dass eine bösartige Website einen Link so modifiziert, dass dieser erst die tatsächliche Website öffnet. Der Nutzer ist jetzt also auf seiner Zielseite, beispielsweise Twitter. Hier meldet er sich an, oder ist bereits angemeldet, er schöpft keinen verdacht, da es sich ja tatsächlich um die echte Webseite handelt. Eine halbe Stunde später findet der redirect statt und der Nutzer wird auf eine täuschend echt aussehende Twitter Anmeldemaske umgeleitet, nichts ahnend meldete er sich erneut an und wird von der Fake Anmeldeseite wieder an das echte Twitter weitergeleitet.

Für die allermeisten Nutzer wäre so ein Angriff wohl nicht zu erkennen und wahrscheinlich würde ich auch darauf hereinfallen.

Als Nächstes stellte ich mir drei Fragen - Was kann man tun, damit man selbst kein Opfer wird? Kann ich als Webseiten Betreiber das irgendwie verhindern? Und warum geht das überhaupt?

Zur ersten Frage:

Zum einen lohnt es sich bei links immer beim hovern unten links auf das Ziel des Links zu schauen. Steht da eine falsche Domain nicht klicken, steht da keine Domain, so wird der redirect, oder der neue Tab mit js erzeugt, also Obacht. Aber was mache ich auf dem Tablet oder Smartphone? Hier gibt es keinen hover, der mir zeigt, wo es hingeht. Gute Frage, keine Antwort. Die einzige Lösung ist wohl immer genau aufzupassen, wo ich meine, Anmeldedaten eingebe. Zudem bleibt ein Passwortmanager eine starke Empfehlung, zum einen weil bei einem Abfangen meiner Anmeldedaten immer nur ein Account hops geht, zum anderen, weil ein Passwortmanager das Passwort bei einer Falschen Domain nicht vorschlagen würde. Wenn der Passwortmanager das Passwort nicht vorschlägt, lohnt sich ein genauer Blick auf die Domain, es ist mit hoher Wahrscheinlichkeit nicht die richtige.

Zur zweiten Frage:

Ja, es gibt Möglichkeiten. Ich kann einen redirect mit "beforeunload" abfangen, das würde aber auch jeden Link auf der Webseite betreffen → also eine etwas nervige Lösung.

window.addEventListener("beforeunload", function(event) {
  event.returnValue = "Alaaarmm! Alaaarm!";
});

Natürlich gibt es auch eine vernünftige Lösung, und zwar den Content-Security-Policy-Header (CSP-Header). Tja und spätestens da hat es dann auch bei mir wieder geklingelt, natürlich war dieser mir bereits ein begriff, aber hatte ich ihn je absichtlich implementiert? Nein. Die einzigen Male, in denen ich mich je mit Themen wie CSP-Header oder CORS beschäftigt hatte, waren wenn dadurch etwas nicht funktionierte. Mit CSP-Header ist die lösung dann recht simpel, einfach angeben dass nur meine seite JS ausführen darf und gegebenenfalls noch ein paar weitere Domains auf die Whitelist setzen - Fertig.

Content-Security-Policy: default-src 'self' mcglobus.de; script-src 'self';

Die meisten professionellen Webseiten wie Google oder Twitter machen das natürlich auch. Aber es gibt genug, die es nicht tun, meine eigenen gehörten in der Vergangenheit oft genug dazu. Ein Grund für mehr, mich mit dem Thema Sicherheit ernsthafter zu befassen.

Zur dritten Frage:

Die Möglichkeit, dass ein Tab den anderen beeinflussen kann, ist auf die Funktionsweise von JavaScript zurückzuführen. JavaScript wurde so entwickelt, dass es auf allen offenen Tabs und Fenstern einer Webseite ausgeführt werden kann. Das bedeutet, dass, wenn ein Tab eine Funktion ausführt, diese Funktion auch auf anderen Tabs ausgeführt werden kann, da alle Tabs denselben Kontext teilen.

Dieses Verhalten ist nicht per se ein Sicherheitsproblem, da JavaScript in einer sicheren Sandbox-Umgebung ausgeführt wird und somit nicht auf das Betriebssystem zugreifen kann. Allerdings können bösartige Skripte auf andere Tabs zugreifen und vertrauliche Daten wie Passwörter, Cookies und andere sensible Informationen stehlen.

Aus diesem Grund wurden verschiedene Sicherheitsmaßnahmen wie Content Security Policy (CSP) und Cross-Origin Resource Sharing (CORS) entwickelt, um die Sicherheit im Web zu verbessern und die Möglichkeit zu verringern, dass bösartige Skripte auf andere Tabs zugreifen können.