samesite cookie что это

15.08.202303.07.2023 admin 0 Comments

Работа с SameSite cookie s в ASP.NET Core

Автор: Рик Андерсон (Rick Anderson)

каждый компонент ASP.NET Core, порождаемый cookie s, должен решить, подходит ли SameSite.

SameSite и Identity

Пример кода теста SameSite

Следующие примеры можно скачать и протестировать:

Следующий пример можно скачать и протестировать:

Изменения режима работы с декабрьским обновлением

Использование API с SameSite

все компоненты ASP.NET Core, которые выдают cookie s, переопределяют предыдущие значения по умолчанию параметрами, подходящими для их сценариев. Переопределенные ранее значения по умолчанию не изменились.

Компонент	cookie	По умолчанию
CookieBuilder	SameSite	Unspecified
Session	Сессионоптионс.Cookie	Lax
CookieTempDataProvider	CookieТемпдатапровидероптионс.Cookie	Lax
IAntiforgery	Антифоржерйоптионс.Cookie	Strict
Cookie Идентификаци	CookieAuthenticationOptions.Cookie	Lax
AddTwitter	Твиттероптионс. штат Cookie	Lax
RemoteAuthenticationHandler	Ремотеаусентикатионоптионс. CorrelationCookie	None
AddOpenIdConnect	Опенидконнектоптионс. nonceCookie	None
HttpContext. Response. Cookie s. append	CookieOptions	Unspecified

ASP.NET Core 3,1 и более поздних версий предоставляет следующую поддержку SameSite:

Журнал и изменения

Исправления были выпущены в ноябре 2019, чтобы обновить стандарт 2016 до стандарта 2019. 2019. черновик спецификации SameSite:

API-интерфейсы, затрагиваемые изменением стандарта 2016 SameSite с черновым стандартом на версию 2019

Поддержка старых браузеров

В Startup.Configure добавьте код, вызывающий UseCookiePolicy перед вызовом UseAuthentication метода, или любой метод, который выполняет запись cookie s:

В Startup.ConfigureServices добавьте код, аналогичный приведенному ниже:

В предыдущем примере MyUserAgentDetectionLib.DisallowsSameSiteNone — это библиотека, предоставляемая пользователем и определяющая, не поддерживает ли агент пользователя SameSite None :

В следующем коде показан пример DisallowsSameSiteNone метода:

Следующий код предназначен только для демонстрации:

Тестирование приложений на наличие проблем SameSite

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

Протестируйте веб-приложения с помощью версии клиента, которая может явно использовать новое поведение SameSite. для Chrome, Firefox и Chromium ребра доступны новые флаги функций выбора, которые можно использовать для тестирования. Когда приложение применяет исправления SameSite, протестируйте его с помощью более старых версий клиента, особенно Safari. Дополнительные сведения см. в разделе поддержка старых браузеров в этом документе.

Тестирование с помощью Chrome

Тестирование с помощью Safari

Тестирование с помощью Firefox

Тестирование с помощью браузера пограничных устройств

Ребро поддерживает старый стандарт SameSite. Версия 44 не имеет известных проблем совместимости с новым стандартом.

Тестирование с помощью ребра (Chromium)

Тест с Electron

Версии Electron включают более старые версии Chromium. например, версия, Electron используемая Teams, — Chromium 66, что приводит к более старому поведению. Необходимо выполнить собственное тестирование совместимости с используемой версией Electron продукта. См. раздел Поддержка более старых браузеров в следующем разделе.

Источник

Как изменения в Chrome могут сломать ваш сайт: подробный гид по обновленному атрибуту SameSite для обработки cookie

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

Что такое 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-код ссылки из письма выглядит следующим образом:

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

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

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

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

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

— 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 80.

Шаг 2

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

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

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

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

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

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

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

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

Источник

С 2016 года Chromium поддерживает параметр куков SameSite, который, как следует из названия, ограничивает передачу куков пределами одного сайта. У параметра есть три состояния, которые разрешают передачу куков:

В теории SameSite помогает обезопасить данные от необоснованного трекинга и межсайтовых подделок запроса — CSRF. Но если разработчики сайта не настроили параметр, сервер автоматически выставляет SameSite=None и обращается с куками как со сторонними, свободно отправляя их направо и налево. Спойлер: по данным Google на март 2019, SameSite был проставлен лишь у 0,1% куков.

Поэтому в мае 2019 Google с Microsoft опубликовали проект “Incrementally Better Cookies”, где предложили по умолчанию считать все куки куками первого порядка. В виде эксперимента эти настройки были введены для небольшого числа пользователей Chrome еще в октябре 2019 года. А уже в феврале 2020 Google официально внес новые правила в Chrome 80 Stable. Теперь отправлять куки сторонним доменам можно только через HTTPS, предварительно поменяв атрибут нужных куков с дефолтного SameSite=Lax на SameSite=None.

Пока что новые настройки выкатили среди нескольких процентов пользователей Chrome 80 Stable и увеличивают это число постепенно. С выходом Chrome 81-82 Canary/Dev/Beta новые правила распространятся на 50% пользователей, и их число также будет расширяться.

Аналогичные настройки будут вводить Microsoft Edge и Mozilla Firefox.

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

Веселье начнется со следующим шагом в сторону куков получше, так как в представлении Google хорошие куки — это мертвые куки. Google рассчитывает избавиться от сторонних куков за 2 года и взамен предлагает использовать HTTP State Tokens и набор API. Эта инициатива получила название Privacy Sandbox.

Интернет на куках держится. Аутентификация, история просмотров сайтов, страниц и медиа-элементов (вшитый плеер, баннер, кнопка репоста), метрики/ счетчики/трекинги, подстройка страниц под устройство, браузер и пользовательские настройки — везде нужны куки для хранения и передачи релевантных данных от сервера к браузеру и обратно.

