Схема на том же сайте

Определение «same-site» развивается, чтобы включить схему URL, поэтому ссылки между версиями сайта HTTP и HTTPS теперь считаются межсайтовыми запросами. Обновитесь до HTTPS по умолчанию, чтобы избежать проблем, где это возможно, или читайте дальше, чтобы узнать подробности о том, какие значения атрибута SameSite необходимы.

Стивен Бинглер
Steven Bingler
GitHub
Роуэн Меревуд

Schemeful Same-Site изменяет определение (веб)сайта с просто регистрируемого домена на схему + регистрируемый домен. Вы можете найти больше подробностей и примеров в Understanding "same-site" и "same-origin" .

Хорошая новость: если ваш сайт уже полностью обновлен до HTTPS, то вам не о чем беспокоиться. Для вас ничего не изменится.

Если вы еще не полностью обновили свой сайт, то это должно быть приоритетом. Однако, если есть случаи, когда посетители вашего сайта будут переходить между HTTP и HTTPS, то некоторые из этих распространенных сценариев и связанное с ними поведение файлов cookie SameSite описаны далее в этой статье.

Вы можете включить эти изменения для тестирования как в Chrome, так и в Firefox.

  • В Chrome 86 включите about://flags/#schemeful-same-site . Отслеживайте ход выполнения на странице статуса Chrome .
  • Начиная с Firefox 79, установите network.cookie.sameSite.schemeful в true через about:config . Отслеживайте прогресс с помощью Bugzilla issue .

Одной из основных причин изменения SameSite=Lax в качестве значения по умолчанию для файлов cookie была защита от подделки межсайтовых запросов (CSRF) . Однако небезопасный HTTP-трафик по-прежнему предоставляет возможность сетевым злоумышленникам подделывать файлы cookie, которые затем будут использоваться в защищенной HTTPS-версии сайта. Создание этой дополнительной межсайтовой границы между схемами обеспечивает дополнительную защиту от этих атак.

Распространенные сценарии перекрестных схем

