3. Principles of the Same-Origin Policy (Prinzipien der Same-Origin-Policy)

Viele User-Agents führen Aktionen im Namen von entfernten Parteien durch. Beispielsweise folgen HTTP-User-Agents Weiterleitungen, die Anweisungen von entfernten Servern sind, und HTML-User-Agents stellen umfangreiche Document Object Model (DOM)-Schnittstellen für Skripte bereit, die von entfernten Servern abgerufen wurden.

Ohne ein Sicherheitsmodell könnten User-Agents Aktionen durchführen, die für den Benutzer oder andere Parteien schädlich sind. Im Laufe der Zeit sind viele webbezogene Technologien auf ein gemeinsames Sicherheitsmodell konvergiert, das umgangssprachlich als "Same-Origin-Policy" bekannt ist. Obwohl sich dieses Sicherheitsmodell weitgehend organisch entwickelt hat, kann die Same-Origin-Policy anhand einiger Schlüsselkonzepte verstanden werden. Dieser Abschnitt präsentiert diese Konzepte und gibt Ratschläge zur sicheren Verwendung dieser Konzepte.

3.1 Trust (Vertrauen)

Die Same-Origin-Policy spezifiziert Vertrauen durch URI. Beispielsweise bestimmen HTML-Dokumente mit einem URI, welches Skript ausgeführt werden soll:

<script src="https://example.com/library.js"></script>

Wenn ein User-Agent dieses Element verarbeitet, ruft der User-Agent das Skript unter dem angegebenen URI ab und führt das Skript mit den Privilegien des Dokuments aus. Auf diese Weise gewährt das Dokument alle Privilegien, die es besitzt, der durch den URI bezeichneten Ressource. Im Wesentlichen erklärt das Dokument, dass es der Integrität der von diesem URI abgerufenen Informationen vertraut.

Zusätzlich zum Importieren von Bibliotheken von URIs senden User-Agents auch Informationen an entfernte Parteien, die durch URI bezeichnet werden. Betrachten Sie beispielsweise das HTML-Formularelement:

<form method="POST" action="https://example.com/login">
 ... <input type="password"> ...
</form>

Wenn der Benutzer sein Passwort eingibt und das Formular absendet, sendet der User-Agent das Passwort an den durch den URI bezeichneten Netzwerk-Endpunkt. Auf diese Weise exportiert das Dokument seine geheimen Daten an diesen URI und erklärt im Wesentlichen, dass es der Vertraulichkeit der an diesen URI gesendeten Informationen vertraut.

3.1.1 Pitfalls (Fallstricke)

Beim Entwerfen neuer Protokolle, die die Same-Origin-Policy verwenden, stellen Sie sicher, dass wichtige Vertrauensunterschiede in URIs sichtbar sind. Wenn beispielsweise sowohl Transport Layer Security (TLS) als auch nicht-TLS-geschützte Ressourcen das "http"-URI-Schema verwenden (wie in [RFC2817]), könnte ein Dokument nicht angeben, dass es ein Skript nur über TLS abrufen möchte. Durch Verwendung des "https"-URI-Schemas können Dokumente anzeigen, dass sie mit Ressourcen interagieren möchten, die vor aktiven Netzwerkangreifern geschützt sind.

3.2 Origin (Ursprung)

Im Prinzip könnten User-Agents jeden URI als separate Schutzdomäne behandeln und eine ausdrückliche Zustimmung erfordern, damit Inhalte, die von einem URI abgerufen wurden, mit einem anderen URI interagieren können. Leider ist dieses Design für Entwickler umständlich, da Webanwendungen oft aus einer Reihe von Ressourcen bestehen, die zusammenarbeiten.

Stattdessen gruppieren User-Agents URIs in Schutzdomänen, die "Origins" (Ursprünge) genannt werden. Grob gesagt sind zwei URIs Teil desselben Origin (d. h. repräsentieren denselben Principal), wenn sie dasselbe Schema, denselben Host und denselben Port haben. (Siehe Abschnitt 4 für vollständige Details.)

F: Warum nicht einfach den Host verwenden?

A: Die Einbeziehung des Schemas in das Origin-Tupel ist für die Sicherheit wesentlich. Wenn User-Agents das Schema nicht einschließen würden, gäbe es keine Isolierung zwischen http://example.com und https://example.com, da beide denselben Host haben. Ohne diese Isolierung könnte jedoch ein aktiver Netzwerkangreifer Inhalte, die von http://example.com abgerufen wurden, korrumpieren und diese Inhalte dazu bringen, den User-Agent anzuweisen, die Vertraulichkeit und Integrität von Inhalten zu kompromittieren, die von https://example.com abgerufen wurden, wodurch der durch TLS [RFC5246] gebotene Schutz umgangen wird.

F: Warum den vollständig qualifizierten Hostnamen anstelle nur der "Top-Level"-Domain verwenden?

A: Obwohl DNS eine hierarchische Delegierung hat, variieren die Vertrauensbeziehungen zwischen Hostnamen je nach Bereitstellung. An vielen Bildungseinrichtungen können Studenten beispielsweise Inhalte unter https://example.edu/~student/ hosten, aber das bedeutet nicht, dass ein von einem Studenten erstelltes Dokument Teil desselben Origin sein sollte (d. h. dieselbe Schutzdomäne bewohnen sollte) wie eine Webanwendung zur Notenverwaltung, die unter https://grades.example.edu/ gehostet wird.

Die example.edu-Bereitstellung veranschaulicht, dass die Gruppierung von Ressourcen nach Origin nicht immer perfekt mit jedem Bereitstellungsszenario übereinstimmt. In dieser Bereitstellung bewohnt die Website jedes Studenten denselben Origin, was möglicherweise nicht wünschenswert ist. In gewissem Sinne ist die Origin-Granularität ein historisches Artefakt der Entwicklung des Sicherheitsmodells.

3.2.1 Examples (Beispiele)

Alle folgenden Ressourcen haben denselben Origin:

http://example.com/
http://example.com:80/
http://example.com/path/file

Jeder der URIs hat dieselben Schema-, Host- und Port-Komponenten.

Jede der folgenden Ressourcen hat einen anderen Origin als die anderen:

http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/

In jedem Fall unterscheidet sich mindestens eine der Schema-, Host- und Port-Komponenten von den anderen in der Liste.

3.3 Authority (Autorität)

Obwohl User-Agents URIs in Origins gruppieren, trägt nicht jede Ressource in einem Origin dieselbe Autorität (im Sicherheitssinne des Wortes "Autorität", nicht im Sinne von [RFC3986]). Beispielsweise ist ein Bild passiver Inhalt und trägt daher keine Autorität, was bedeutet, dass das Bild keinen Zugriff auf die Objekte und Ressourcen hat, die seinem Origin zur Verfügung stehen. Im Gegensatz dazu trägt ein HTML-Dokument die volle Autorität seines Origin, und Skripte innerhalb (oder importiert in) das Dokument können auf jede Ressource in seinem Origin zugreifen.

User-Agents bestimmen, wie viel Autorität einer Ressource gewährt werden soll, indem sie deren Medientyp untersuchen. Beispielsweise werden Ressourcen mit einem Medientyp von image/png als Bilder behandelt, und Ressourcen mit einem Medientyp von text/html werden als HTML-Dokumente behandelt.

Beim Hosten von nicht vertrauenswürdigen Inhalten (wie benutzergenerierten Inhalten) können Webanwendungen die Autorität dieses Inhalts einschränken, indem sie dessen Medientyp einschränken. Beispielsweise ist das Bereitstellen von benutzergenerierten Inhalten als image/png weniger riskant als das Bereitstellen von benutzergenerierten Inhalten als text/html. Natürlich integrieren viele Webanwendungen nicht vertrauenswürdige Inhalte in ihre HTML-Dokumente. Wenn dies nicht sorgfältig durchgeführt wird, riskieren diese Anwendungen, die Autorität ihres Origin an die nicht vertrauenswürdigen Inhalte weiterzugeben, eine Schwachstelle, die allgemein als Cross-Site-Scripting bekannt ist.

3.3.1 Pitfalls (Fallstricke)

Beim Entwerfen neuer Teile der Webplattform sollten Sie darauf achten, Ressourcen unabhängig vom Medientyp keine Autorität zu gewähren. Viele Webanwendungen stellen nicht vertrauenswürdige Inhalte mit eingeschränkten Medientypen bereit. Eine neue Webplattform-Funktion, die diesen Inhalten Autorität gewährt, riskiert, Schwachstellen in bestehende Anwendungen einzuführen. Bevorzugen Sie stattdessen die Gewährung von Autorität an Medientypen, die bereits die volle Autorität des Origin besitzen, oder an neue Medientypen, die speziell entwickelt wurden, um die neue Autorität zu tragen.

Um mit Servern kompatibel zu bleiben, die falsche Medientypen liefern, verwenden einige User-Agents "Content Sniffing" und behandeln Inhalte so, als hätten sie einen anderen Medientyp als den vom Server bereitgestellten Medientyp. Wenn dies nicht sorgfältig durchgeführt wird, kann Content Sniffing zu Sicherheitslücken führen, da User-Agents möglicherweise Medientypen mit niedriger Autorität, wie Bilder, die Privilegien von Medientypen mit hoher Autorität, wie HTML-Dokumente, gewähren [SNIFF].

3.4 Policy (Richtlinie)

Allgemein gesprochen isolieren User-Agents verschiedene Origins und erlauben kontrollierte Kommunikation zwischen Origins. Die Details, wie User-Agents Isolierung und Kommunikation bereitstellen, variieren je nach mehreren Faktoren.

3.4.1 Object Access (Objektzugriff)

Die meisten vom User-Agent bereitgestellten Objekte (auch als Anwendungsprogrammierschnittstellen oder APIs bekannt) sind nur für denselben Origin verfügbar. Insbesondere können von einem URI abgerufene Inhalte auf Objekte zugreifen, die mit von einem anderen URI abgerufenen Inhalten verbunden sind, wenn und nur wenn die beiden URIs zum selben Origin gehören, d. h. dasselbe Schema, denselben Host und denselben Port haben.

