Verbundene Website-Sets

Warnung: Diese Funktion wird derzeit von zwei Browser-Anbietern abgelehnt. Siehe den Abschnitt Standards-Positionen unten für Einzelheiten zur Ablehnung.

Verbundene Website-Sets sind ein Mechanismus zur Definition einer Reihe von verwandten Websites, die vertrauenswürdige Inhalte teilen. Dadurch können Browser diesen Websites standardmäßig Zugriff auf Drittanbieter-Cookies und unpartitionierten Zustand gewähren, wenn sie in anderen Mitgliedern des Sets eingebettet sind, ohne dass Benutzer über eine Berechtigungsaufforderung Zugriff auf die Storage Access API gewähren müssen.

Konzepte und Verwendung

Betrachten wir Situationen, in denen Sie eine Reihe verwandter Websites mit verschiedenen Domainnamen haben und den Website-Inhalten Zugriff auf Drittanbieter-Cookies und unpartitionierten Status gewähren möchten, wenn sie in einem Drittanbieterkontext innerhalb anderer verwandter Websites geladen werden (d.h. eingebettet in ein <iframe>). Typische Anwendungsfälle sind:

  • App-Sites: Eine einzelne Anwendung kann über mehrere Websites bereitgestellt werden, um Benutzern eine nahtlose Navigation zwischen ihnen in einer einzigen Sitzung zu ermöglichen.
  • Marken-Sites: Eine Reihe von Markenressourcen kann auf einer einzelnen Site enthalten sein, jedoch über mehrere Domains bereitgestellt werden, einschließlich Sitzungsdaten zu Benutzerpräferenzen, Anpassungen usw.

Der Zugriff auf Drittanbieter-Cookies und unpartitionierten Zustand wird häufig durch Browser-Richtlinien blockiert. Sie können dies jedoch mithilfe der Storage Access API umgehen — siehe Using the Storage Access API für Einzelheiten.

Verbundene Websites sind ein Mechanismus zur schrittweisen Verbesserung, der zusammen mit der Storage Access API funktioniert. Unterstützende Browser gewähren Drittanbieter-Cookie- und unpartitionierten Zustandszugriff zwischen Websites im gleichen Set ohne den üblichen Workflow zur Benutzerberechtigungsaufforderung zu durchlaufen, sobald Document.requestStorageAccess() (oder Document.requestStorageAccessFor()) aufgerufen wird. Dies führt zu einer benutzerfreundlicheren Erfahrung für Benutzer von Websites im Set.

Sie sollten bedenken, dass:

Wie funktioniert RWS?

Ein verbundenes Website-Set besteht aus einer primären Site und bis zu fünf zugeordneten Sites.

JSON-Struktur

Ein Set wird durch eine JSON-Struktur dargestellt. Ein hypothetisches Beispiel ist wie folgt:

json
{
  "sets": [
    {
      "contact": "email address or group alias if available",
      "primary": "https://primary1.com",
      "associatedSites": [
        "https://associateA.com",
        "https://associateB.com",
        "https://associateC.com"
      ],
      "serviceSites": ["https://servicesiteA.com"],
      "rationaleBySite": {
        "https://associateA.com": "Explanation of affiliation with primary site",
        "https://associateB.com": "Explanation of affiliation with primary site",
        "https://associateC.com": "Explanation of affiliation with primary site",
        "https://serviceSiteA.com": "Explanation of service functionality support"
      },
      "ccTLDs": {
        "https://associateA.com": [
          "https://associateA.ca",
          "https://associateA.co.uk"
        ],
        "https://associateB.com": [
          "https://associateB.ru",
          "https://associateB.co.kr"
        ],
        "https://primary1.com": ["https://primary1.co.uk"]
      }
    }
  ]
}

Hinweis: Die Erklärungen der Zugehörigkeit müssen eine klare Beschreibung enthalten, wie die Zugehörigkeit zur primären Site den Benutzern dieser Sites präsentiert wird.

Um ein Set zu nutzen, muss sein JSON der related_website_sets.JSON-Datei im Related Website Sets GitHub-Repository hinzugefügt werden, die Chrome dann konsumiert, um die Liste der Sets zu erhalten, auf die das RWS-Verhalten angewendet werden soll.

.well-known Dateien

Jede Site im Set muss auch eine .well-known-Datei unter /.well-known/related-website-set.json bereitstellen, die dazu dient, die Set-Struktur und die Beziehung zwischen den Sites im Set zu verifizieren.

Die .well-known-Datei der primären Site muss explizit die vollständige Set-Struktur auflisten. https://primary1.com im obigen Beispiel würde eine https://primary1.com/.well-known/related-website-set.json Datei benötigen, die folgendermaßen aussieht:

