Comments 11

Может кто-нибудь внятно объяснить, какое влияние SameSite оказывает на ограничение пикселей-трекеров? Ведь владелец пикселя-трекера всегда может просто начать выдавать SameSite=None, и все, он снова работает, как и раньше работал. Какой вообще глубинный смысл SameSite, если владельцы сайтов могут его легко выставлять в none?

Во-первых чтобы не слать лишние байты в запросах.


Во-вторых чтобы предовтратить некоторые проблемы с безопасностью. Например пусть GET /post/123/delete удаляет пост 123. Злоумышленник может разместить картинку с таким адресом на своём сайте и заманить туда администратора. Куки администратора уйдут с запросом и удалится пост 123. От этих проблем традиционно борются другими способами, например CSRF токенами, использованием POST или PUT вместо GET, но корень проблемы именно в том, что куки уходят там, где разработчик сайта не ожидает, что они уйдут.


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


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

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

Именно так.
Шел 2020 год… Программисты все еще рассчитывают на «мои кукисы точно не утянут с моего сайта, поэтому я буду им всегда доверять». На самом же деле уже давно надо забывать про CSRF и тому подобное. Давно уже активно развиваются API-first системы, и надо рассчитывать только на подлинность персонализации, откуда бы она не прилетела. Это же API.
Насколько я понял то теперь по умолчанию куки будут отдаваться в запросе только к тому сайту, адрес которого у вас в адресной строке браузера. Если у вас загружается картинка со стороннего сайта, то в запросе все куки будут удалены. И если этот же пользователь зайдет на другой сайт с этой же картинкой-счетчиком, то оттуда будет также выслан запрос без куки и счетчик зафиксирует эти два запроса с разных сайтов как двух разных пользователей.

Присоединяюсь к вопросу. Насколько я понимаю, эта мера направлена только на защиту от CSRF атак.

Может кто-нибудь внятно объяснить, какое влияние SameSite оказывает на ограничение пикселей-трекеров..

По-моему всё в одну кучу смешали: отсебятину и поверхостный перевод…
Да ни как эта технология не предназначена для блокировки трекеров…
Она против CSRF-атак т. е. когда владелец сайта-хозяина cookies не хочет чтобы его подставляли на других сайтах…

Имхо самый железобетонный способ для защиты от CSRF — это проверка Origin (HTTP_ORIGIN) на стороне сервера. Потому что работает для всего и всегда (включая WebSockets по wss:// — собственно, для WebSockets только это и работает, если не считать рукодельный способ с CSRF-токеном).


Все остальное (что SameSite, что CSRF-токен) — это «костыли по месту». Поправьте меня, если неправ.

Скорее всего Вы правы, да я и не специалист в сетевых технологиях. Просто заинтересовала статья, потратил полчаса на чтение всяких английских оригиналов:
web.dev/samesite-cookies-explained
tools.ietf.org/html/draft-west-first-party-cookies-07
И просто вижу, что люди обсуждают сами не совсем понимая что…
Вы правы с точки зрения грамотной web-разработки:
это проверка Origin (HTTP_ORIGIN) на стороне сервера

Но здесь речь о браузере Chrome и компании Google, которая продвигает его и себя на рынке. Цель — позиционировать свой браузер как самый безопасный, который обрубает на корню всякие CSRF. А не учить кого-то грамотно на серверах запросы обрабатывать.

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


Впрочем на практике это из разряда "поддерживать IE 5.5". Для подавляющего большинства сайтов можно не заморачиваться. В крайнем случае при логине проверять браузер и отказывать в логине пользователям уязвимых браузеров.

Only those users with full accounts are able to leave comments. Log in, please.