Es gibt einige Ausnahmen von dieser allgemeinen Regel. Beispielsweise sind einige Teile der Location-Schnittstelle von HTML über Origins hinweg verfügbar (z. B. um das Navigieren in anderen Browsing-Kontexten zu ermöglichen). Als weiteres Beispiel ist die postMessage-Schnittstelle von HTML explizit über Origins hinweg sichtbar, um die Cross-Origin-Kommunikation zu erleichtern. Das Offenlegen von Objekten für fremde Origins ist gefährlich und sollte nur mit großer Vorsicht durchgeführt werden, da dadurch diese Objekte potenziellen Angreifern ausgesetzt werden.

3.4.2 Network Access (Netzwerkzugriff)

Der Zugriff auf Netzwerkressourcen variiert je nachdem, ob sich die Ressourcen im selben Origin wie der Inhalt befinden, der versucht, darauf zuzugreifen.

Im Allgemeinen ist das Lesen von Informationen aus einem anderen Origin verboten. Ein Origin ist jedoch berechtigt, bestimmte Arten von Ressourcen zu verwenden, die von anderen Origins abgerufen wurden. Beispielsweise ist ein Origin berechtigt, Skripte auszuführen, Bilder zu rendern und Stylesheets aus jedem Origin anzuwenden. Ebenso kann ein Origin Inhalte aus einem anderen Origin anzeigen, wie z. B. ein HTML-Dokument in einem HTML-Frame. Netzwerkressourcen können auch zulassen, dass andere Origins ihre Informationen lesen, beispielsweise unter Verwendung von Cross-Origin Resource Sharing [CORS]. In diesen Fällen wird der Zugriff typischerweise pro Origin gewährt.

Das Senden von Informationen an einen anderen Origin ist erlaubt. Das Senden von Informationen über das Netzwerk in beliebigen Formaten ist jedoch gefährlich. Aus diesem Grund beschränken User-Agents Dokumente darauf, Informationen mithilfe bestimmter Protokolle zu senden, wie z. B. in einer HTTP-Anfrage ohne benutzerdefinierte Header. Die Erweiterung der Menge zulässiger Protokolle, beispielsweise durch Hinzufügen von Unterstützung für WebSockets, muss sorgfältig durchgeführt werden, um die Einführung von Schwachstellen zu vermeiden [RFC6455].

3.4.3 Pitfalls (Fallstricke)

Immer wenn User-Agents einem Origin erlauben, mit Ressourcen aus einem anderen Origin zu interagieren, laden sie Sicherheitsprobleme ein. Beispielsweise gibt die Fähigkeit, Bilder aus einem anderen Origin anzuzeigen, deren Höhe und Breite preis. Ebenso führt die Fähigkeit, Netzwerkanfragen an einen anderen Origin zu senden, zu Cross-Site-Request-Forgery-Schwachstellen [CSRF]. User-Agent-Implementierer wägen diese Risiken jedoch oft gegen die Vorteile ab, die Cross-Origin-Interaktion zu erlauben. Beispielsweise würde ein HTML-User-Agent, der Cross-Origin-Netzwerkanfragen blockiert, seinen Benutzern das Folgen von Hyperlinks verhindern, eine Kernfunktion des Webs.

Beim Hinzufügen neuer Funktionen zur Webplattform kann es verlockend sein, einem Ressource ein Privileg zu gewähren, dieses Privileg aber einer anderen Ressource im selben Origin vorzuenthalten. Das Vorenthalten von Privilegien auf diese Weise ist jedoch ineffektiv, da die Ressource ohne das Privileg das Privileg normalerweise trotzdem erhalten kann, da User-Agents Ressourcen innerhalb eines Origin nicht isolieren. Stattdessen sollten Privilegien Origins als Ganzes gewährt oder vorenthalten werden (anstatt zwischen einzelnen Ressourcen innerhalb eines Origin zu unterscheiden) [BOFGO].

3.5 Conclusion (Fazit)

Die Same-Origin-Policy verwendet URIs, um Vertrauensbeziehungen zu bezeichnen. URIs werden in Origins gruppiert, die Schutzdomänen repräsentieren. Einigen Ressourcen in einem Origin (z. B. aktiven Inhalten) wird die volle Autorität des Origin gewährt, während anderen Ressourcen im Origin (z. B. passiven Inhalten) die Autorität des Origin nicht gewährt wird. Inhalten, die die Autorität ihres Origin tragen, wird Zugriff auf Objekte und Netzwerkressourcen innerhalb ihres eigenen Origin gewährt. Diesen Inhalten wird auch begrenzter Zugriff auf Objekte und Netzwerkressourcen anderer Origins gewährt, aber diese Cross-Origin-Privilegien müssen sorgfältig entworfen werden, um Sicherheitslücken zu vermeiden.