Наборы связанных веб-сайтов

Наборы связанных веб-сайтов — это механизм для определения набора связанных сайтов, которые используют доверенный контент. В результате браузеры могут предоставлять по умолчанию доступ к файлам cookie третьих сторон и неразделенному состоянию для этих сайтов, когда они содержат вставленный контент из других членов набора, без необходимости запроса разрешения пользователя через API доступа к хранилищу Storage Access API.

Рассмотрим ситуации, когда у вас есть ряд связанных веб-сайтов с разными доменными именами, и вы хотите предоставить сайтам доступ к файлам cookie третьих сторон и неразделенному состоянию при загрузке в контексте третьей стороны внутри других связанных сайтов (т.е., вставленных в <iframe>). Типичные примеры использования:

• Сайты приложений: Одно приложение может быть развернуто на нескольких сайтах, чтобы пользователи могли беспрепятственно переходить между ними в одной сессии.
• Сайты бренда: Набор брендовых активов может быть сосредоточен на одном сайте, но затем развернут на нескольких доменах, включая данные сеанса, связанные с пользовательскими предпочтениями, настройками и т. д.

Доступ к файлам cookie третьих сторон и неразделенному состоянию обычно блокируется политиками браузера. Но можно обойти это с помощью API доступа к хранилищу — см. Использование API доступа к хранилищу для получения подробной информации.

Связанные веб-сайты — это механизм постепенного улучшения, который работает вместе с API доступа к хранилищу. Поддерживающие браузеры предоставляют доступ к файлам cookie третьих сторон и неразделенному состоянию между веб-сайтами в одном наборе без необходимости прохождения обычного процесса запроса разрешения пользователя, как только будет вызван Document.requestStorageAccess() (или Document.requestStorageAccessFor()). Это приводит к более удобному пользовательскому опыту для пользователей сайтов в наборе.

Следует учитывать, что:

• Только Chrome Document.requestStorageAccessFor() метод (который позволяет сайтам верхнего уровня запрашивать доступ к хранилищу от имени вставленного контента источника) поддерживается только для доменов в наборе связанных веб-сайтов. См. Использование API доступа к хранилищу для примера.
• Когда Chrome впервые поддержал стандартный API доступа к хранилищу (то есть, методы Document.hasStorageAccess() и Document.requestStorageAccess()), сайтам, совершающим вызовы, необходимо было быть частью набора связанных веб-сайтов. Сейчас это больше не требуется.

Набор связанных веб-сайтов состоит из одного основного сайта и до пяти связанных сайтов.

Набор представляется структурой 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"]
      }
    }
  ]
}

Чтобы использовать набор, его JSON необходимо добавить в файл related_website_sets.JSON, доступный на GitHub-репозитории наборов связанных веб-сайтов, после чего Chrome получит список наборов для применения поведения RWS.

Каждый сайт в наборе также должен предоставлять файл .well-known по адресу /.well-known/related-website-set.json, который служит для проверки структуры набора и взаимосвязей между сайтами в наборе.

Файл .well-known основного сайта должен явно указывать полную структуру набора. https://primary1.com в приведенном выше примере потребовался бы файл https://primary1.com/.well-known/related-website-set.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"]
  }
}

Каждый вспомогательный и сервисный сайт должен указать свой основной сайт в файле .well-known. Каждый сайт, не являющийся основным, в приведенном выше примере (например, https://associateA.com) потребовал бы файл /.well-known/related-website-set.json следующего вида:

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

Полные сведения о процессе, синтаксисе JSON и других требованиях к представлению наборов см. в руководстве по представлению. Только администраторы доменов могут создавать наборы, содержащие их сайты.

Учитывайте, что файлы .well-known также проверяются в рамках процесса представления, поэтому их нужно разместить до отправки связанного набора.

После активации набора:

• Запросы от сайтов в наборе (через Document.requestStorageAccess()) для доступа к файлам cookie третьих сторон и неразделенному состоянию, принадлежащим сайтам в наборе, автоматически предоставляются, и шаг подтверждения пользователем не требуется.
• Вызовы Document.requestStorageAccessFor() могут выполняться сайтами верхнего уровня в наборе для запроса доступа к файлам cookie третьих сторон для других сайтов в наборе.

RWS разработан с учетом безопасности. Было бы катастрофично, если бы злонамеренный сайт смог заявить о своей принадлежности к набору и получить связанные с этим привилегии. Рассмотрим теоретический злонамеренный сайт evilsite.example.com, и рассмотрим примеры атак, которые он может попытаться реализовать, но все они потерпят неудачу:

• evilsite.example.com: Если сайт, утверждающий, что он принадлежит к набору (i.e. путем указания основного сайта в файле .well-known ) не включен в представленный набор и/или файл .well-known основного сайта, он не получит преимуществ принадлежности к набору.
• evilsite.example.com: В процессе представления файлы .well-known, размещенные на сайтах, не являющихся основными, должны явно указывать основной сайт. Если этот основной сайт не соответствует представленному набору (т.е., если связанные/сервисные сайты ожидают другого основного сайта или не ожидают принадлежности к набору), представление будет отклонено.
• site1.example.com и site2.example.com преднамеренно включены в один набор, но site1.example.com перехватывается evilsite.example.com: Влияние атаки по перехвату сайта в рамках набора не хуже, чем обычно, после того как другие сайты будут соответствующим образом обновлены:
  • Обычный API доступа к хранилищу требует активного согласия со стороны вставленного сайта, поэтому site2.example.com может прекратить вызывать document.requestStorageAccess() при вставке в site1.example.com, избегая атаки CSRF.
  • Использование requestStorageAccessFor() требует CORS, поэтому site2.example.com может отказаться от ответа с соответствующими заголовками CORS, когда запросы сети поступают от site1.example.com, тем самым избегая атаки CSRF.

• Демонстрация наборов связанных веб-сайтов Related Website Sets demo показывает, как используется RWS.
• Также см. Использование API доступа к хранилищу.

Два браузерных вендора противостоят этому спецификации. Известные позиции следующие:

• Mozilla (Firefox): Отрицательно
• Apple (Safari): Отрицательно

• API доступа к хранилищу
• Наборы связанных веб-сайтов на developers.google.com (2023)
• Наборы связанных веб-сайтов: руководство для разработчиков на developers.google.com (2023)