Samesite cookie как исправить

В целях совершенствования безопасности веб-ресурсов периодически появляются новые технологии и инструменты для разработки. Появление атрибута SameSite Cookie как раз является таким примером. Атрибут при должной настройке призван защитить от возможных атак путем использования сторонних cookie-файлов. Также правильные настройки данного атрибута позволяют запретить отслеживания при помощи Cookie, что часто используется для персонализации рекламы и сбора данных о пользователе.

Что такое Cookie SameSite? Это расширение файлов Cookie (появившееся в 2016 году), которое предназначено для защиты от подделки межсайтовых запросов (сокращенно CSRF). Но совсем недавно этот атрибут Cookie был внедрен компанией Google в свои продукты в обновленном виде и поэтому появилась необходимость правильно устанавливать данный атрибут, чтобы сайты работали без ошибок. В частности, Google обновила стандарт и добавила новшества – теперь по умолчанию устанавливается запрещающее значение, что может повредить единую систему аутентификации и вызвать прочие ошибки на сайте.

Атрибут SameSite может иметь разные значения:

– None, в этом случае ограничения на файлы Cookie не устанавливаются;

– Strict, устанавливается полный запрет на отправку любых Cookie;

– Lax, в этом случае файлы Cookie полностью блокируются для межсайтовых запросов (включая изображения, iframe и т.д.).

Для использования защищенного соединения HTTPS также можно указать дополнительный атрибут Secure. Если это указано, Cookie будет отправлен только через HTTPS, но не через обычный протокол HTTP.

При неправильном использовании Cookie в консоли браузера могут появляться ошибки, связанные с данным атрибутом. Исправить их достаточно просто – достаточно для всех Cookie-файлов установить атрибут SameSite и выбрать для него подходящее значение.

Как устанавливать значения Cookie SameSite? Например, в языке PHP (7.3+) управлять такими настройками позволяет функция setcookie, которая принимает различные параметры установки Cookie. Параметр options этой функции позволяет задать различные настройки – он принимает ассоциативный массив, который может иметь любой из ключей: expires, path, domain, secure, httponly и нужный нам samesite. Если элемент samesite не указан, cookie-атрибут SameSite не будет установлен.

В более старых версиях PHP можно управлять данным атрибутом как показано далее:

setcookie('cookie-name', '1', 0, '/; samesite=strict');

Кроме того, можно использовать настройки Apache. Например, чтобы задать всем Cookie на сайте нужные значения, в файле .htaccess следует прописать примерно следующее:

Header always edit Set-Cookie (.*) «$1; SameSite=Lax».

Не стоит забывать и о методе установке Cookie посредством отправки заголовков:

header(‘Set-Cookie: key=value; path=/; domain=example.org; HttpOnly; SameSite=Lax’).

Время прочтения
4 мин

Просмотры 46K

На днях внимательная коллега (спасибо, Лена) зарепортила странный баг — сервер нормально ставил куку в браузере, но обратно она не прилетала. Днём ранее всё работало, теперь же кука выставлялась, но спустя несколько секунд магическим образом пропадала (хотя должна держаться сутки). Воспроизводилось это всего у нескольких человек в команде и только в новом Chrome 80, но у остальных в Chrome точно такой же версии всё было в порядке. В других браузерах всё работало как часы. Мистика. Начали разбираться, и спустя какое-то время в консоли Chrome заметили предупреждение для заголовка ответа, устанавливающего куки:

