Same-Origin-Policy

Die Same-Origin-Policy (SOP; deutsch „Gleiche-Herkunft-Richtlinie“) ist ein Sicherheitskonzept, das clientseitigen Skriptsprachen wie JavaScript und ActionScript, aber auch Cascading Style Sheets untersagt, auf Objekte (zum Beispiel Grafiken) zuzugreifen, die von einer anderen Webseite stammen oder deren Speicherort nicht der Origin entspricht. Sie stellt ein wesentliches Sicherheitselement in allen modernen Browsern und Webanwendungen zum Schutz vor Angriffen dar.

Geschichte

Die Same-Origin-Policy wurde 1996 von Netscape mit JavaScript in Netscape Navigator 2.0 eingeführt.^[1] Sie wurde von anderen Herstellern in deren JavaScript-Implementierungen bzw. proprietären Skriptsprachen, etwa JScript, übernommen.

Hintergrund

Den Hintergrund für die große Bedeutung der SOP bildet im Wesentlichen die Kombination aus zwei Tatsachen:

Skriptsprachen im Browser haben über das Document Object Model (DOM) direkten Zugriff auf die gesamte Kommunikation zwischen Browser und Web-Server. Dies beinhaltet sowohl das Auslesen als auch die Manipulation von Daten und betrifft neben dem Empfangen auch das Senden von Daten.
Das Vertrauensverhältnis zwischen Browser (bzw. Anwender) und verschiedenen Webseiten kann extrem unterschiedlich sein.

Daraus ergibt sich die Anforderung, dass keine Informationen aus einem Kontext (zum Beispiel der Verbindung des Browsers zu der Seite einer Bank) von einem Skript aus einem anderen Kontext zugreifbar oder manipulierbar sein dürfen. Um dies zu erreichen, wird beim Zugriff eines Skriptes auf ein Objekt einer Webseite die Herkunft (origin) von beiden verglichen.

Vergleich der Herkunft (origin)

Als Herkunft wird dabei die Kombination aus Protokoll (zum Beispiel HTTP oder HTTPS), Domain und Port in der URL definiert. Nur wenn alle drei gleich sind, gilt die SOP als erfüllt und der Skript-Zugriff ist möglich.

Beispiele

Ein in der Datei http://www.example.com/dir/page.html eingebettetes Skript versucht, auf ein Element in den folgenden Seiten zuzugreifen:

angesprochene URL	Ergebnis	Grund
http://www.example.com/dir/page2.html	Ja	selbes Protokoll, Host und Port
http://www.example.com/dir2/other.html	Ja	selbes Protokoll, Host und Port
http://username:password@www.example.com/dir2/other.html	Ja	selbes Protokoll, Host und Port
http://www.example.com:81/dir/other.html	Nein	selbes Protokoll und Host, aber anderer Port
https://www.example.com/dir/other.html	Nein	anderes Protokoll
http://en.example.com/dir/other.html	Nein	anderer Host
http://example.com/dir/other.html	Nein	anderer Host (genaue Übereinstimmung benötigt, hier ist eine Ausnahme möglich, s. u.)
http://v2.www.example.com/dir/other.html	Nein	anderer Host (genaue Übereinstimmung benötigt)
http://www.example.com:80/dir/other.html	—	Port eindeutig. Hängt von der Implementierung des Browsers ab.

Eine Ausnahme bilden Subdomains: Über eine spezielle DOM-Eigenschaft kann zum Beispiel ein Skript aus der Domain www.example.com den Kontext auf die übergeordnete Domain example.com setzen und damit auf Objekte dieser Domain zugreifen. Das gilt trotzdem nicht für den Zugriff auf andere Subdomains.^[2]

Grenzen und Probleme

Die Grenzen der Same-Origin-Policy sind in zweierlei Hinsicht von Bedeutung:

Die SOP ist als Sicherheitsmechanismus nicht ausreichend wirksam. Viele aktuelle Angriffsmethoden wie DNS Rebinding und Cross-Site Request Forgery zielen erfolgreich darauf ab, die SOP zu umgehen.
Andererseits sind die von der SOP gezogenen Grenzen in vielen Fällen unerwünscht. Insbesondere mit dem Aufkommen von Ajax-basierenden Anwendungen und Mashups gibt es legitimerweise den Wunsch, die Grenzen der SOP zu überschreiten. Eine Möglichkeit bietet das Cross-Origin Resource Sharing (CORS), das es einem Server erlaubt, gezielt zu bestimmen, welche Seiten trotz ihrer fremden Herkunft Zugriff auf die Antwort haben sollen. CORS muss vom Browser explizit unterstützt werden. CORS wird von allen relevanten Browsern unterstützt^[3].