Photo by Mohammad Rahmani on Unsplash
Начиная с версии 84, Chrome по умолчанию устанавливает атрибут SameSite для Cookie в Lax. Сервисы, использующие Third-party cookies, могут пострадать, если они не настроили SameSite должным образом.
Обзор
Cookies — это механизмы, используемые в веб-сервисах для хранения состояния, обычно используемые для поддержки сеансов входа в систему, корзин покупок, отслеживания рекламы и т. д. Однако широкое использование Cookies также вызывает опасения по поводу конфиденциальности и безопасности, и SameSite был введен для решения этих проблем.
First-Party and Third-Party
В зависимости от источника Cookie (Set-Cookie), каждый Cookie имеет определенный домен (Domain). Если посмотреть на текущий URL в браузере пользователя, если домен Cookie совпадает с текущим URL, это First-Party; в противном случае это Third-Party.
Third-party
Например, при просмотре сайта a.com отправляется запрос (request) на third-party.com и принимается Cookie от third-party.com. Поскольку браузер автоматически включает в запросы Cookies с тем же доменом, если вы позже посетите другой сайт, например b.com, и он также отправит запрос на third-party.com, сервер получит Cookie. Для этих двух сайтов Cookie third-party.com является Third-party.
First-party
Если вы просматриваете веб-сайт, соответствующий домену third-party.com, Cookie также будет отправлен. В этом случае этот Cookie называется First-Party.
Same-Origin and Same-Site
В предыдущем примере упоминалось использование домена для определения типа Cookie, но лучше определить, является ли Сайт (Site) тем же самым. Связано ли это с часто встречающимся Same-origin?
Origin
Происхождение (Origin) состоит из схемы (Scheme), хоста (Host) и порта (Port). Метод определения очень прост: если схема, хост и порт двух URL идентичны, они являются Same-origin; в противном случае они Cross-origin.
Site
Определение Same-Site включает эффективные домены верхнего уровня (eTLD). Все eTLD определены в Public Suffix List, а Сайт состоит из eTLD и префикса.
Например:
github.io существует в Public Suffix List. Добавление префикса (например, a.github.io) делает его Сайтом. Следовательно, a.github.io и b.github.io — это два разных Сайта (Cross-site).
example.com не существует в Public Suffix List, но .com существует, поэтому example.com — это Сайт, а a.example.com и b.example.com — один и тот же Сайт (Same-site).
Обратите внимание, что Сайт не включает Порт, поэтому даже если Порты разные, они все равно могут быть Same-site.
Why SameSite?
Механизм, при котором «любой запрос несет файлы cookie этого домена», также принес проблемы безопасности и другие проблемы, наиболее важной из которых является подделка межсайтовых запросов (CSRF).
CSRF
Предположим, пользователь вошел на example.com и получил Cookie. Когда пользователь посещает вредоносный сайт evil.com, JavaScript на этом сайте может отправить POST-запрос на example.com/pay?amount=1000. Браузер автоматически включит Cookie example.com, и пользователь неосознанно заплатит 1000 долларов. Сервер не может определить, откуда пришел этот запрос.
Ограничения
Сами Cookies нельзя настроить на отправку только в First-party среде, поэтому запросы несут Cookies в любой среде. Сервер не может идентифицировать источник запроса и может только отвечать как обычно, заставляя Клиента тратить пропускную способность на отправку бесполезных Cookies.
Решение
С помощью атрибута SameSite мы можем индивидуально настраивать условия отправки Cookies в разных средах.
SameSite
Атрибут SameSite имеет три значения. Установка его в Strict или Lax может ограничить отправку Cookies только в Same-Site запросах. Если оставить пустым, поведение зависит от браузера; для Chrome значение по умолчанию — Lax.
Strict
Cookies отправляются только в среде First-party. Однако есть проблема: предположим, пользователь видит ссылку на пост в Facebook на example.com (скажем, fb.com). Даже если пользователь вошел в fb.com и имеет Cookie, переход по ссылке не отправит Cookie, потому что два сайта являются Cross-site, поэтому он увидит только страницу входа.
Поэтому Strict подходит для чувствительных действий, таких как удаление постов, совершение платежей и т. д.
Lax
Чтобы устранить слишком строгие ограничения Strict, Lax разрешает отправку Cookies даже в ситуациях Cross-site в следующих случаях:
- Ввод URL в адресную строку
- Клик по ссылке
<a href="..."> - Отправка формы
<form method="GET"> - Prerendering
<link rel="prerender" href="...">
Эти случаи имеют две общие черты: все они являются GET запросами и все они запускают навигацию верхнего уровня (Top-level Navigation). Это позволяет избежать проблемы, когда Strict требует повторного входа каждый раз, а также предотвращает неосознанную отправку Cookies при просмотре других веб-сайтов.
Lax + POST
Однако, чтобы не нарушать некоторые существующие процессы входа в систему, Chrome в настоящее время немного ослабляет ограничение для SameSite=Lax, давая разработчикам больше времени на адаптацию.
В течение двух минут после установки Cookie, независимо от метода запроса (Request Method), пока он запускает навигацию страницы верхнего уровня, Cookie будет отправлен. Это означает, что если браузер меняет страницу, например, отправляя форму <form method="POST">.
Подробности см. в обсуждении о Lax + POST.
None
Чтобы отправить Third-party cookie, вы должны установить SameSite=None; Secure. Да, теперь, если вы хотите отправить Third-party cookie в тестовой среде, пожалуйста, подготовьте https://localhost.
Кроме того, отправка Cross-Origin Requests через XHR/Fetch требует установки withCredentials: true для отправки Cookie и вступления в силу Set-Cookie в заголовке ответа. Сервер также должен установить Access-Control-Allow-Credentials: true в заголовке ответа, чтобы JavaScript мог получить доступ к содержимому ответа.
Неподдерживаемые браузеры
Не все браузеры поддерживают последние правила SameSite, поэтому на сервере можно добавить некоторые временные обходные пути (Workarounds) для поддержки нескольких браузеров:
Установить оба Cookie
Этот метод может решить проблемы почти для всех браузеров, но недостатком является то, что будет две копии Cookie:
Set-cookie: name=value; SameSite=None; Secure
Set-cookie: name-legacy=value; Secure
Код на стороне сервера:
if (req.cookies['name']) {
// Использовать новый, если доступен
cookieVal = req.cookies['name'];
} else if (req.cookies['name-legacy']) {
// В противном случае использовать старый
cookieVal = req.cookies['name-legacy'];
}
User Agent
Определить браузер, используя User agent запроса, чтобы решить содержимое Set-Cookie. Этот метод требует только изменения кода, устанавливающего Cookie, без изменения части парсинга (Parsing). Однако этот метод суждения включает больше переменных и облегчает установку неправильного Cookie.
Обзор
- Cookies без установленного атрибута SameSite по умолчанию будут иметь
SameSite=Laxине могут быть отправленыв среде Cross-site. - Чтобы отправить Cookies в Cross-site, вам нужно установить
SameSite=None; Secure. - Вы можете использовать SameSite sandbox чтобы проверить, соответствует ли ваш текущий браузер последним правилам SameSite.