json
{
  "primary": "https://primary1.com",
  "associatedSites": [
    "https://associateA.com",
    "https://associateB.com",
    "https://associateC.com"
  ],
  "serviceSites": ["https://servicesiteA.com"],
  "rationaleBySite": {
    "https://associateA.com": "Explanation of affiliation with primary site",
    "https://associateB.com": "Explanation of affiliation with primary site",
    "https://associateC.com": "Explanation of affiliation with primary site",
    "https://serviceSiteA.com": "Explanation of service functionality support"
  },
  "ccTLDs": {
    "https://associateA.com": [
      "https://associateA.ca",
      "https://associateA.co.uk"
    ],
    "https://associateB.com": [
      "https://associateB.ru",
      "https://associateB.co.kr"
    ],
    "https://primary1.com": ["https://primary1.co.uk"]
  }
}

Jede zugeordnete und Dienst-Site muss ihre primäre Site in einer .well-known-Datei angeben. Jede nicht-primäre Site im obigen Beispiel (z.B. https://associateA.com) würde eine /.well-known/related-website-set.json Datei benötigen, die so aussieht:

json
{
  "primary": "https://primary1.com"
}

Für vollständige Details zum Prozess, zur JSON-Syntax und zu anderen Anforderungen für das Einreichen von Sets siehe die Einreichungsrichtlinien. Nur Domain-Administratoren können ein Set erstellen, das ihre Sites enthält.

Beachten Sie, dass die .well-known-Dateien auch als Teil des Einreichungsprozesses überprüft werden, daher müssen sie vor der Einreichung des zugeordneten Sets vorbereitet werden.

Vorteile eines aktiven Sets

Sobald ein Set aktiv ist:

  • Anfragen von Sites im Set (über Document.requestStorageAccess()), um Zugriff auf Drittanbieter-Cookies und unpartitionierten Zustand zu erhalten, die Sites im Set gehören, werden automatisch gewährt, und kein Schritt zur Benutzerberechtigung ist erforderlich.
  • Document.requestStorageAccessFor() Anrufe können von Top-Level-Sites im Set ausgeführt werden, um Drittanbieter-Cookie-Zugriff für andere Sites im Set anzufordern.

RWS-Sicherheit

RWS wurde mit Sicherheitsaspekten im Sinn entworfen. Es wäre katastrophal, wenn eine böswillige Site in der Lage wäre, zu behaupten, Teil eines Sets zu sein, und die damit verbundenen Privilegien zu erlangen. Betrachten wir eine theoretische böswillige Site, evilsite.example.com, und untersuchen einige Angriffsbeispiele, die sie versuchen könnte, die alle scheitern würden:

  • evilsite.example.com versucht, eine assoziierte Site in einem anderen Set zu sein: Wenn eine Site behauptet, in einem Set zu sein (d.h. indem sie eine primäre in einer .well-known-Datei auflistet), jedoch nicht im Set-Einreichung und/oder der primären .well-known-Datei enthalten ist, erhält sie nicht die Vorteile, Teil des Sets zu sein.
  • evilsite.example.com beansprucht, eine primäre Site zu sein, und reicht ein Set ein, das einige potentielle Opfer-Sites enthält: Der Einreichungsprozess erfordert, dass .well-known-Dateien, die von nicht primären Sites gehostet werden, ihre primäre explizit auflisten. Wenn diese primäre nicht mit der Set-Einreichung übereinstimmt (d.h. wenn die assoziierten/Dienst-Sites eine andere primäre erwarten oder überhaupt nicht in einem Set erwartet werden), wird die Einreichung abgelehnt.
  • site1.example.com und site2.example.com sind absichtlich im gleichen Set, aber site1.example.com wird von evilsite.example.com gehijackt: Die Auswirkungen eines Site-Hijacking-Angriffs innerhalb eines Sets sind nicht schlimmer als sie normalerweise wären, sobald die anderen Sites entsprechend aktualisiert werden:
    • Die reguläre Storage Access API erfordert eine aktive Einwilligung durch die eingebettete Site, also kann site2.example.com aufhören, document.requestStorageAccess() aufzurufen, wenn sie in site1.example.com eingebettet ist, um einen CSRF-Angriff zu vermeiden.
    • Die Verwendung von requestStorageAccessFor() erfordert CORS, also könnte site2.example.com entscheiden, nicht mit den entsprechenden CORS-Headern zu antworten, wenn Netzwerk-Anfragen von site1.example.com kommen, um so einen CSRF-Angriff zu vermeiden.

Beispiele

Spezifikationen

Specification
User Agent Interaction with Related Website Sets

Standards-Positionen

Zwei Browser-Anbieter lehnen diese Spezifikation ab. Bekannte Positionen sind wie folgt:

Siehe auch