В новых версиях Chrome появится защита от передачи сторонних cookie и скрытой идентификации

    Корпорация Google в новых версиях браузера Chrome сделает упор на защиту персональной информации. В частности, компания изменит подход к обработке cookie и поддержки атрибута SameSite. Уже в 76 версии, будет по умолчанию включен флаг «same-site-by-default-cookies». Если в заголовке не будет атрибута SameSite, браузер автоматически выставит значение «SameSite=Lax», которое ограничит отправку сookie для вставок со сторонних сайтов. При этом владельцы сайтов смогут снимать это ограничение, прописывая при установке сookie параметр SameSite=None.

    Атрибут SameSite дает возможность определить допустимость передачи сookie при поступлении запроса со стороннего ресурса. Сейчас сookie передаются на любой запрос к сайту, для которого обнаружены Cookie, даже в том случае, если открыт один сайт, а обращение осуществляется косвенно при помощи загрузки изображения или через iframe.

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

    Стоит отметить, что возможность отправки сookie на сторонние сайты используется и для вставки на страницы виджетов, включая интеграцию с YouTube и Facebook.

    SameSite дает возможность управлять поведением браузера при выставлении сookie. Например, разрешить отправку сookie лишь в ответ на запросы, которые инициированы с сайта, с которого сookie были получены изначально. Атрибут может принимать три значения: «Strict», «Lax» и «None». Strict — сookie не отправляются вообще, включая входящие ссылки с внешних сайтов. Lax — используются более мягкие ограничения, так что сookie блокируются лишь для межсайтовых запросов, например, для изображений или iframe.

    Есть и вариант использования жесткого ограничения, которое запрещает обработку сторонник сookie для запросов без HTTPS. Разработчики также работают над защитой пользователя от скрытой идентификации («browser fingerprinting»). Такой метод использует косвенные данные, включая разрешение экрана, параметры заголовков HTTP/2, HTTPS, анализ плагинов и шрифтов, доступность Web API, особенности отрисовки разных видеокарт, паттерны работы с мышью и клавиатурой и т.п.

    Также в новой версии Chrome применят защиту от злоупотреблений, которые связаны с затруднением возврата на исходную страницу после перехода на другой сайт. Затруднения такого рода вызываются путем искусственного добавления фиктивных записей в историю просмотров и других методов, в результате чего у пользователя нет возможности воспользоваться кнопкой Back. В новой версии Chrome обработчик кнопки будет пропускать записи, которые связаны с автоматическими пробросами и манипуляциями с историей посещений.

    Еще с версии 76 поддержка Flash будет частичной — по умолчанию технология будет отключена, но ее можно вернуть в настройках «Расширенные > Приватность и безопасность > Свойства сайтов». Полное прекращение поддержки Flash планируется с 2020 года. Отключение плагина Flash от Adobe планируется уже в этом году.
    Поделиться публикацией

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

      +2
      Либо для Google Analytics будет исключение, либо гугл придумал ещё один способ ставить межсайтовые маячки, что напрягает. В последнем случае все конкурирующие рекламные сети резко обломаются, один лишь GA будет как-то работать.
        0
        Google Analytics — это скрипт, а не запрос к другому сайту. Данный скрипт выполняется в пределах текущего сайта, и кука ставится тоже на текущем. Т. е. на Google Analytics это не повлияет.

        В статье говорилось о запросах, например, картинках, AJAX, файлах (например, javascript; да, кука не будет передаваться, но если этот javascript идёт на выполнение, то он может поставить сам куку где надо), iframe и т. д. Причём кука ставится именно на чужом сайте, а не текущем. Проблем с безопасностью это не даёт, но позволяет отслеживать пользователя, если автор сайта использует твои файлы.
          +1
          Нет, GA как раз использует межсайтовые куки наряду с локальными для сайта. И конечно для таких кук будет исключение. Не только для Гугла, а вообще для всех. Установка SameSite в None, как описано в статье.
          Само обновление направлено не на борьбу с межсайтовой идентификацией в принципе, а только на несанкционированное использование, когда сервер ставит куки для внутреннего использования, а ресурс загружают извне (и в теории, могут получить значение этих кук, если сервер их выдает).
            +1
            Только что проверил — GA не использует куки при запросе к своим серверам. Куки ставятся только на текущем сайте, а потом просто добавляются в запрос как обычный параметр (без всяких кук). Таким образом, нововведение никак не затронет GA, о чём я и сказал в своём комментарии выше.

            Многие рекламные сети тоже не будут затронуты, по крайней мере в тех случаях, когда автор сайта ставит под угрозу свой сайт и запускает их скрипты без всяких iframe и ограничений на него. А если скрипт запускается безопасно, или если это изначально iframe, то автору сайта для возможности идентификации юзера рекламной сетью придётся установить SameSite=«Lax» (хотя логичнее было бы дать возможность указать конкретные домены, например, свой соседний домен (при условии, что верхний не даёт важных кук нижним) или домен более верхнего уровня, либо домен рекламной сети).
            0
            Под исключением GA я подразумевал соответствующий домен (www.google-analytics.com). А так, да — скрипт GA, выполняющийся на новом сайте (куда пользователь ранее не заходил), отправляет запрос на www.google-analytics.com, и браузер в этот запрос добавляет сохранённые куки (от этого домена), что позволяет GA подключить сессию на новом сайте к общей истории пользователя.
            И конечно для таких кук будет исключение. Не только для Гугла, а вообще для всех. Установка SameSite в None, как описано в статье
            Интересно, какое поведение будет по умолчанию. Если такое, как без этого атрибута, то наверное большой паники не будет, просто кто захочет — сможет улучшить безопасность.
              +2
              Почему не хотите текст статьи прочитать?
              Уже в 76 версии, будет по умолчанию включен флаг «same-site-by-default-cookies». Если в заголовке не будет атрибута SameSite, браузер автоматически выставит значение «SameSite=Lax», которое ограничит отправку сookie для вставок со сторонних сайтов. При этом владельцы сайтов смогут снимать это ограничение, прописывая при установке сookie параметр SameSite=None.
                –1
                ок, то есть с одной стороны, гугл хочет автоматически «защитить» некоторые сайты, а с другой, подорвать работу тех рекламных сетей, которые не внесут изменения в свой серверный код, добавляя chrome-only фичу.
                  0
                  А опишите решение, которое позволит сделать первое, не сделать второе, и поясните почему это решение лучше, чем эта фича.
                    0
                    Такое чувство, что у нас есть какая-то установка — найти в любых действиях Гугла негатив (не особо вникая в суть самого действия). Порой это трудно, но вы стараетесь, стараетесь…
                      +1
                      Что это за рекламные сети, которые не вносят изменения в свой серверный код?
                    +1
                    Интересно, какое поведение будет по умолчанию.
                    Я Вас не понял. В статье же сказано — по умолчанию будет Lax, т. е. сторонние куки будут блокироваться. На Google Analytics это никак не повлияет, смотрите мой комментарий.
                      0
                      Проверил, действительно нет кук. Но кажется, когда-то я их видел там.

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

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