Хабрахабр

Почему Google уменьшает «время жизни» cookies, полученных с помощью HTTP

Еще в начале года в компании Google сообщили, что с июля (когда выходит Chrome 68) все сайты, использующие HTTP, будут помечаться как небезопасные. В компании считают, что это позволит повысить конфиденциальность пользователей в сети.

В прошлом месяце стало известно, что Google дополнительно уменьшит «время жизни» cookies, полученных с применением незащищенного протокола, до одного года. Однако на этом работа ИТ-гиганта с HTTP не закончилась. Подробнее о ситуации расскажем далее.


/ Flickr / Jeff Herbst / PD

Представители компании отмечают, что «cookie-долгожители» позволяют проводить атаку, получившую название «всеобъемлющий мониторинг» (Pervasive Monitoring). Отправка cookies по HTTP в Google называют риском безопасности. Примером ситуации, в которой был замешан этот тип мониторинга, может быть история, когда NSA использовало PREF cookie для слежения за пользователями сети. Это масштабное (и часто скрытое) отслеживание передаваемой информации путем сбора артефактов протокола, метаданных (например, заголовков) и данных приложений.

Но так как на более защищенный протокол перешли не все (лишь 81 из 100 сайтов используют HTTPS по умолчанию), исследователи решили пойти дальше и уменьшить время жизни cookies. Google заявляют, что от подобного типа атак защищает HTTPS.

Разработчики Chrome планируют ограничить время жизни cookie. Согласно данным телеметрии Google, cookie, полученные по HTTP, «живут» больше года. Они убеждены, что так будет сложнее отследить действия пользователей в интернете на разных сайтах. И сделать это постепенно: сперва сократить до одного года, потом — до нескольких дней.

Это изменение реализуют в обновлении Chrome 70, которое выйдет в конце октября 2018 года.

Суть предложения

Инженеры Google предлагают изменить формат передачи cookie следующим образом.

Если «возраст» больше некоторого порогового значения (12 месяцев, а позднее — несколько дней), то cookie не добавляется в заголовок, а удаляется. При формировании заголовка для исходящего запроса на незащищенный URL, сперва будет проверяться дата создания каждого cookie. Если содержимое осталось прежним, то время создания нового cookie согласуется со временем создания старого. Также предлагается изменить алгоритм установки времени создания cookie.

Как это скажется на работе веб-сервисов?

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

  1. Все же перейти на HTTPS.
  2. Внедрить систему, похожую на ротацию ID в DoubleClick, значение которых повторно шифруется и обновляется каждый день. Это решение подойдет для тех, кто по каким-то причинам не может перейти на HTTPS.
  3. Отказаться от cookies как идентификаторов и использовать вместо них localStorage.


/ Flickr / Joi Ito / CC

А что с другими браузерами?

Разработчики других браузеров также пытались внедрить что-то подобное. Например, 2 года назад представители Mozilla предлагали превратить некоторые cookie браузера Firefox в сеансовые (1 и 2), но от этого предложения отказались.

Однако тестирование инициативы показало, что слишком малое число сайтов выставляют этот флаг. Идея была в том, чтобы устанавливать cookies на сессию, если они не имели флага secure. Даже сайты, которые используют HTTPS (в том числе google.com), пренебрегали этим.

Что касается предложения Google, то в компании надеются, что их решение сократить время жизни cookie подтолкнет сообщество к тому, чтобы сделать HTTPS «стандартом» в веб-среде.

О чем еще мы пишем в корпоративном блоге 1cloud:

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть