Was ist die Same-Origin-Policy (SOP)?

Um eine höhere Sicherheit zu gewährleisten, sind moderne Webanwendungen und Browser mit verschiedenen Mechanismen und Funktionen ausgestattet. Eine davon ist die sogenannte Same-Origin-Policy (SOP), eine von Browsern durchgesetzte Regel zum Schutz der Datenexposition von einer Website zur anderen.

Im Folgenden erfahren Sie mehr über die Same-Origin-Policy.

Wie ist die Herkunft definiert?

m Zusammenhang mit dem Internet ist eine Herkunft die Kombination aus einem URI-Schema (Uniform Resource Identifier), einem Hostnamen (oder einer Domäne) und einer Portnummer. 

Nehmen wir also die Hauptseite unseres Blogs: https://crashtest-security.com/de/vulnerability-testing-blog/.

Hier ist das Schema HTTPS, der Host ist crashtest-security.com, und die Portnummer ist 443 (die Standard-Portnummer für HTTPS). 

Moderne Browser würden jede Seite mit demselben Schema, Host und Port als dieselbe Herkunft betrachten. Weicht hingegen eine dieser Angaben ab, wird die Herkunft nicht als dieselbe angesehen. 

Auf der folgenden Website (http://company-website.com/) finden Sie einige Beispiele für Seiten, die als gleichwertig angesehen werden und andere, die nicht als gleichwertig angesehen werden.

Ob die Herkunft derselbe ist oder nicht, wirkt sich darauf aus, wie Browser Anfragen zwischen verschiedenen Herkünften behandeln.

Was ist der Zweck der Same-Origin-Policy?

Der Zweck der SOP besteht darin, zu regeln, ob und wie Herkünfte und ihre Ressourcen interagieren. Sie wird auf Browserebene implementiert, um zu gewährleisten, dass keine unerlaubte herkunftsübergreifende Kommunikation stattfindet, die dazu führen könnte, dass ein bösartiges Skript auf einer Website Zugang zu sensiblen Daten auf einer anderen erhält. Oder anders ausgedrückt: Es verhindert die Wiederverwendung authentifizierter Benutzersitzungen auf verschiedenen Websites und den Lesezugriff auf Antworten unterschiedlicher Herkunft.

Wenn ein Client eine Anfrage an eine Herkunft sendet, enthält die Anfrage Authentifizierungsdetails wie Sitzungscookies, die für diese Herkunft relevant sind. Stellen Sie sich vor, ein Benutzer wird dazu verleitet, eine Website mit einer irreführenden Domäne zu besuchen, die einen Iframe enthält, der den Inhalt der eigentlichen Website lädt. Der Benutzer meldet sich dann an und sendet dabei die erforderlichen Authentifizierungs-Cookies über die bösartige Website an die tatsächliche Domäne. 

Gäbe es keine Same-Origin-Policy, könnte die Antwort der eigentlichen Website von Angreifern gelesen werden. Damit könnten sie über das Document Object Model (DOM) der eigentlichen Website auf die Daten des Nutzers zugreifen und in dessen Namen Anfragen stellen. Dank der Same-Origin-Policy ist dies nicht möglich.

Was verbietet und erlaubt die Same-Origin-Policy?

Die SOP wird manchmal fälschlicherweise so verstanden, dass sie alle Arten von herkunftsübergreifenden Anfragen blockiert. Wäre dies der Fall, wäre es nicht möglich, Ressourcen zwischen verschiedenen Herkünften bereitzustellen, und es gäbe keinen Grund für die Existenz von Content Delivery Networks (CDN) oder sogar dem Web. Die SOP verbietet auch nicht, dass die Herkünfte untereinander Anfragen stellen oder zwischen den Herkünften schreiben (z. B. Formulare übermitteln). 

Im Großen und Ganzen erlaubt die SOP das Einbetten von Ressourcen, nicht aber das Lesen zwischen den Herkünften. Der Unterschied zwischen dem Einbetten und dem Lesen besteht darin, dass eine eingebettete Ressource kopiert wird und von ihrer Herkunft unabhängig wird, während beim Lesen die externe Herkunft erhalten bleibt. 

Zulässige Formen der Einbettung sind HTML-Tags wie iframe, script, img, video, audio, link, object, embed und form. Dieser Teil des POS kann manchmal eine Quelle von Sicherheitslücken sein und zu Clickjacking-Angriffen führen.

Es gibt Unterschiede zwischen den Browsern, wie die Richtlinien- und Same-Origin-Prüfungen umgesetzt werden. Die SOP-Anwendung variiert zwischen Technologien und Ressourcen wie Cookies, JavaScript, DOM und anderen APIs. Nachfolgend sind einige Beispiele dafür aufgeführt, was SOP in der Regel verbietet:

• Cookies können nicht an eine Seite mit einer anderen Herkunft gesendet werden, obwohl dies in diesem Fall nur für Seiten mit anderen Domains/Subdomains gilt, während Schema und Port nicht überprüft werden.
• AJAX-Anfragen wie XMLHttpRequest sind unter SOP nicht erlaubt, obwohl dies möglich ist, wenn Cross-Origin Resource Sharing (CORS) implementiert ist.
• Selbst wenn JavaScript eingebettet ist, kann es keine Inhalte auf einer Website mit einer anderen Herkunft lesen.

Kann SOP Cyber-Angriffe verhindern?

Obwohl SOP sehr nützlich ist, um verschiedene Arten von Angriffen zu verhindern, hat es seine Grenzen und kann nicht alle herkunftsübergreifenden Bedrohungen aufhalten. 

Die wichtigsten Bedrohungen im Zusammenhang mit der Ausnutzung von Herkunftsschwachstellen sind Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) und die oben erwähnten Clickjacking-Angriffe.

