Две отдельные тарелки с печеньем, которые представляют собой разные схемы: HTTP и HTTPS. Печение — файлы cookie.

Same-Site с учетом схемы

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

Available in: English, 日本語, and 한국어
Appears in: Безопасность и надежность
Steven Bingler
Steven Bingler
GitHub
Rowan Merewood
Rowan Merewood
TwitterGitHubGlitch
Содержание

Спецификация Same-Site с учетом схемы определяет (веб-)сайт не как регистрируемый домен, а как схему + регистрируемый домен. Более подробную информацию и примеры см. в статье Что такое «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.

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

Распространенные сценарии межсхемных переходов #

Переходы #

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

Межсхемный переход по ссылке в незащищенной HTTP-версии сайта, ведущей на защищенную HTTPS-версию. Файлы cookie «SameSite=Strict» заблокированы, «SameSite=Lax» и «SameSite=None; Secure» разрешены
Межсхемный переход с HTTP на HTTPS
HTTP → HTTPSHTTPS → 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; Secure» разрешены
Страница HTTP, использующая межсхемный подресурс через HTTPS
HTTP → HTTPSHTTPS → HTTP
SameSite=Strict⛔ Блокируется⛔ Блокируется
SameSite=Lax⛔ Блокируется⛔ Блокируется
SameSite=None;Secure✓ Разрешено⛔ Блокируется

Отправка формы запросом POST #

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

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

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

Как проверить свой сайт #

В Chrome и Firefox можно использовать инструменты разработчика и передачи сообщений.

В Chrome 86 на вкладке «Проблемы» (Issues) в DevTools будут показаны проблемы, относящиеся к Same-Site с учетом схемы. Возможные проблемы приведены ниже.

Проблемы с переходами:

  • «Чтобы файлы cookie в будущем могли отправляться с запросами Same-Site, перейдите полностью на HTTPS» (Migrate entirely to HTTPS to continue having cookies sent on same-site requests) — предупреждение о том, что файл cookie будет заблокирован в будущей версии Chrome.
  • «Чтобы отправлять файлы cookie с запросами Same-Site, перейдите полностью на HTTPS» (Migrate entirely to HTTPS to have cookies sent on same-site requests) — предупреждение о том, что файл cookie был заблокирован.

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

  • «Чтобы файлы cookie в будущем могли отправляться на подресурсы Same-Site, перейдите полностью HTTPS» (Migrate entirely to HTTPS to continue having cookies sent to subresources) или «Чтобы файлы cookie в будущем могли устанавливаться подресурсами Same-Site, перейдите полностью HTTPS» (Migrate entirely to HTTPS to continue allowing cookies tobe set by same-site subresources) — предупреждения о том, что файл cookie будет заблокирован в будущей версии Chrome.
  • «Чтобы отправлять файлы cookie на подресурсы Same-Site, перейдите полностью на HTTPS» (Migrate entirely to HTTPS to have cookies sent to same-site subresources) и «Чтобы устанавливать файлы cookie подресурсами Same-Site, перейдите полностью HTTPS» (Migrate entirely to HTTPS to allow cookies to be set by same-site subresources) — предупреждения о том, что файл cookie был заблокирован. Последнее предупреждение также может появиться при отправке формы запросом POST.

Подробнее — в статье Советы по тестированию и отладке Same-Site с учетом схемы.

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

  • «Файл cookie cookie_name скоро будет обрабатываться как межсайтовый по отношению к http://site.example/, потому что схемы не совпадают» (Cookie cookie_name will be soon treated as cross-site cookie against http://site.example/ because the scheme does not match).
  • «Файл cookie cookie_name был обработан как межсайтовый по отношению к http://site.example/, потому что схемы не совпадают» (Cookie cookie_name has been treated as cross-site cookie against http://site.example/ because the scheme does not match).

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

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

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

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

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

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

Same-Site:

  • подключение wss:// с https://;
  • подключение ws:// с http://.

Не Same-Site:

  • подключение wss:// с http://;
  • подключение ws:// с https://.

Автор фото — Джулисса Капдевилла, платформа Unsplash

Последнее обновление

— Улучшить статью
Return to all articles
Поделиться
By Chrome DevRel