Определение «один и тот же сайт» развивается и включает схему URL-адресов, поэтому ссылки между версиями сайта HTTP и HTTPS теперь считаются межсайтовыми запросами. Перейдите на HTTPS по умолчанию, чтобы избежать проблем, где это возможно, или прочитайте подробности о том, какие значения атрибута SameSite необходимы.
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 | 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
.
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 | 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 будет полностью прекращено.
- Этот обходной путь не сработает, если URL-адрес, на который вы отправляете файлы cookie (или устанавливаете их), небезопасен. Это связано с тем, что
Как это повлияет на мои файлы cookie, если я не указал атрибут SameSite
?
Файлы cookie без атрибута SameSite
обрабатываются так, как если бы для них был указан SameSite=Lax
, и к этим файлам cookie применяется такое же поведение перекрестной схемы. Обратите внимание, что временное исключение для небезопасных методов по-прежнему применяется. Дополнительную информацию см. в разделе «Устранение последствий Lax + POST» в FAQ по Chromium SameSite
.
Как это влияет на WebSockets?
Соединения WebSocket по-прежнему будут считаться односайтовыми, если они имеют тот же уровень безопасности, что и страница.
Тот же сайт:
-
wss://
соединение сhttps://
-
ws://
соединение сhttp://
Межсайтовый:
-
wss://
соединение сhttp://
-
ws://
соединение сhttps://
Фото Джулиссы Капдевильи на Unsplash