• Beim Cross-Site Scripting wird bösartiger Code auf der Client-Seite eingeschleust, um den Browser zu zwingen, bestimmte Aktionen durchzuführen und Sitzungen zu stehlen.
• Cross-Site-Request-Forgery beruht darauf, dass ein Benutzer eine bösartige Website mit eingebettetem Code besucht, der dann beginnt, ohne sein Wissen Anfragen im Namen des Benutzers zu generieren. 
• Clickjacking ist die Verwendung von transparenten Schaltflächen über einem eingebetteten Iframe. Diese Schaltflächen verweisen auf bösartige Websites, über die die Sitzungen und Daten der Benutzer gestohlen oder gekapert werden können.

Um diese Angriffe zu verhindern, sollten Sie am besten zusätzliche Maßnahmen ergreifen, die nicht in der SOP enthalten sind. Auf den Seiten, die mit diesen Angriffen in Verbindung stehen, erfahren Sie mehr über deren Vermeidung!

Lockerung der Same-Origin-Policy

Die strengen Regeln der Richtlinie können bei Websites mit mehreren Subdomains oder wenn zwei Domains miteinander interagieren sollen, zu Schwierigkeiten führen. Es gibt Möglichkeiten, die herkunftsübergreifende Kommunikation in solchen Situationen auf kontrollierte Weise zu ermöglichen.

Cross-Origin Resource Sharing (CORS)

Eine gängige Methode zur Lockerung von SOP ist die gemeinsame Nutzung von Ressourcen (CORS). CORS ermöglicht die gemeinsame Nutzung externer Ressourcen durch den HTTP Access-Control-Allow-Origin Response Header. 

Ein Browser sendet einen Request-Header an eine andere Herkunft, und der Server gibt die erforderlichen Anweisungen in seinem Response-Header. Wenn gemäß den Anweisungen die Anfrage von dieser Herkunft zulässig ist, erlaubt der Browser die Serverantwort. Wenn nicht, wird die Antwort vom Browser nicht freigegeben. 

CORS bietet auch die Möglichkeit, eine Preflight-Anfrage, auch bekannt als OPTIONS-Anfrage, zu stellen. Bei der Preflight-Anfrage wird der Server gefragt, ob er dem Client erlaubt, einen domänenübergreifenden Aufruf durchzuführen, insbesondere einen, der Header oder andere Methoden enthält, die Daten verändern können. Wenn der Server dies zulässt, kann die eigentliche Anfrage erfolgen.

JavaScript document.domain 

JavaScript ermöglicht die Interaktion zwischen verschiedenen Herkünften, wenn auch in eingeschränkter Form. Diese Option gilt für Herkünfte wie Subdomains, die sich eine Domänenhierarchie teilen. Sie ermöglicht es ihnen, ihre Herkunft als die Domäne oder Superdomäne zu deklarieren, unter der sie sich befinden. Dies gilt auch für Skripte, die auf solchen Seiten arbeiten.

Mit dieser Methode können beispielsweise Subdomains wie store.example.com und login.example.com als ihre Domäne deklariert werden:

document.domain = "example.com";

Die Website unter example.com muss dieselbe Einstellung verwenden, um den Prozess abzuschließen. Sobald dies geschehen ist, ist die gemeinsame Nutzung von Ressourcen zwischen diesen Herkünften aktiviert. 

Beachten Sie, dass die Port- und Schemabeschränkungen unter SOP in diesem Szenario nicht aufgehoben werden und weiterhin übereinstimmen müssen.

JSON mit Auffüllung (JSONP)

JSONP bietet ebenfalls eine Möglichkeit, SOP zu umgehen. Diese Umgehung nutzt das <script>-Tag und die Tatsache, dass die Richtlinie es zulässt, dass JavaScript Ressourcen aus verschiedenen Domänen abruft und ausführt. 

Daher können herkunftsübergreifende Ressourcen gemeinsam genutzt werden, indem das src-Attribut des Tags verwendet wird, das die URL einer externen Skriptdatei angibt. Auf diese Weise kann eine Ressource geladen werden, die eine JSONP-Nutzlast zurückgibt. Die Ressource wird dann über die enthaltene Callback-Funktion verarbeitet und kann abgerufen werden.

FAQ

Warum ist die Same-Origin-Policy erforderlich?

SOP ist eine Browser-Policy, die Domains vor herkunftsübergreifenden Interferenzen schützt. Sie regelt den Lesezugriff auf Ressourcen einer Domain von einer anderen aus über JavaScript. Die Richtlinie verhindert nicht, dass Ressourcen eingebettet werden, so dass eine Interaktion zwischen Domänen möglich ist, wenn auch auf bestimmte, begrenzte Weise.

Reicht SOP aus, um herkunftsübergreifende Angriffe zu verhindern?

Nein, die Richtlinie kann Angriffe wie Cross-Site Scripting, Cross-Site Request Forgery oder Clickjacking nicht verhindern. Sie bietet jedoch einen guten Schutz gegen herkunftsübergreifende Versuche, authentifizierte Sitzungen wiederzuverwenden und Ressourcen von einem anderen Herkunft zu lesen.

Kann SOP gelockert werden?

Ja, es gibt mehrere Ansätze, die es ermöglichen, die Richtlinie zu lockern und Ressourcen zwischen Domänen gemeinsam zu nutzen. Dazu gehören CORS, Dokument, Domäne, JSONP und andere.