Google на время снимает ограничения в Chrome 80 на передачу Cookie между сайтами, не использующими HTTPS



    3 апреля 2020 года Джастин Шух (Justin Schuh), директор отдела Chrome Engineering, сообщил в корпоративном блоге Chromium Blog о том, что Google на неопределенное время снимает ограничения в Chrome 80 на передачу Cookie между сайтами, не использующими HTTPS.

    На такой шаг разработчикам браузера пришлось пойти из-за эпидемии коронавируса (COVID-19), чтобы минимизировать проблемы при использовании пользователями Chrome 80, которые могут возникнуть при работе с сайтами, еще не перешедшими на новый стандарт SameSite Cookie. В числе таких ресурсов есть множество банковские и медицинских сервисов, онлайн-порталов, а также сайтов государственных услуг различных стран.

    С середины февраля 2020 года в Chrome 80 была ужесточена политика относительно Cookie для сайтов, которые не используют запросы HTTPS, чтобы отсечь рекламу и трекеры отслеживания, которые подгружаются с других доменов, от домена текущей страницы. Также подобные Cookie применяются для отслеживания перемещений пользователя между сайтами в коде рекламных сетей, виджетов социальных сетей и систем web-аналитики. Ранее пользователи Chrome могли вручную отключить файлы cookie в chrome://settings/content/cookies, установив параметр «блокировать сторонние файлы cookie» на странице.

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


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

    Ранее 22 марта 2020 года стало известно, что Google полностью пропустит выпуск Chrome версии 82, после стабильного релиза Chrome 81 будет выпущен Chrome 83, об этом рассказал Джейсон Керси (Jason Kersey), представитель группы разработчиков браузера Google Chrome.

    19 марта 2020 года Google объявила, что ставит на паузу разработку новых версий браузера Chrome и собственной операционной системы Chrome OS, чтобы суметь поддержать стабильность, безопасность и надежность Chrome 80. Сейчас в Google адаптируются, изменяя под текущую ситуацию в мире свою стратегию по разработке и поддержки собственного ПО, чтобы суметь избежать появления случайных критических ошибок и сохранить бесперебойную работу команд разработчиков в условиях эпидемии коронавируса.

    С 11 марта 2020 года Google начала глобально минимизировать риск распространения коронавируса среди сотрудников. Компания перевела всех своих сотрудников в Северной Америке на удаленный домашний режим работы по крайней мере до 10 апреля 2020 года, если их текущие роли и должности это позволяют. в настоящее время на Google работают около 120 тыс. человек, а в штате компании числится около 100 тыс. сотрудников. Вдобавок Google заявила, что создала специальный денежный фонд (COVID-19 fund), на средства из которого предполагается оплачивать больничные для всего временного персонала и поставщиков компании, если у них есть симптомы вируса или они не могут прийти на работу из-за карантина. Таким образом, Google предоставит всем своим нештатным сотрудникам оплачиваемый отпуск по болезни, в случае ее выявления.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 11

      +3

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

        +2

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


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


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


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

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

          Именно так.
          Шел 2020 год… Программисты все еще рассчитывают на «мои кукисы точно не утянут с моего сайта, поэтому я буду им всегда доверять». На самом же деле уже давно надо забывать про CSRF и тому подобное. Давно уже активно развиваются API-first системы, и надо рассчитывать только на подлинность персонализации, откуда бы она не прилетела. Это же API.
          0
          Насколько я понял то теперь по умолчанию куки будут отдаваться в запросе только к тому сайту, адрес которого у вас в адресной строке браузера. Если у вас загружается картинка со стороннего сайта, то в запросе все куки будут удалены. И если этот же пользователь зайдет на другой сайт с этой же картинкой-счетчиком, то оттуда будет также выслан запрос без куки и счетчик зафиксирует эти два запроса с разных сайтов как двух разных пользователей.
            0
            Промахнулся с ответом :)
            habr.com/ru/news/t/495734/#comment_21463816
              0

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

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

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

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


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

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

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

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


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

                  0
                  Del.

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

                  Самое читаемое