Но универсальность куков легко превращается в минус, потому что способствует бесконтрольному трекингу пользователей.

Взамен Гугл предлагает использовать HTTP State Tokens. Процесс в теории выглядит так: браузер отправляет закриптованный токен серверу сайта через заголовок http — только по одному токену на источник и только через безопасное соединение.

Значение токена контролируются клиентом, а не сервером, и выглядит как случайный набор байтов фиксированной длины. Соответственно, сервер не знает о пользователе ничего, но может подписать верифицированные токены своим закриптованным ключом и указать в ответе дополнительные атрибуты: дату создания токена, допустимый контекст передачи (same origin, same site [default], cross site), время действия токена [1 час — default], значение.

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

Google предложил ряд API для решения некоторых задач:

Общая тенденция — передать контроль над пользовательскими данными пользователю — конечно же правильная. Использование криптографии тоже можно оценивать только позитивно. В то же время отказ от куков спасет только от трекинга по кукам, остается еще довольно способов отследить уникального пользователя, на которые он уже не сможет повлиять.

Как на монетизацию издателей повлияет исчезновение персонализированной рекламы? Как изменятся отношения между ad-tech, издателями, рекламодателями и теперь еще и браузером? Возможно ли за два года продумать и воплотить безболезненный переход к интернету без куков? За чей счет? В конце концов, индустрия рекламы использует куки и отслеживает отдельных пользователей, потому что без этого никак или просто потому что может? Время покажет.

Источник

Работа с файлами cookie SameSite в ASP.NET

Автор: Рик Андерсон (Rick Anderson)

Каждый компонент ASP.NET, порождаемый файлами cookie, должен решить, подходит ли SameSite.

Использование SameSite в ASP.NET 4.7.2 и 4,8

.NET 4.7.2 и 4,8 поддерживает черновой стандарт 2019 для SameSite с момента выпуска обновлений в декабре 2019. Разработчики могут программно управлять значением заголовка SameSite с помощью Свойства HttpCookie. SameSite. Присвоение SameSite свойству Strict Lax значения, или None приводит к записанию этих значений в сети с помощью файла cookie. Задание этого параметра (SameSiteMode)(-1) означает, что заголовок SameSite не должен включаться в сеть с файлом cookie. Свойство HttpCookie. Secureили «requireSSL» в файлах конфигурации можно использовать, чтобы пометить куки-файл как Secure или нет.

ASP.Net также выдает четыре отдельных файла cookie для этих функций: Анонимная проверка подлинности, проверка подлинности с помощью форм, состояние сеанса и управление ролями. Экземпляры этих файлов cookie, полученные в среде выполнения, можно манипулировать с помощью SameSite свойств и, как и для Secure любого другого экземпляра HttpCookie. Однако из-за одеяланого последовательного SameSite стандарта параметры конфигурации для этих четырех компонентов не согласуются. Ниже приведены соответствующие разделы и атрибуты конфигурации со значениями по умолчанию. Если SameSite для функции отсутствует или не Secure связан атрибут, то эта функция будет возвращаться к значениям по умолчанию, настроенным в system.web/httpCookies разделе, описанном выше.

Убедитесь, что web.config содержит следующее:

Verify the project file contains the correct TargetFrameworkVersion:

В предыдущем packages.config файле Microsoft.ApplicationInsights пакет:

Изменения режима работы с декабрьским обновлением

Сводка влияния изменений на браузеры

Это значит, что приложение прерывается в Chrome или вы разбиваете на несколько других мест.

Журнал и изменения

Известные проблемы

Служба приложений Azure — обработка файлов cookie SameSite

Поддержка старых браузеров

Подход корпорации Майкрософт к устранению проблемы заключается в том, чтобы помочь вам реализовать компоненты обнаружения браузеров, чтобы удалить sameSite=None атрибут из файлов cookie, если известно, что браузер не поддерживает его. Советом Google было выдавать двойные файлы cookie, один с новым атрибутом и один без атрибута. Однако мы будем рассматривать советы Google в ограниченном объеме. Некоторые браузеры, особенно мобильные браузеры, имеют очень малые ограничения на количество файлов cookie, которые может отправить сайт или имя домена. Отправка нескольких файлов cookie, особенно больших файлов cookie, таких как файлы cookie проверки подлинности, максимально быстро достигают мобильного браузера, вызывая сбои в работе приложений, которые трудно диагностировать и исправить. Кроме того, в качестве платформы существует большая экосистема кода и компонентов сторонних производителей, которые не могут быть обновлены для использования подхода двойного файла cookie.

Эти обнаружения являются наиболее распространенными агентами браузера, которые поддерживают стандарт 2016 и, для которого атрибут необходимо полностью удалить. Это не является полной реализацией:

См. следующие разделы ASP.NET 4.7.2 SameSite cookie:

Обеспечение перенаправления сайта по протоколу HTTPS

В локальных установках перезаписи URL-адресов IIS является необязательным компонентом, который может потребоваться для установки.

Тестирование приложений на наличие проблем SameSite

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

Следует убедиться, что файлы cookie создаются, сохраняются и удаляются в приложении правильно.

Протестируйте веб-приложения с помощью версии клиента, которая может явно использовать новое поведение SameSite. У Chrome, Firefox и Chromium ребра есть новые флаги функций выбора, которые можно использовать для тестирования. Когда приложение применяет исправления SameSite, протестируйте его с помощью более старых версий клиента, особенно Safari. Дополнительные сведения см. в разделе поддержка старых браузеров в этом документе.