A cookie associated with a cross-site resource at _your_domain_ was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`.

Начали изучать что это такое, и постепенно стало понятно, как ошибка возникла и почему проявлялась не у всех. Поскольку наш сервис должен обрабатывать запросы с разных доменов, то SameSite — как раз наш случай. Добавили SameSite=None; Secure, и проблема для нас решилась.

Почему так?

Изначально, по стандарту HTTP, браузер отправлял cookies (или просто куки) при любом запросе на соответствующий им домен. Это открывало возможности для CSRF-атаки, то есть позволяло недобросовестным людям при определённом стечении обстоятельств получить доступ к каким-либо ресурсам под видом ничего не подозревающих добросовестных, просто воспользовавшись их куками.

В 2016 году был введён атрибут SameSite, позволяющий контролировать, будет ли браузер отправлять cookies, если страница посылает запрос на другой домен. У разработчиков появилась возможность блокировать передачу своих кук, если запрос выполняется с постороннего сайта. Для этого атрибуту SameSite нужно было явно присвоить значение Strict (cookies передаются только при запросах и переходах с домена, к которому они относятся), или Lax (куки передаются при переходе на сайт с других сайтов по прямой ссылке, но не передаются при других запросах с них, например при AJAX-запросе или загрузке картинок). Отсутствие SameSite было эквивалентно SameSite=None, то есть по умолчанию cookies всё так же передавались при любых запросах.

В мае 2019 года разработчики Google Chrome объявили, что будут постепенно менять это поведение и трактовать отсутствие SameSite как SameSite=Lax (подробнее здесь). То есть — по умолчанию браузер будет блокировать передачу cookies при запросах с текущей страницы на любые другие ресурсы, кроме прямых переходов по ссылке. Разработчики Firefox и Edge объявили, что со временем так же внедрят это изменение в своих браузерах.

Для пользователей такое поведение браузера более безопасно. Разработчикам же сайтов и веб-сервисов нужно иметь ввиду, что если им всё-таки требуется получать свои cookies при запросах с других сайтов, они должны будут явно установить своим кукам атрибуты SameSite=None, Secure (Secure — потому что такой запрос вдобавок должен приходить на сервер только по защищённому каналу).

Поскольку нововведение меняет действующий стандарт, и не все сайты смогут адаптироваться быстро, то переход к новому поведению происходит постепенно. Изначально его включили у ограниченного числа бета-пользователей Chrome, и вот теперь постепенно увеличивают их количество. Актуальная информация доступна здесь. Самая свежая запись по ссылке:

Last updated March 9, 2020.

We have begun enforcing the new behavior for Chrome 80 stable, just not for 100% of users. The controlled rollout is to a limited initial population,

То есть, период бета-тестирования позади, и разработчики Chrome начали потихоньку включать новый функционал у обычных пользователей. Что в принципе хорошо, поскольку так действительно безопаснее.

Вернуть старое поведение возможно через настройки: в адресной строке Chrome ввести chrome://flags, перейти на страницу, найти пункт SameSite be default cookies, и установить ему значение Disabled. Но это подходит больше для тестирования, чем для простых пользователей. Аналогично, если в вашем Chrome 80 пока работает старое поведение, вы можете принудительно включить новый функционал, установив эту же настройку в Enabled.

Поэтому если вашему сайту требуется получать cookies при запросах с разных доменов — будьте готовы к грядущим переменам (а кто уже готов — тот молодец). Всем добра!

Дополнено:
xdenser в комментариях указал, что некоторые старые версии браузеров не поддерживают SameSite=None, не принимая такие куки совсем или обрабатывая их нестандартным способом. Среди них есть браузеры для десктопов и мобильных устройств. На странице https://www.chromium.org/updates/same-site/incompatible-clients приводится список браузеров и возможное решение проблемы (на псевдокоде, но довольно детальное). Авторы предлагают детектировать проблемные версии браузеров по заголовку useragent, и не выставлять их кукам атрибут SameSite=None совсем.

Дополнено 2:
В связи с ситуацией с COVID-19, с 3 апреля 2020 г. Google временно приостанавливает внедрение описанных изменений в обработке SameSite, для обеспечения бесперебойной работы интернет-сервисов. На устройствах, где изменения уже задействованы, они будут отменены.
(с) blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html

Источники:
web.dev/samesite-cookies-explained
www.chromium.org/updates/same-site
www.chromestatus.com/feature/5088147346030592
www.chromium.org/updates/same-site/incompatible-clients
blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html

16 января 2020 г.

Эта статья посвящена тому, как планируемые изменения в Chrome могут повлиять на функции вашего сайта для пользователей. Она уже была опубликована в блоге для разработчиков Chromium.

В мае команда Chrome представила модель обработки файлов cookies, безопасную по умолчанию и созданную на основе новой системы классификации таких файлов (см. спецификацию). Эта инициатива – часть нашего плана по повышению уровня конфиденциальности и безопасности в интернете.

Разработчики Chrome собираются реализовать новую модель в Chrome 80 в феврале 2020 г. Компании Mozilla и Microsoft также планируют обеспечить ее поддержку в браузерах Firefox и Edge, но у них свои сроки. Изменения в Chrome вступят в силу через несколько месяцев, однако разработчикам, которые применяют файлы cookie, стоит начать подготовку к этому уже сейчас. Эта запись содержит общую информацию о будущих изменениях. Подробные инструкции для разработчиков вы можете найти на сайте web.dev.

О файлах cookie для одного сайта или нескольких сайтов

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

Менее очевидный пример – когда владелец нескольких сайтов использует для них всех один и тот же файл cookie. Хотя сайты и файл cookie принадлежат одному и тому же человеку, контекст все равно считается сторонним, поскольку домен файла cookie не соответствует одному или нескольким сайтам, на которых он используется.

Файл cookie имеет сторонний контекст, если он предназначен для нескольких сайтов. Это может быть в ситуации, когда сторонний ресурс на веб-странице обращается к файлу cookie, который не относится к домену сайта.

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

Когда ресурс на веб-странице получает доступ к файлу cookie, связанному с доменом сайта, это называется собственным контекстом, то есть файл предназначен для одного сайта.

Новая безопасная и прозрачная модель обработки файлов cookie

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

Чтобы защитить интернет-ресурсы и пользователей, мы разработали новую модель, безопасную по умолчанию: все файлы cookie должны быть недоступны сторонним сервисам, если не указано иное. Чтобы разрешить сторонний доступ к файлам cookie, разработчикам следует использовать новую настройку: SameSite=None. Если задан атрибут SameSite=None, необходимо добавить дополнительный атрибут Secure, чтобы межсайтовые файлы cookie были доступны только по протоколу HTTPS.
Это не устранит все риски, связанные с открытым доступом, но защитит сайт от сетевых атак.

Помимо очевидных преимуществ с точки зрения безопасности, явное объявление межсайтовых файлов cookie обеспечивает пользователям большую прозрачность и возможность выбирать. Например, браузеры могут предлагать пользователям точную настройку файлов cookie, доступных только для одного сайта, независимо от межсайтовых файлов cookie.

Контроль в Chrome: с февраля 2020 г.

В феврале выйдет Chrome 80, и система станет воспринимать файлы cookie, для которых не задано значение SameSite, как файлы со значением SameSite=Lax. Сторонний доступ будет возможен только для файлов cookie с атрибутом Secure SameSite=None, который означает безопасное подключение. Средства отслеживания статуса атрибутов SameSite=None и Secure, доступные на платформе Chrome, будут обновляться с учетом актуальной информации о запуске.

Представители Mozilla подтвердили, что реализуют поддержку новой модели классификации файлов cookie и намерены использовать настройку «SameSite=None; Secure» для межсайтовых файлов cookie в Firefox. Компания Microsoft недавно сообщила о том, что готова использовать такую же модель. Эксперимент начнется с Microsoft Edge 80.

Подготовка и возможные сложности

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

• Не все языки и библиотеки в настоящее время поддерживают значение None. Поэтому разработчикам приходится непосредственно прописывать заголовок файла cookie. В этом репозитории GitHub вы можете найти инструкции по реализации настройки «SameSite=None; Secure» для разных языков, библиотек и фреймворков.
• Некоторые браузеры, например Chrome, Safari и UC Browser, могут обрабатывать значение None нежелательным образом. В таком случае разработчики должны прописать в коде исключения для клиентов этих браузеров. В частности, это касается компонентов Android WebView, работающих на основе старых версий Chrome. Список неподдерживаемых клиентов доступен здесь.
• Разработчикам приложений рекомендуется объявить подходящие настройки SameSite cookie для компонентов Android WebViews, основанных на версиях Chrome, которые поддерживают значение None. Это стоит сделать для файлов cookie, доступ к которым осуществляется как через заголовки HTTP(S), так и через CookieManager API Android WebView. Однако учтите, что новая модель будет реализована для Android WebView позже.
• Если некоторые корпоративные сервисы, такие как система единого входа или внутренние приложения, не будут готовы к запуску в феврале, то ИТ-администраторам необходимо реализовать специальные правила для того, чтобы браузер Chrome работал по-старому.
• Если у вас есть файлы cookie как с собственным, так и со сторонним контекстом, используйте их отдельно, чтобы получить доступ ко всем преимуществам атрибута SameSite=Lax в собственном контексте.

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

Вы можете узнать, как новые алгоритмы работы браузера Chrome отразятся на вашем сайте или на файлах cookie, которыми вы управляете. Для этого перейдите на страницу chrome://flags, используя браузер Chrome версии 76 или более поздней, а затем включите эксперименты SameSite by default cookies и Cookies without SameSite must be secure. Также эти эксперименты будут автоматически включены у отдельных пользователей бета-версии Chrome 79. Такие пользователи могут столкнуться с проблемами из-за несовместимости с сервисами, не поддерживающими новую модель обработки файлов cookie. В этом случае следует перейти на страницу chrome://flags и отключить эксперименты.

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

Наконец, если вас интересует, готовы ли поставщики сервисов для сайта к переходу на новую модель обработки файлов cookie, обратите внимание на уведомления в консоли Инструментов разработчика (Chrome версии 77 и более поздних). Если на странице есть межсайтовые файлы cookie, для которых не заданы нужные настройки, вы увидите следующее:

Некоторые поставщики, в том числе определенные сервисы Google, должны внести необходимые изменения в течение нескольких месяцев до выхода Chrome 80 в феврале. Вы можете связаться со своими партнерами и узнать, готовы ли они.

Table of contents

• Introduction

• Решения проблемы с SameSite

Introduction

Cookies позволяют идентифицировать пользователя и в дальнейшем выполнять запросы от имени данного пользователя.
Поэтому их безопасность очень важна. Ранее для сессионных cookies уже был добавлен параметр HttpOnly, который защищает доступ к cookies из JS и тем самым препятствует перехвату с помощью XSS-уязвимостей.
Но все же оставалась возможность сделать запрос с другого домена к сайту (example.com), на котором авторизован пользователь, с передачей cookies посредством встраивания скрипта или вызова изображения, например:

<script src="http://example.com">

Для того, чтобы запретить передачу cookies при таких кроссдоменных запросах, был введен параметр SameSite, который может принимать следующие значения (первые два запрещают кроссдоменную передачу):

• Strict
• Lax
• None

До недавнего времени браузеры не обрабатывали данный параметр и считали, что он по умолчанию установлен как None.
Но в феврале Chrome стал обрабатывать параметр SameSite, и, если параметр не установлен, то значение по умолчанию выставлять Lax, а не None, как было до версии 80.

Конечно же, об изменениях было известно заранее (еще в сентябре 2019) и 79 версия Chrome уже включала в себя поддержку обработки данного параметра, но она по умолчанию была отключена.

С выходом Chrome 80 у некоторых сайтов, которые пользовались возможностью кроссдоменной передачи cookies, появились проблемы с работоспособностью в данном браузере.

После выхода Chrome 80 было решено на время откатить функционал проверки SameSite, т.к. не все сайты успели вовремя среагировать на изменения, но позже его опять вернут.

Решения проблемы с SameSite

Для того, чтобы решить данную проблему, необходимо установить для cookies, которые используются для кроссдоменной передачи, параметр SameSite=None, но Chrome будет принимать такой параметр только при установке параметра Secure, т.е., если мы кроссдоменно передаем cookies, то делать это нужно только по https.

Для PHP поддержка параметра SameSite была введена только в версии 7.3 для функции setcookie. Для Legacy-проектов переход на 7.3 версию PHP может быть затруднителен и поэтому придется выбирать один из обходных путей:

• Использовать вместо setcookie обычную установку заголовков через функцию header:

header("Set-Cookie: key=value; path=/; domain=example.com; Secure; SameSite=None");

• Воспользоваться классом Cookie из пакета symfony/http-foundation: https://github.com/symfony/http-foundation/blob/master/Cookie.php

Описанные выше решения предполагают доработку кода, но установка необходимых cookies может происходить в коде вендора и поэтому либо придется его форкать, либо отказываться от обновления вендора.

Но если данные методы не подходят, то остается подмена cookies уже на стороне web-сервера:

• Для Apache необходимо в секции VirtualHost добавить подмену:

Header edit Set-Cookie ^((COOKIE_NAME1|COOKIE_NAME2).*)$ "$1;Secure;SameSite=None"

• Для Nginx в location добавляем:

proxy_cookie_path / "/; Secure; SameSite=None";

Стоит отметить, что это лишь временные решения и в долгосрочной перспективе необходимо решить проблемы с Legacy и устанавливать cookies штатными средствами.

Дата публикации : 2020-04-07 17:32:06

Дата редактирования : 2020-11-12 00:36:06

Автор :

Chrome планирует внедрить по умолчанию новую защиту пользователей от передачи сторонних Cookie и скрытой идентификации во
все версии браузеров Chrome 80 и выше начиная с февраля 2020 года. Mozilla и Microsoft также заявили о намерении внедрить новую модель в браузеры Firefox и Edge в сроки, установленные
самостоятельно.

В содержимое веб-сайтов часто включаются внешние сервисы для рекламы, рекомендации по контенту, сторонние виджеты, социальные сети и другие опции. Когда вы просматриваете веб-страницы, внешние
службы могут сохранять файлы Cookie в вашем браузере и в дальнейшем могут получать доступ к этим файлам Cookie, чтобы предоставить персональные рекомендации или оценить поведение пользователей. У
каждого файла Cookie имеется связанный с ним домен. Если домен, связанный с файлом Cookie, соответствует внешней службе, а не веб-сайту в адресной строке пользователя, это считается межсайтовой
(или «сторонней») связью.

Менее очевидные случаи межсайтового использования включают ситуации, когда объект, который владеет несколькими веб-сайтами, использует файлы Cookie с настроенными араметрами. Несмотря на то, что
один и тот же объект владеет файлами Cookie и веб-сайтами, это однозначно считается межсайтовой (сторонней) связью, если домен с файлами Cookie не соответствует сайтам, с которых осуществляется
доступ к файлам Cookie.

Когда внешний ресурс на веб-странице получает доступ к файлу Cookie, который не соответствует домену сайта — это межсайтовый или «сторонний» контекст. Напротив, доступ к файлам Cookie в контексте
одного и того же сайта (или «первого лица») происходит, когда домен файла Cookie совпадает с доменом сайта в адресной строке пользователя. Файлы Cookie одного сайта обычно используются для того,
чтобы когда пользователи заходили на отдельные сайты, запоминались индивидуальные предпочтения и поддерживалась аналитика
сайта. Когда ресурс на веб-странице получает доступ к файлу Cookie, который соответствует сайту и который посещает пользователь — это контекст того же сайта или «первого лица».

Атрибут SameSite позволяет определить допустимость передачи файлов Cookie, если со стороннего веб-ресурса поступил запрос. Чаще всего файлы Cookie передаются по любому запросу, даже если запрос
поступает с другого сайта при помощи загрузки изображения или iframe.

Подобным способом действуют рекламные сети, пытаясь отследить пользователей при посещении разных сайтов. Также аналогичным образом поступают злоумышленники при организации CSRF-атак, как со
страниц взломанного сайта направляются запросы на основной сайт, где находится авторизованный пользователь. При этом пользовательский браузер по указанному запросу передаёт сессионные файлы
Cookie. Также отправка Cookie на другие сайты будет возможна, когда на страницах с виджетами имеются вставки.

Параметры атрибута «SameSite» позволяют управлять действиями браузера при отправке файлов Cookie. Например, отправлять Cookie только на те запросы, которые получены первоначально с другого сайта.

Атрибут имеет три значения:

• «Strict» — полный запрет на отправку Cookie.
• «Lax» — блокируются некоторые Cookie для запросов между сайтами (изображения или iframe). 
• «None» — ограничения на файлы Cookie отсутствуют.

В настоящее время для предотвращения внешнего доступа файл Cookie может иметь только два параметра: «SameSite = Lax» или «SameSite = Strict». Тем не менее только немногие разработчики
придерживаются этой практики. В результате для значительного числа файлов Cookie сайты могут подвергаться атакам через подделку межсайтовых запросов (Cross Site Request Forgery).

Чтобы защитить пользователей и сайты, новая модель безопасности по умолчанию защищает все файлы Cookie от внешнего доступа, если не указаны иные параметры. Чтобы назначить файлы Cookie для
межсайтового доступа, разработчики должны сделать настройку файлов Cookie и добавить запись «SameSite = None».

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

Другие варианты запрещают обработку файлов Cookie для сторонних сайтов по http-протоколу. В перспективе пользователи будут защищены от скрытой идентификации при помощи уникального отпечатка
браузера (технология «Browser Fingerprinting»).

В новой версии Chrome у обработчика кнопки Back появится защита от записей, связанных с автоматическими пробросами и манипуляциями с историей посещений, когда возникают искусственные трудности
при возвращении пользователей с просматриваемого сайта на исходную (домашнюю) страницу.

Технология Flash будет отключена по умолчанию в настройках «Расширенные — Приватность и безопасность — Свойства сайтов». С 2020 года поддержка Flash будет полностью отключена.

В рамках развития стратегии Google по информационной безопасности в последующих версиях браузера Chrome 80+ изменится технология обработки файлов Cookie и поддержке атрибута SameSite.

• По умолчанию будет включена опция «Same-site-by-default-Cookies».
• Если в заголовке не будет атрибута «SameSite», браузер Chrome без участия пользователей самостоятельно установит значение «SameSite=Lax», что поможет ограничить отправку файлов Cookie для
  вставок со сторонних сайтов.
• Чтобы снять автоматическое ограничение, владельцы сайтов могут самостоятельно установить значение параметра «SameSite=None».
• Безопасные настройки будут доступны для внешнего доступа, если они доступны из защищенных соединений. Средства отслеживания состояния платформы Chrome для «SameSite = None» и Secure будут
  по-прежнему обновляться с использованием последней информации о запуске. 
• Mozilla подтвердила свою поддержку новой модели классификации файлов Cookie, намереваясь реализовать атрибут «SameSite = None». 
• Microsoft также объявила о планах начать реализацию модели, начиная с браузера Microsoft Edge 80.

Если вы управляете межсайтовыми файлами Cookie, для безопасной настройки файлов Cookie вам необходимо применять атрибут «SameSite = None». Внедрение не должно представлять трудности для
большинства разработчиков. Но Гугл настоятельно рекомендует приступить к тестированию без промедления, чтобы заранее выявить сложности и особые случаи. Например, такие как:

• Не все языки и библиотеки поддерживают значение None, что требует от разработчиков непосредственной установки заголовка файлов Cookie. Этот репозиторий Github содержит инструкции по
  реализации атрибута безопасной настройки «SameSite = None» на разных языках, в библиотеках и фреймворках.
• Некоторые браузеры, включая отдельные версии Chrome, Safari и UC Browser, могут непреднамеренно обрабатывать значение None и это требует от разработчиков кодирования исключений для этих
  клиентов. Например, для Android WebViews на основе более старых версий Chrome. Вот список известных несовместимых клиентов.
• Разработчикам приложений рекомендуется раскрывать соответствующие настройки файлов Cookie SameSite для веб-приложений Android на основе версий Chrome, которые совместимы со значением None,
  как для файлов Cookie, доступ к которым осуществляется через заголовки HTTP (S), так и через API-интерфейс Cookie Manager Android WebView. Однако новая модель не будет позже применяться на
  Android WebView.
• Корпоративным ИТ-администраторам могут потребоваться специальные политики для временного возврата браузера Chrome к прежним настройкам, если некоторые
  службы, такие как единый вход или внутренние приложения, неготовы к запуску новой модели в феврале 2020 года.
• Если у вас есть файлы Cookie, к которым вы получаете доступ как в первом, так и в стороннем контексте, вы можете рассмотреть возможность использования отдельных файлов Cookie для получения
  преимуществ безопасности SameSite = Lax в контексте первого лица.

В разъяснениях к SameSite Cookie предлагаются
конкретные рекомендации для решения вышеописанных ситуаций, а также каналы для обратной связи. Чтобы проверить влияние новой версии Chrome на ваш сайт или управляемые вами файлы Cookie, вы можете
обратиться к настройке «chrome: // flags» в браузере Chrome 76+ и включить опцию «SameSite by default Cookies» и «Cookies without SameSite must be secure».

Кроме того, эти опции будут автоматически включены для некоторых пользователей бета-версии браузера Chrome 79. Некоторые пользователи бета-версии с включенными экспериментальными опциями могут
столкнуться с проблемами несовместимости со службами, которые еще не поддерживают новую модель. В этом случае пользователи могут отказаться от данных опций в бета-версии, отключив с помощью
настройки «chrome: // flags».

• Если вы управляете файлами Cookie, доступ к которым осуществляется только в пределах одного и того же сайта (файлы Cookie для единственного сайта), с вашей стороны не требуется никаких
  действий. Новый браузер Chrome автоматически предотвращает доступ к этим файлам Cookie со стороны внешних объектов, даже если атрибут SameSite отсутствует или его значение не задано. 
• Однако Google настоятельно рекомендует использовать соответствующее значение SameSite (Lax или Strict) и советует не полагаться на поведение браузера по умолчанию. Поскольку не все браузеры
  могут по умолчанию защищать файлы Cookie для одного сайта.
• Если вы решили узнать о готовности поставщиков и других лиц, предоставляющих услуги вашему веб-сайту, вы можете проверить наличие предупреждений в инструментах разработчика Developer Tools в
  Chrome 77+, если на странице содержатся межсайтовые файлы Cookie, в которых отсутствуют необходимые параметры:

Set-Cookie: SameSite

SameSite cookies

Cookie "myCookie" rejected because it has the "SameSite=None" attribute but is missing the "secure" attribute.

This Set-Cookie was blocked because it had the "SameSite=None" attribute but did not have the "Secure" attribute, which is required in order to use "SameSite=None".

Set-Cookie: flavor=choco; SameSite=None

Set-Cookie: flavor=choco; SameSite=None; Secure

Cookie "myCookie" has "SameSite" policy set to "Lax" because it is missing a "SameSite" attribute, and "SameSite=Lax" is the default value for this attribute.

Set-Cookie: flavor=choco; SameSite=Lax

RewriteEngine on
RewriteBase "/"
RewriteCond "%{HTTP_HOST}"       "^example.org$" [NC]
RewriteRule "^(.*)"              "https://www.example.org/index.html" [R=301,L,QSA]
RewriteRule "^(.*).ht$"         "index.php?nav=$1 [NC,L,QSA,CO=RewriteRule;01;https://www.example.org;30/;SameSite=None;Secure]
RewriteRule "^(.*).htm$"        "index.php?nav=$1 [NC,L,QSA,CO=RewriteRule;02;https://www.example.org;30/;SameSite=None;Secure]
RewriteRule "^(.*).html$"       "index.php?nav=$1 [NC,L,QSA,CO=RewriteRule;03;https://www.example.org;30/;SameSite=None;Secure]
[...]
RewriteRule "^admin/(.*).html$" "admin/index.php?nav=$1 [NC,L,QSA,CO=RewriteRule;09;https://www.example.org:30/;SameSite=Strict;Secure]

Specifications

Browser compatibility

HTTP

• Service-Worker-Navigation-Preload

  Заголовок запроса Service-Worker-Navigation-Preload указывает,что это результат операции fetch(),выполненной во время предварительной загрузки.

• Set-Cookie

  Заголовок ответа Set-Cookie HTTP используется для отправки с сервера пользовательского агента,чтобы потом его можно было вернуть обратно.

• SourceMap

  Заголовок ответа SourceMap HTTP связывает сгенерированный код,позволяя браузеру реконструировать оригинал и представить реконструированный отладчику.

• Strict-Transport-Security

  Заголовок ответа HTTP Strict-Transport-Security (часто сокращенно HSTS)информирует браузеры о том,что доступ к сайту должен осуществляться только с использованием и любыми будущими

Разработчики Google Chrome постепенно внедряют новые стандарты безопасности пользователей, меняя подход к обработке cookie и поддержке атрибута SameSite. Подробно рассказываем, что это за атрибут и как он может изменить работу сайтов и приложений.

• Что такое SameSite и как он работает?
• Что такое межсайтовый запрос?
• Почему Google совершает такие радикальные изменения?
• Как Chrome защищает пользователей от CSRF-атак?
• Реальный пример разницы между значением атрибута Strict и Lax
• Обновление Chrome 80 SameSite
• На скольких пользователей повлияет это изменение?
• Будет ли затронут мой сайт?
• Как подготовиться к обновлением Chrome 80
  • Шаг 1
  • Шаг 2
  • Нужна дополнительная помощь?

Что такое SameSite и как он работает?

В мае 2019 года разработчики Chrome объявили о внедрении новой модели безопасности для обработки файлов cookie. Теперь у каждого пользователя по умолчанию будет включен флаг «same-site-by-default-cookies». При этом, если в файле не будет атрибута SameSite, браузер все равно самостоятельно поставит значение «SameSite=Lax» —это ограничит отправку сookie для вставок со сторонних сайтов. Однако владельцы сайтов смогут снимать это ограничение, прописывая в настройках сookie параметр «SameSite=None, Secure» — последний параметр означает, что такой запрос вдобавок должен приходить на сервер только по защищённому каналу.

Изначально, по стандарту HTTP, браузер отправлял cookies при любом запросе на соответствующий им домен. Однако такие механизмы открывали возможности для проведения CSRF-атак — мошенники могли при определенном стечении обстоятельств получить доступ к разным ресурсам, пользуясь сookie. Поэтому в 2016 году появился атрибут SameSite, позволяющий контролировать, как браузер будет отправлять cookies в случае, если страница сайта посылает запрос на другой домен.

При этом первоначально, когда Chrome только начали разрабатывать SameSite, атрибуту нужно было присвоить явное значение Strict или Lax (подробнее о них мы расскажем ниже). Отсутствие SameSite было эквивалентно «SameSite=None», то есть по умолчанию cookies всё так же передавались при любых запросах.

Основной целью изменения работы атрибута SameSite является повышение прозрачности и безопасности для пользователей — люди смогут узнавать, кто отслеживает и использует информацию из сookie, которой они делятся. Кроме того, изменение в SameSite повлияет как на поведение пользователей, так и на рекламодателей, медиа и любых компаний, которые используют файлы сookie для анализа поведения своей аудитории.

Что такое межсайтовый запрос?

Когда вы посещаете какой-либо сайт, в браузере сразу же создается и сохраняется файл cookie. Этот cookie-файл затем используется для идентификации пользователя и обеспечения персонализированного просмотра. Существует два типа файлов cookie — first-party and third-party. Оба типа могут содержать одну и ту же информацию: однако к ним обращаются в разных случаях и и создаются они немного разными путями.

Если вы посещаете какой-нибудь сайт, например, a.com, и собираетесь получить доступ к услуге с того же доменного имени, сгенерированные файлы cookie будут считаться файлами cookie типа first-party. Поскольку файлы cookie были созданы одним и тем же сайтом, вы сможете наслаждаться персонализированным подходом — в том числе настройкой окружения, сохраненной информацией для входа в систему, элементами корзины покупок и так далее.

В случае, если вы посещаете сайт с условным названием b.com, который содержит разный контент — например, изображения или iframe из другого доменного имени, cookie будут считаться сторонними — third-party, поскольку они происходят от другого адреса, чем в строке URL. Эти файлы cookie будут созданы другим сайтом, а доступ от одного к другому будет представлять собой межсайтовый запрос. Страница сайта a.com с запросом b.com позволят таким службам, как Facebook, Google Analytics, Doubleclick, отслеживать пользователей и предоставлять им онлайн-рекламу. В таком случае все эти сайты являются b.com — при помощи этой технологии Google показывает пользователям целевую рекламу на сайтах, которые он посещает.

И вот как раз отправку файлов cookie типа third-party прекратит Google Chrome в межсайтовых запросах в случае, если они не защищены и не помечены с использованием стандарта IETF SameSite. Другими словами, контент со страницы b.com, который расположен на сайте a.com, больше не сможет получить доступ к файлам cookie, если они не защищены и не помечены специальными флагами.

Почему Google совершает такие радикальные изменения?

Обмен межсайтовыми cookie-файлами не всегда является проблемой, но у этой технологии есть потенциал для злоупотребления. Текущее поведение Google Chrome позволяет сторонним веб-сайтам получать доступ ко всем файлам cookie по умолчанию. Это создает возможность проведения CSRF-атак, при которых мошенники могут использовать сохраненные cookie-файлы пользователей на сторонних сайтах.

Например, пользователь является залогиненым в Хекслете и у него есть сессия в cookie. Пользователь случайно перешел на какую-то зараженную страницу, через которую мошенник может получить доступ к файлам cookie пользователя на Хекслете, перейти в уже аутентифицированный сеанс и сделать несколько запросов на сайте вместо человека, поскольку пользователь уже прошел проверку подлинности, поэтому сайт не планирует проводить дополнительные проверки. Таким образом мошенник может решить все курсы пользователя на сайте и пройти все упражнения.

Есть несколько способов создать такие вредоносные команды: теги изображений, теги ссылок, скрытые формы и запросы JavaScript XMLHttpRequest. При текущем состоянии Chrome запрошенный файл cookie будет отправлен по умолчанию, и хакер получит доступ к сеансу пользователя, что означает, что он фактически вошел в систему как пользователь. Чтобы бороться с этой уязвимостью, фреймворкам часто требуются уникальные токены/идентификаторы, которые недоступны для злоумышленников и не будут отправляться с запросами.

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

HTML-код ссылки из письма выглядит следующим образом:

Хакер уже изучил банк пользователя и знает, как имитировать переводы с аккаунта. Например, обычно этот банк создает таким образом команды для денежных переводов:

Этот хакер отправил это электронное письмо большому количеству клиентов банка, и он знает, что по крайней мере один человек нажмет эту правдоподобную ссылку.

На первый взгляд письмо выглядит настоящим — там нет никаких подозрительных данных, которые явно говорят о том, что это мошенники. Пользователь нажимает на логотип банка, а поскольку он уже прошел проверку подлинности в соседней вкладке, переход по ссылке в итоге создает неавторизованную транзакцию. За несколько секунд у пользователя со счета списывается много денег — и с этим практически ничего невозможно сделать.

При этом, если бы этот банк разрешал только Post-запросы на денежные переводы, то мошенник бы не смог создать вредоносный запрос, используя тег <a href>. Мошеннику бы пришлось уже создавать тег <form> с автоматическим выполнением встроенного JavaScript.

Этот код бы выглядел так:

Однако в жизни этот сценарий бы не был реализован, поскольку банки предотвращают такие CSRF-атаки, используя динамически генерируемые токены сеансов, тайм-ауты сеансов и другие превентивные методы. И теперь — с использованием атрибута Strict — у банков появилась еще одна возможность для киберзащиты. Однако такие механизмы защиты обычно есть у крупных компаний, тогда как небольшому интернет-бизнесу намного сложнее получить подобную систему, поэтому часто такие сайты становятся жертвами кибермошенников.

Как Chrome защищает пользователей от CSRF-атак?

Именно для устранения этой проблемы в 2016 году инженеры из Chrome представили концепцию атрибута SameSite, с помощью которого разработчики сайтов смогут устанавливать правила для совместного использования и доступа к файлам SameSite. Значение атрибута может устанавливаться в трех диапазонах — Strict, Lax или None.

— Strict — самое строгое значение атрибута. К файлам cookie с таким параметром можно получить доступ только при посещении домена, с которого он был изначально установлен. Другими словами, «SameSite= Strict» полностью блокирует передачу cookie с a.com, когда страница сайта b.com отправляет запрос. При этом передача cookie не произойдет даже в том случае, если пользователь щелкнет ссылку верхнего уровня в стороннем домене. Такой вариант лучше всего подходит для сервисов, требующих высокой безопасности, например, для банковского сектора.

— Lax — это значение позволяет всем типам сайта, которые принадлежат к одному и тому же домену, получить доступ к cookie. В отличие от None, где cookie отправляются всегда по умолчанию, это значение, как и Strict, отправляется только по запросу определенного сайта. Однако Lax разрешает доступ к навигации верхнего уровня с помощью безопасного метода HTTP, такого как HTTP GET. Файл cookie не будет отправляться с POST-запросами между доменами или при загрузке сайта во фрейме с несколькими источниками, но он будет отправляться при переходе на сайт по стандартной <a href=...> ссылке верхнего уровня.

— None — это значение позволяет отслеживать пользователей на разных сайтах. Файлы cookie с этим параметром будут работать так же, как они работают сегодня. При этом для установки этого значения атрибута необходимо не просто указать None, но и выбрать тип — Secure, который гарантирует, что запрос передается по безопасному соединению. В случае, если пользователь не станет указывать Secure, то запрос будет отклонен браузером.

Реальный пример разницы между значением атрибута Strict и Lax

Если со значением None все более или менее понятно — оно будет работать так же, как cookie передаются сегодня, то с Strict и Lax все немного сложнее. Допустим, вы является гендиректором компании TalkToMe, Inc. — многофункциональной системы объяснения сложных вопросов на простых примерах. Вы позволяете своим пользователям встраивать вашу плашку на собственные сайты — они получают интеграцию в соцсети, расширенные возможности модерации и другие широкие функции сообщества.

В случае, если значение первичных файлов cookie сайта TalkToMe, Inc. установлены на Lax, ваши клиенты по-прежнему могут получить доступ к встроенным комментариям. Если для собственных файлов cookie у TalkToMe, Inc. установлено значение Strict, ваши клиенты не смогут получить доступ к этим данным с внешнего сайта.

Обновление Chrome 80 SameSite

С обновлением Chrome версии 51 Google предоставила разработчикам сайтов возможность устанавливать правила совместного использования файлов cookie. При этом многие разработчики не следуют этой рекомендуемой практике, поэтому в очередном обновлении — Chrome 80, разработчики Google насильно изменили значение SameSite на Lax по умолчанию. Другими словами, Chrome решил по умолчанию ограничить использование всех файлов cookie и требует, чтобы разработчики самостоятельно помечали файлы cookie значением «SameSite=None» в том случае, если им это необходимо, и брали на себя ответственность за это.

На скольких пользователей повлияет это изменение?

Согласно статистике, 64% пользователей в мире пользуются браузером Chrome. При этом файлы cookie, не помеченные специальным образом, перестанут работать не только в новых случаях их использования — это изменение затронет и ранее загруженные файлы.

Будет ли затронут мой сайт?

Скорее всего, — да.

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

Как подготовиться к обновлением Chrome 80

Шаг 1

Включение флагов SameSite в Chrome и проверка возможных ошибок атрибута на вашем сайте. Начиная с версии Chrome 76, вы можете включить новый #same-site-by-default-cookies флаг и протестировать свой сайт.

Для этого нужно:

• Перейти к chrome: // flags /

• Включить необходимый режим.

• Перезапустить браузер, чтобы изменения вступили в силу.
• Посетить ваш сайт и увидеть, что в консоли инструментов разработчика в браузере нет ошибок.

Если вы видите сообщения об ошибках, как на картинке выше, ваш сайт все еще не готов к обновлению Chrome 80.

Шаг 2

Firefox, Edge и другие браузеры также изменят работу с файлами cookie по умолчанию следующим образом:

— Cookie без SameSite-атрибута будут обрабатываться как «SameSite= Lax». Если вам нужен сторонний доступ, то необходимо обновить cookie.

— Файлы cookie, для которых требуется доступ третьих сторон, должны указывать иметь атрибут «SameSite=None; Secure», чтобы разрешить доступ к ним.

Если вы не знаете, предоставляете ли вы файлы cookie, предназначенные для использования на нескольких сайтах, вот некоторые распространенные сценарии их использования

• Вы представляете рекламу на своем сайте;
• Вы представляете контент в <iframe>;
• Вы представляете контент в WebView;
• Вы представляете изображения с другого сайта на вашем сайте;
• Вы встраиваете контент, размещенный на других сайтах, таких как видео, карты, примеры кода, виджеты чатов и посты в социальных сетях;
• Вы используете сторонние сервисы на своем веб-сайте, такие как Facebook, Twitter, Instagram, LinkedIn, Gravatar, Календарь Google, отслеживание пользователей (CrazyEgg, Google Analytics), CRM и/или бронирование, услуги бронирования, защиты от мошенничества и платежей;

Теперь установите ваши cookie. Большинство серверных приложений поддерживают SameSite атрибуты, однако есть несколько клиентов, которые не поддерживают его.

Нужна дополнительная помощь?

Разработчики Chrome советуют в случае отказа работы cookie на сайтах обращаться сразу же к ним. Для этого можно поднять вопрос о SameSite на GitHub, отправить вопрос «samesite» в StackOverflow, а также следить за обновлениями SameSite в блоге компании.

Адаптированный перевод статьи издания Heroku by Lenora Porter. Мнение автора оригинальной публикации может не совпадать с мнением администрации Хекслета.