8. Security Considerations (Sicherheitsüberlegungen)

Die Same-Origin-Policy ist einer der Eckpfeiler der Sicherheit für viele User-Agents, einschließlich Webbrowser. Historisch haben einige User-Agents andere Sicherheitsmodelle ausprobiert, einschließlich Taint-Tracking und Exfiltrationsprävention, aber diese Modelle erwiesen sich zu dieser Zeit als schwierig zu implementieren (obwohl es in jüngster Zeit ein erneutes Interesse an der Wiederbelebung einiger dieser Ideen gibt).

Die Bewertung der Sicherheit der Same-Origin-Policy ist schwierig, da das Origin-Konzept selbst eine so zentrale Rolle in der Sicherheitslandschaft spielt. Der begriffliche Ursprung selbst ist nur eine Isolationseinheit, unvollkommen wie die meisten Einheitskonzepte. Dennoch gibt es einige systemische Schwächen, die unten diskutiert werden.

8.1 Reliance on DNS (Abhängigkeit von DNS)

In der Praxis stützt sich die Same-Origin-Policy auf das Domain Name System (DNS) für die Sicherheit, da viele häufig verwendete URI-Schemata wie http DNS-basierte Benennungsautoritäten verwenden. Wenn DNS teilweise oder vollständig kompromittiert ist, könnte die Same-Origin-Policy die von Anwendungen benötigten Sicherheitseigenschaften nicht bereitstellen.

Einige URI-Schemata wie https sind resistenter gegen DNS-Kompromittierung, da User-Agents andere Mechanismen wie Zertifikate verwenden, um die Quelle von Inhalten zu überprüfen, die von diesen URIs abgerufen werden. Andere URI-Schemata wie das chrome-extension-URI-Schema (siehe Abschnitt 4.3 von [CRX]) verwenden eine öffentliche-Schlüssel-basierte Benennungsautorität und sind vollständig gegen DNS-Kompromittierung gesichert.

Das Web-Origin-Konzept isoliert Inhalte, die von verschiedenen URI-Schemata abgerufen werden; dies ist wesentlich zur Eindämmung der Auswirkungen einer DNS-Kompromittierung.

8.2 Divergent Units of Isolation (Divergierende Isolationseinheiten)

Im Laufe der Zeit sind mehrere Technologien auf das Web-Origin-Konzept als praktische Isolationseinheit konvergiert. Viele heute verwendete Technologien wie Cookies [RFC6265] stammen jedoch aus der Zeit vor dem modernen Web-Origin-Konzept. Diese Technologien haben oft unterschiedliche Isolationseinheiten, was zu Schwachstellen führt.

Eine Alternative besteht darin, nur die "registrierungskontrollierte" Domain anstelle des vollständig qualifizierten Domainnamens als Isolationseinheit zu verwenden (z.B. "example.com" anstelle von "www.example.com"). Diese Praxis ist aus mehreren Gründen problematisch und wird NICHT EMPFOHLEN:

Der Begriff der "registrierungskontrollierten" Domain ist eine Funktion der menschlichen Praxis um DNS herum und keine Eigenschaft von DNS selbst. Beispielsweise betreiben viele Gemeinden in Japan öffentliche Registrierungen ziemlich tief in der DNS-Hierarchie. Es gibt weit verbreitete "Public-Suffix-Listen", aber diese Listen sind schwer aktuell zu halten und variieren zwischen Implementierungen.
Diese Praxis ist inkompatibel mit URI-Schemata, die keine DNS-basierte Benennungsautorität verwenden. Wenn beispielsweise ein gegebenes URI-Schema öffentliche Schlüssel als Benennungsautoritäten verwendet, ist der Begriff eines "registrierungskontrollierten" öffentlichen Schlüssels etwas inkohärent. Schlimmer noch, einige URI-Schemata wie nntp verwenden gepunktete Delegation in die entgegengesetzte Richtung von DNS (z.B. alt.usenet.kooks), und andere verwenden DNS, präsentieren aber die Labels in umgekehrter üblicher Reihenfolge (z.B. com.example.www).

Bestenfalls ist die Verwendung "registrierungskontrollierter" Domains URI-Schema- und implementierungsspezifisch. Schlimmstenfalls können Unterschiede zwischen URI-Schemata und Implementierungen zu Schwachstellen führen.

8.3 Ambient Authority (Umgebungsautorität)

Bei Verwendung der Same-Origin-Policy gewähren User-Agents Autorität an Inhalte basierend auf deren URI und nicht basierend darauf, welche Objekte der Inhalt bezeichnen kann. Diese Entkopplung von Bezeichnung und Autorität ist ein Beispiel für Umgebungsautorität und kann zu Schwachstellen führen.

Betrachten Sie beispielsweise Cross-Site-Scripting in HTML-Dokumenten. Wenn ein Angreifer Skriptinhalte in ein HTML-Dokument einschleusen kann, werden diese Skripte mit der Autorität des Origin des Dokuments ausgeführt, wodurch möglicherweise das Skript Zugriff auf vertrauliche Informationen wie die medizinischen Aufzeichnungen des Benutzers erhält. Wenn jedoch die Autorität des Skripts auf die Objekte beschränkt wäre, die das Skript bezeichnen kann, würde der Angreifer keinen Vorteil durch das Einschleusen des Skripts in ein von einem Dritten gehostetes HTML-Dokument erlangen.

8.4 IDNA Dependency and Migration (IDNA-Abhängigkeit und -Migration)

Die Sicherheitseigenschaften der Same-Origin-Policy können entscheidend von Details des vom User-Agent verwendeten IDNA-Algorithmus abhängen. Insbesondere könnte ein User-Agent einige internationalisierte Domainnamen (z.B. solche, die das Zeichen U+00DF enthalten) auf unterschiedliche ASCII-Darstellungen abbilden, je nachdem, ob der User-Agent IDNA2003 [RFC3490] oder IDNA2008 [RFC5890] verwendet.

Die Migration von einem IDNA-Algorithmus zu einem anderen könnte eine Reihe von Sicherheitsgrenzen neu zeichnen, potenziell neue Sicherheitsgrenzen errichten oder, schlimmer noch, Sicherheitsgrenzen zwischen zwei sich gegenseitig misstrauenden Entitäten niederreißen. Das Ändern von Sicherheitsgrenzen ist riskant, da die Kombination zweier sich gegenseitig misstrauender Entitäten im selben Origin einer erlauben könnte, die andere anzugreifen.