Навигация между версиями веб-сайта с кросс-схемой (например, ссылка с http ://site.example на https ://site.example) ранее позволяла отправлять файлы cookie SameSite=Strict . Теперь это рассматривается как кросс-сайтовая навигация, что означает, что файлы cookie SameSite=Strict будут заблокированы.

Навигация между схемами, запускаемая путем перехода по ссылке с незащищенной HTTP-версии сайта на защищенную HTTPS-версию. SameSite=Strict cookies заблокированы, SameSite=Lax и SameSite=None; Защищенные cookies разрешены.
Кросс-схемная навигация с HTTP на HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Заблокировано ⛔ Заблокировано
SameSite=Lax ✓ Разрешено ✓ Разрешено
SameSite=None;Secure ✓ Разрешено ⛔ Заблокировано

Загрузка подресурсов

Любые внесенные вами изменения следует рассматривать только как временное решение, пока вы работаете над обновлением до полноценного HTTPS.

Примерами подресурсов являются изображения, фреймы и сетевые запросы, выполненные с помощью XHR или Fetch.

Загрузка кросс-схемного подресурса на странице ранее позволяла отправлять или устанавливать файлы cookie SameSite=Strict или SameSite=Lax . Теперь это обрабатывается так же, как и любой другой сторонний или кросс-сайтовый подресурс, что означает, что любые файлы cookie SameSite=Strict или SameSite=Lax будут заблокированы.

Кроме того, даже если браузер разрешает загрузку ресурсов из небезопасных схем на защищенной странице, все файлы cookie будут заблокированы при таких запросах, поскольку сторонние или межсайтовые файлы cookie требуют Secure .

Межсхемный подресурс, полученный в результате включения ресурса из безопасной HTTPS-версии сайта в небезопасную HTTP-версию. Файлы cookie SameSite=Strict и SameSite=Lax заблокированы, а SameSite=None; безопасные файлы cookie разрешены.
HTTP-страница, включающая кросс-схемный подресурс через HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Заблокировано ⛔ Заблокировано
SameSite=Lax ⛔ Заблокировано ⛔ Заблокировано
SameSite=None;Secure ✓ Разрешено ⛔ Заблокировано

Отправка формы

Публикация между версиями веб-сайта с разными схемами ранее позволяла отправлять файлы cookie с SameSite=Lax или SameSite=Strict . Теперь это рассматривается как межсайтовый POST — могут быть отправлены только файлы cookie SameSite=None . Вы можете столкнуться с этим сценарием на сайтах, которые по умолчанию представляют небезопасную версию, но обновляют пользователей до безопасной версии при отправке формы входа или оформления заказа.

Как и в случае с подресурсами, если запрос поступает из защищенного контекста (например, HTTPS) в незащищенный контекст (например, HTTP), то все файлы cookie в этих запросах будут заблокированы, поскольку сторонние или межсайтовые файлы cookie требуют Secure .

Отправка формы между схемами, полученная в результате отправки формы на незащищенной HTTP-версии сайта на защищенную HTTPS-версию. Файлы cookie SameSite=Strict и SameSite=Lax заблокированы, а SameSite=None; Защищенные файлы cookie разрешены.
Кросс-схемная отправка форм с HTTP на HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Заблокировано ⛔ Заблокировано
SameSite=Lax ⛔ Заблокировано ⛔ Заблокировано
SameSite=None;Secure ✓ Разрешено ⛔ Заблокировано

Как я могу протестировать свой сайт?

Инструменты и сообщения для разработчиков доступны в Chrome и Firefox.

Начиная с Chrome 86, вкладка Issue в DevTools будет включать Schemeful Same-Site issues. Вы можете увидеть следующие проблемы, выделенные для вашего сайта.

Проблемы с навигацией:

  • «Перейдите полностью на HTTPS, чтобы продолжить отправку файлов cookie при запросах на тот же сайт» — предупреждение о том, что файлы cookie будут заблокированы в будущей версии Chrome.
  • «Перейти полностью на HTTPS, чтобы файлы cookie отправлялись при запросах с одного сайта» — предупреждение о том, что файл cookie заблокирован .

Проблемы с загрузкой подресурсов:

  • «Перейти полностью на HTTPS, чтобы продолжить отправку файлов cookie на подресурсы того же сайта» или «Перейти полностью на HTTPS, чтобы продолжить установку файлов cookie подресурсами того же сайта» — предупреждения о том, что файлы cookie будут заблокированы в будущей версии Chrome.
  • «Migrate complete to HTTPS to have cookies send to same-site subresources» или «Migrate complete to HTTPS to allow cookies be set by same-site subresources» — предупреждения о том, что cookie заблокирован . Последнее предупреждение может также появляться при отправке формы.

Более подробную информацию можно найти в разделе Советы по тестированию и отладке для Schemeful Same-Site .

Начиная с Firefox 79, при установке network.cookie.sameSite.schemeful в значение true через about:config консоль будет отображать сообщение о проблемах Schemeful Same-Site. Вы можете увидеть следующее на своем сайте:

  • «Файл cookie cookie_name вскоре будет рассматриваться как межсайтовый cookie для http://site.example/ поскольку схема не совпадает».
  • «Файл cookie cookie_name был обработан как межсайтовый по отношению к http://site.example/ поскольку схема не совпадает».

Часто задаваемые вопросы

Мой сайт уже полностью доступен по протоколу HTTPS. Почему я вижу проблемы в DevTools моего браузера?

Возможно, некоторые из ваших ссылок и подресурсов по-прежнему указывают на небезопасные URL-адреса.

Один из способов решения этой проблемы — использовать HTTP Strict-Transport-Security (HSTS) и директиву includeSubDomain . С HSTS + includeSubDomain даже если одна из ваших страниц случайно включает небезопасную ссылку, браузер автоматически будет использовать безопасную версию.

Что делать, если я не могу перейти на HTTPS?

Хотя мы настоятельно рекомендуем вам обновить свой сайт полностью до HTTPS, чтобы защитить своих пользователей, если вы не можете сделать это самостоятельно, мы предлагаем поговорить с вашим хостинг-провайдером, чтобы узнать, может ли он предложить такую ​​возможность. Если вы размещаете сайт самостоятельно, то Let's Encrypt предоставляет ряд инструментов для установки и настройки сертификата. Вы также можете рассмотреть возможность перемещения своего сайта за CDN или другой прокси-сервер, который может обеспечить соединение HTTPS.

Если это все еще невозможно, попробуйте ослабить защиту SameSite для затронутых файлов cookie.

  • В случаях, когда блокируются только файлы cookie SameSite=Strict можно снизить уровень защиты до Lax .
  • В случаях, когда блокируются как Strict , так и Lax файлы cookie, а ваши файлы cookie отправляются на защищенный URL-адрес (или устанавливаются с него), вы можете снизить уровень защиты до None .
    • Этот обходной путь не сработает , если URL, на который вы отправляете файлы cookie (или устанавливаете их с него), небезопасен. Это происходит потому, что SameSite=None требует атрибута Secure для файлов cookie, что означает, что эти файлы cookie не могут быть отправлены или установлены через незащищенное соединение. В этом случае вы не сможете получить доступ к этим файлам cookie, пока ваш сайт не будет обновлен до HTTPS.
    • Помните, что это временно, поскольку со временем сторонние файлы cookie будут полностью исключены.

Как это повлияет на мои файлы cookie, если я не указал атрибут SameSite ?

Файлы cookie без атрибута SameSite обрабатываются так, как если бы они указывали SameSite=Lax , и то же самое поведение кросс-схемы применяется к этим файлам cookie. Обратите внимание, что временное исключение для небезопасных методов все еще применяется, см. смягчение Lax + POST в Chromium SameSite FAQ для получения дополнительной информации.

Как это влияет на WebSockets?

Подключения WebSocket по-прежнему будут считаться соединениями одного сайта, если они имеют такой же уровень безопасности, что и страница.

На том же сайте:

  • wss:// соединение с https://
  • ws:// соединение с http://

Межсайтовый:

  • wss:// соединение с http://
  • ws:// соединение с https://

Фото Джулиссы Капдевильи на Unsplash