Объяснение SameSiteатрибута файлов cookie
Защитите свой сайт, узнав, как явно отмечать межсайтовые файлы cookie.
Файлы cookieэто один из доступных методов добавления постоянного состояния веб-сайтам. С годами возможности cookie росли и развивались, но платформа сохранила часть прежних проблем. Для их решения браузеры (в том числе Chrome, Firefox и Edge) меняют свое поведение, чтобы обеспечить больше устанавливаемых по умолчанию параметров, сохраняющих конфиденциальность.
Каждый файл cookie представляет собой пару key=value , дополненную рядом атрибутов, которые определяют, когда и где используется этот файл cookie. Вероятно, вы уже использовали эти атрибуты, чтобы установить дату истечения срока действия или указать, что файл cookie должен отправляться только по HTTPS. Серверы устанавливают файлы cookie, отправляя в своем ответе заголовок Set-Cookie . Чтобы узнать обо всех подробностях, вы можете погрузиться в RFC6265bis, а пока что краткое напоминание.
Допустим, у вас есть блог, в котором вы хотите показывать своим пользователям рекламу «Что нового». Пользователи могут закрыть рекламу, и не будут видеть ее в течение некоторого времени. Вы можете сохранить это предпочтение в файле cookie, установить для него срок действия в месяц (2600000 секунд) и отправлять файл cooki только по HTTPS. Этот заголовок будет выглядеть так:
Серверы устанавливают файлы cookie с помощью заголовка Set-Cookie .
Когда ваш читатель просматривает страницу, которая соответствует этим требованиям, то есть просматривается в безопасном соединении, а возраст cookie не превышает одного месяца, браузер пользователя отправит этот заголовок в своем запросе:
Браузер отправляет файл cookie обратно в заголовке Cookie .
Вы также можете добавлять и читать файлы cookie, доступные для этого сайта, в JavaScript, используя document.cookie . Запись в document.cookie приведет к созданию или переопределению файла cookie с этим ключом. Например, в консоли JavaScript браузера можно попробовать выполнить следующее:
При чтении document.cookie будут выведены все файлы cookie, доступные в текущем контексте, причем каждый файл cookie разделен точкой с запятой:
JavaScript может получить доступ к файлам cookie с помощью document.cookie .
Если вы попробуете сделать это на нескольких популярных сайтах, вы заметите, что большинство из них устанавливают значительно больше трех файлов cookie. В большинстве случаев эти файлы cookie отправляются при каждом запросе к этому домену, что имеет ряд последствий. Пропускная способность каналов загрузки часто более ограничена, чем каналов скачивания для ваших пользователей, поэтому накладные расходы на все исходящие запросы добавляют задержку к времени до первого байта. Будьте осторожны в выборе количества и размера файлов cookie, которые вы устанавливаете. Используйте атрибут Max-Age , чтобы гарантировать, что файлы cookie не будут храниться дольше необходимого.
Что такое основные и сторонние файлы cookie? #
Если вы вернетесь к предыдущей подборке сайтов, то, вероятно, заметите, что присутствуют файлы cookie для различных доменов, а не только для того, который вы посещаете в данный момент. Файлы cookie, соответствующие домену текущего сайта, то есть тому, что отображается в адресной строке браузера, называются основными файлами cookie. Аналогично, файлы cookie из доменов, отличных от текущего сайта, называются сторонними файлами cookie. Это определение не абсолютное, а зависит от контекста пользователя; один и тот же файл cookie может быть как основным, так и сторонним, в зависимости от того, на каком сайте пользователь находится в данный момент. Файлы cookie могут поступать с разных доменов на одной странице.
Продолжая приведенный выше пример, предположим, что в одном из ваших сообщений в блоге есть изображение изумительно чудесного котика, и оно размещено по адресу /blog/img/amazing-cat.png . Поскольку это изображение такое изумительное, другой человек использует его прямо на своем сайте. Если посетитель был в вашем блоге и у него файл cookie promo_shown , то, когда он просматривает amazing-cat.png на сайте другого человека, этот файл cookie будет отправлен в этом запросе для изображения. Это никому не нужно, так как promo_shown ни для чего не используется на сайте этого человека, он просто добавляет накладные расходы к запросу.
Если это непреднамеренный эффект, то зачем вам это нужно? Именно этот механизм позволяет сайтам сохранять состояние, когда они используются в стороннем контексте. Например, если вы разместите на своем сайте видео с YouTube, посетители увидят в проигрывателе опцию «Посмотреть позже». Если ваш посетитель уже зарегистрирован на YouTube, его сессия будет доступна во встроенном проигрывателе с помощью стороннего cookie, то есть кнопка «Посмотреть позже» просто сохранит видео одним махом, а не предложит ему войти в систему или переместит его с вашей страницы обратно на YouTube. 
Файл cookie в стороннем контексте отправляется при посещении разных страниц.
Одно из культурных свойств Интернета заключается в том, что он по умолчанию считается открытым. Отчасти это позволило многим людям создавать собственный контент и приложения. Однако это также породило ряд проблем, связанных с безопасностью и конфиденциальностью. Атаки с подделкой межсайтовых запросов (CSRF) основываются на том факте, что файлы cookie прикрепляются к любому запросу из заданного источника, независимо от того, кто инициирует запрос. Например, если вы посетите evil.example , он может инициировать запросы к your-blog.example , и ваш браузер с радостью прикрепит связанные файлы cookie. Если ваш блог не будет внимательно следить за тем, как он проверяет эти запросы, то evil.example может инициировать такие действия, как удаление сообщений или добавление собственного контента.
Пользователи также становятся более осведомленными о том, как файлы cookie могут использоваться для отслеживания их активности на нескольких сайтах. Однако до сих пор не существовало способа явно заявить о своих намерениях в отношении файла cookie. Ваш файл cookie
promo_shown должен отправляться только как основной, тогда как сессионный cookie для виджета, предназначенного для встраивания на другие сайты, намеренно предназначен для обеспечения состояния входа в систему в контексте третьей стороны.
Явно укажите использование файлов cookie с помощью атрибута SameSite #
Введение атрибута SameSite (определенного в RFC6265bis) позволяет вам объявить, должен ли ваш файл cookie быть основным или внутрисайтовым. На этом моменте давайте вспомним, что именно означает «сайт». Сайтэто комбинация суффикса домена и части домена непосредственно перед ним. Например, домен www.web.dev является частью сайта web.dev .
Ключевой термин
Список публичных суффиксов public suffix list определяет это, поэтому речь не только о доменах верхнего уровня, таких как .com , но и о сервисах, таких как github.io , что позволяет считать your-project.github.io и my-project.github.io отдельными сайтами.
Ключевой термин
Введение атрибута SameSite в файл cookie предоставляет три различных способа управления этим поведением. Вы можете не указывать атрибут или использовать значения атрибута Strict или Lax , чтобы ограничить файлы cookie внутрисайтовыми запросами.
Если вы установите для атрибута SameSite значение Strict , ваш файл cookie будет отправляться только для внутрисайтовых запросов. Говоря языком пользователей, файл cookie будет отправлен только в том случае, если сайт для файла cookie совпадает с сайтом, который в данный момент отображается в адресной строке браузера. То есть, если файл cookie promo_shown задан следующим образом:
Когда пользователь находится на вашем сайте, файл cookie будет отправлен вместе с запросом, как и ожидалось. Однако при переходе по ссылке на ваш сайт, например, с другого сайта или по электронной почте от друга, при первом запросе файл cookie не будет отправлен. Это хорошо, если файлы cookie относятся к функциям, стоящим за начальной навигацией, например, сменой пароля или совершением покупки, но слишком ограничивает promo_shown . Если ваш пользователь переходит по ссылке на сайт, он хочет, чтобы файл cookie был отправлен, чтобы были применены пользовательские предпочтения.
Именно здесь и приходит на помощь SameSite=Lax , который разрешает доступ к навигации верхнего уровня. Давайте вернемся к приведенному выше примеру статьи о котике, где другой сайт ссылается на ваш контент. Они используют непосредственно вашу фотографию котика и дают ссылку на вашу оригинальную статью.
И файл cookie был задан следующим образом:
Когда читатель находится в блоге другого человека, файл cookie не будет отправлен, если браузер запросит amazing-cat.png . Однако когда читатель перейдет по ссылке на cat.html в вашем блоге, этот запрос будет включать файл cookie. Это делает значение Lax хорошим выбором для файлов cookie, влияющих на отображение сайта, а значение Strict полезным для файлов cookie, связанных с действиями пользователя.
Внимание
Наконец, можно не указывать значение, что ранее было способом неявного заявления о том, что вы хотите, чтобы файлы cookie отправлялись во всех контекстах. В последнем проекте RFC6265bis это делается явным образом путем введения нового значения SameSite=None . Это означает, что вы можете использовать значение None , чтобы четко указать, что вы намеренно хотите, чтобы файл cookie был отправлен в стороннем контексте. Файлы cookie с явно указанным контекстом None , Lax или Strict .
Изменения поведения по умолчанию без атрибута SameSite #
- если у файлов cookie не задан атрибут SameSite , будет считаться, что SameSite=Lax ;
- для файлов cookie с SameSite=None также нужно указывать параметр Secure , что означает, что такой запрос должен приходить только по защищённому каналу.
Chrome реализует это поведение по умолчанию, начиная с версии 84. В Firefox эти ключевые изменения доступны для тестирования, начиная с Firefox 69, и в будущем они будут использоваться по умолчанию. Чтобы проверить это поведение в Firefox, откройте about:config и установите network.cookie.sameSite.laxByDefault . Edge также планирует изменить свое поведение по умолчанию.
SameSite=Lax по умолчанию #
No attribute set
Если вы отправляете файл cookie без заданного значения для атрибута SameSite …
Default behavior applied
Браузер будет обрабатывать этот файл cookie, как если бы было указано SameSite=Lax .
Хотя это и задумывалось для применения более безопасного значения по умолчанию, в идеале вам следует явно задать значение атрибута SameSite , а не полагаться на то, что браузер применит его за вас. Это делает ваше намерение в отношении файлов cookie явным и повышает шансы на согласованное использование в разных браузерах.
Внимание
SameSite=None должен быть безопасным #
Установка cookie без Secure будет отклонена.
Вы должны убедиться, что для значения атрибута SameSite=None задан параметр Secure .
Вы можете протестировать это поведение в Chrome 76, включив about://flags/#cookies-without-same-site-must-be-secure и в Firefox 69, установив в about:config настройку network.cookie.sameSite.noneRequiresSecure .
Уверены, вы захотите применить эту настройку для новых файлов cookie и обновить существующие файлы cookie, даже если срок их действия еще не истек.
Оба эти изменения обратно совместимы с браузерами, которые правильно реализовали предыдущую версию SameSite или просто не поддерживают его. Применяя эти изменения к своим файлам cookie, вы явно указываете на их предполагаемое использование, а не полагаетесь на поведение браузера по умолчанию. Точно так же любые клиенты, которые еще не распознают SameSite=None должны игнорировать его и продолжать работу, как если бы атрибут не был установлен.
Предупреждение
Рецепты cookie SameSite #
Чтобы прочитать подробнее о том, как именно обновить файлы cookie для успешной обработки изменений SameSite=None и о различиях в поведении браузеров, перейдите к следующей статье, Рецепты cookie SameSite.
Благодарим за вклад и отзывы Лили Чен, Мальте Убл, Майка Уэста, Роба Додсона, Тома Штайнера и Вивека Сехара.
Что такое Cookie SameSite, какие значения может иметь этот атрибут и как убрать ошибки в консоли браузера
17.06.21 Разное 
3034
В целях совершенствования безопасности веб-ресурсов периодически появляются новые технологии и инструменты для разработки. Появление атрибута 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 можно управлять данным атрибутом как показано далее:
Кроме того, можно использовать настройки Apache. Например, чтобы задать всем Cookie на сайте нужные значения, в файле .htaccess следует прописать примерно следующее:
Header always edit Set-Cookie (.*) «$1; SameSite=Lax».
Не стоит забывать и о методе установке Cookie посредством отправки заголовков:
SameSite и кроссдоменные cookies
Cookies позволяют идентифицировать пользователя и в дальнейшем выполнять запросы от имени данного пользователя. Поэтому их безопасность очень важна. Ранее для сессионных cookies уже был добавлен параметр HttpOnly , который защищает доступ к cookies из JS и тем самым препятствует перехвату с помощью XSS -уязвимостей. Но все же оставалась возможность сделать запрос с другого домена к сайту ( example.com ), на котором авторизован пользователь, с передачей cookies посредством встраивания скрипта или вызова изображения, например:
Для того, чтобы запретить передачу 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 :
- Воспользоваться классом Cookie из пакета symfony/http-foundation : https://github.com/symfony/http-foundation/blob/master/Cookie.php
Описанные выше решения предполагают доработку кода, но установка необходимых cookies может происходить в коде вендора и поэтому либо придется его форкать, либо отказываться от обновления вендора.
Но если данные методы не подходят, то остается подмена cookies уже на стороне web -сервера:
- Для Apache необходимо в секции VirtualHost добавить подмену:
- Для Nginx в location добавляем:
Стоит отметить, что это лишь временные решения и в долгосрочной перспективе необходимо решить проблемы с Legacy и устанавливать cookies штатными средствами.