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

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

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

Schemeful Same-Site изменяет определение (веб)сайта с просто регистрируемого домена на схему + регистрируемый домен. Более подробную информацию и примеры можно найти в разделе Понимание «одного сайта» и «того же происхождения» .

Хорошая новость: если ваш сайт уже полностью обновлен до 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 .

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

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

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

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

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

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

Примеры подресурсов включают изображения, iframe и сетевые запросы, выполненные с помощью 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, вкладка «Проблема» в DevTools будет включать проблемы «Схема на одном и том же сайте». Вы можете увидеть следующие проблемы, выделенные для вашего сайта.

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

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

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

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

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

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

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

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

Тот же сайт:

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

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

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

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