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

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

Steven Bingler

Rowan Merewood

Примечание: Эта статья является частью серии статей об изменениях атрибутов cookie SameSite , в которую также входят:

• Понимание файлов cookie
• Объяснение использования файлов cookie SameSite
• Рецепты печенья SameSite

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

Ключевой термин: Это означает, что небезопасная HTTP-версия сайта, например, http ://website.example, и безопасная HTTPS-версия этого сайта, https ://website.example, теперь рассматриваются как межсайтовые .

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

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

Предупреждение: В долгосрочной перспективе планируется полностью отказаться от поддержки сторонних файлов cookie , заменив их альтернативами, обеспечивающими конфиденциальность. Установка параметра SameSite=None; Secure для файла cookie, разрешающего его передачу между различными схемами, должна рассматриваться лишь как временное решение в процессе перехода к полноценному HTTPS.

Эти изменения можно включить для тестирования как в 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-версии сайта. Создание этой дополнительной межсайтовой границы между схемами обеспечивает дополнительную защиту от подобных атак.

Типичные сценарии межсхемного взаимодействия

Ключевой термин: В приведенных далее примерах, где все URL-адреса имеют один и тот же регистрируемый домен, например, site.example, но разные схемы, например, http ://site.example против https ://site.example, они называются межсхемными .

Навигация

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

Межсистемная навигация с HTTP на HTTPS.

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Заблокировано	⛔ Заблокировано
SameSite=Lax	✓ Разрешено	✓ Разрешено
SameSite=None;Secure	✓ Разрешено	⛔ Заблокировано

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

Внимание: все основные браузеры блокируют активный смешанный контент , такой как скрипты или iframe. Кроме того, браузеры, включая Chrome и Firefox, работают над обновлением или блокировкой пассивного смешанного контента.

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

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

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

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

HTTP-страница, включающая в себя подресурс, работающий в разных схемах, через HTTPS.

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Заблокировано	⛔ Заблокировано
SameSite=Lax	⛔ Заблокировано	⛔ Заблокировано
SameSite=None;Secure	✓ Разрешено	⛔ Заблокировано

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

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

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

Внимание: В данном случае наилучшим решением будет убедиться, что и страница формы, и целевой ресурс используют защищенное соединение, например, HTTPS. Это особенно важно, если пользователь вводит в форму конфиденциальную информацию.

Передача форм между различными системами с HTTP на HTTPS.

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Заблокировано	⛔ Заблокировано
SameSite=Lax	⛔ Заблокировано	⛔ Заблокировано
SameSite=None;Secure	✓ Разрешено	⛔ Заблокировано

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

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

Начиная с Chrome 86, вкладка «Проблемы» в инструментах разработчика будет включать проблемы Schemeful Same-Site. Для вашего сайта могут быть выделены следующие проблемы.

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

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

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

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

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

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

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

На сайте Cookie Basics вы найдете руководства, демонстрации и инструменты, которые помогут вам понять, как работают файлы cookie.

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

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

Вполне возможно, что некоторые ваши ссылки и подресурсы по-прежнему ведут на небезопасные 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 .

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

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

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

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

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

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