Cookie — Википедия

Ку́ки (англ. cookie, букв. «печенье») — небольшой набор данных, отправляемый веб-сервером и хранимый на компьютере пользователя без изменений и какой-либо обработки. Веб-клиент (обычно веб-браузер) всякий раз при обращении к соответствующему сайту пересылает эти данные веб-серверу в составе HTTP-запроса. Обычно куки применяют для^[1]:

• аутентификации пользователя;
• хранения персональных предпочтений и настроек пользователя;
• отслеживания состояния сеанса доступа пользователя;
• хранения сведений статистики о пользователе.

Поддержки браузерами куки (приём, сохранение и последующая пересылка серверу сохранённого) требуют многие сайты с ограничениями доступа, большинство интернет-магазинов^[2]. Настройка оформления и поведения многих веб-сайтов по индивидуальным предпочтениям пользователя тоже основана на куки^[1].

В потоке данных куки легко перехватить, сохранить или подменить (например, для получения доступа к учётной записи), если пользователь использует нешифрованное соединение с сервером. В группе риска — пользователи, выходящие в интернет при помощи публичных точек доступа Wi-Fi и не использующие при этом таких механизмов, как SSL и TLS. Шифрование позволяет также решить и другие проблемы, связанные с безопасностью передаваемых данных.

Большинство современных браузеров позволяет пользователям выбрать — принимать куки или нет, но их отключение делает невозможной работу с некоторыми сайтами. Можно включить автоматическое стирание куки при выключении браузера. Кроме того, по законам некоторых стран (например, согласно постановлению Евросоюза от 2016 года, см. общий регламент по защите данных) сайты должны в обязательном порядке запрашивать согласие пользователя перед установкой куки.

В рамках усиливающихся тенденций защиты приватности данных пользователей технологические компании, такие как Google, Apple и другие, предпринимают меры для ограничения использования сторонних куки. В первую очередь это оказывает влияние на рекламный рынок, заставляя его искать альтернативы. Прогнозируемый в будущем полный отказ от куки называют Post-cookie world^[3].

Cookie используются веб-серверами для идентификации пользователей и хранения данных о них.

К примеру, если вход на сайт осуществляется при помощи cookie, то, после ввода пользователем своих данных на странице входа, cookie позволяют серверу запомнить, что пользователь уже идентифицирован и ему разрешён доступ к соответствующим услугам и операциям^[1].

Многие сайты также используют cookie для сохранения настроек пользователя. Эти настройки могут использоваться для персонализации, которая включает в себя выбор оформления и функциональности. Например, Википедия позволяет авторизованным пользователям выбрать дизайн сайта. Поисковая система Google позволяет пользователям (в том числе и не зарегистрированным в ней) выбрать количество результатов поиска, отображаемых на одной странице^[4].

Cookie также используются для отслеживания действий пользователей на сайте. Как правило, это делается с целью сбора статистики, а рекламные компании на основе такой статистики формируют анонимные профили пользователей для более точного нацеливания рекламы^[5].

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

Спецификации^[6][7] указывают минимальные объёмы, которые должны предоставляться браузерами для хранения cookie. Так, браузер должен хранить по меньшей мере 300 cookie по 4096 байт каждая и по меньшей мере 20 cookie для одного сервера или домена.

Популярные браузеры имеют соответствующий максимум хранящихся cookie для каждого домена:

• Internet Explorer 6 — 20
• Internet Explorer 7 — 20
• Opera 9 — 30
• Firefox 2.0 — 50
• Google Chrome 58.0 — 176
• Safari 10.0 — 242

На практике некоторые браузеры могут накладывать более жёсткие ограничения. К примеру, Internet Explorer предоставляет 4096 байт для всех cookie в одном домене.

Имена cookie нечувствительны к регистру в соответствии с разделом 3.1 RFC 2965.

Cookie могут устанавливать дату их удаления, в этом случае они будут автоматически удалены браузером в указанный срок. Если дата удаления не указана, cookie удаляются сразу, как только пользователь закроет браузер. Таким образом, указание даты истечения позволяет сохранить cookie более чем на один сеанс, и такие cookie называются постоянными. Например, интернет-магазин может использовать постоянные cookie для хранения кодов предметов, которые пользователь поместил в корзину покупок, — и даже если пользователь закроет браузер не совершив покупки, при последующем входе ему не придётся формировать корзину заново.

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

По одной из версий, термин «куки» (печенье) происходит от «волшебного печенья»^[8] — набора данных, которые программа получает и затем отправляет обратно неизменными. В июне 1994 года Лу Монтулли пришла идея использовать их при веб-соединении^[9]. В то время он был сотрудником Netscape Communications, которая разрабатывала по заказу пакет электронной коммерции. Cookie стали решением проблемы надёжной реализации виртуальной корзины покупок.

С помощью Джона Джаннандреа в тот же год Монтулли написал начальную спецификацию cookie. Mosaic Netscape 0.9beta, выпущенная 13 октября 1994 года^[10][11], уже поддерживала cookie. Cookie впервые начали использоваться вне лаборатории на сайте Netscape и определяли, посещал ли пользователь сайт ранее. Монтулли подал заявку на патент в 1995 году и получил его в 1998 году. Internet Explorer начал поддерживать cookie с версии 2, выпущенной в октябре 1995 года^[12].

Хотя некоторые люди знали о существовании cookie уже в первом квартале 1995 года^[13], широкая общественность узнала о них лишь после статьи в «Financial Times» от 12 февраля 1996 года. В том же году cookie оказались в центре внимания средств массовой информации, особенно из-за потенциальной угрозы приватности. Cookie были рассмотрены в Федеральной комиссии по торговле США в двух слушаниях в 1996 и 1997 годах.

Развитие спецификаций cookie на этом не остановилось. В частности, первые обсуждения формальной спецификации начались в апреле 1995 года. Была сформирована специальная рабочая группа в рамках IETF. В качестве отправной точки была выбрана спецификация Netscape. В феврале 1996 года рабочая группа определила сторонние cookie как серьёзную угрозу приватности. Выработанная спецификация была выпущена под названием RFC 2109 в феврале 1997 года. В ней указывалось, что сторонние cookie должны либо блокироваться, либо хотя бы не работать по умолчанию.

В то время рекламные компании уже вовсю использовали сторонние cookie и рекомендации RFC 2109 не поддерживались ни в браузерах Netscape, ни в Internet Explorer. Позднее, в октябре 2000 года, RFC 2109 была заменена новой спецификацией RFC 2965.

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

Вместо того чтобы удаляться после закрытия браузера, как это делают сессионные cookie, постоянные cookie-файлы удаляются в определённую дату или через определённый промежуток времени. Это означает, что информация о cookie будет передаваться на сервер каждый раз, когда пользователь посещает веб-сайт, которому эти cookie принадлежат. По этой причине постоянные cookie иногда называются следящие cookie, поскольку они могут использоваться рекламодателями для записи о предпочтениях пользователя в течение длительного периода времени. Однако они также могут использоваться и в «мирных» целях, например, чтобы избежать повторного ввода данных при каждом посещении сайта.

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

В качестве примера предположим, что пользователь посещает www.example.org. Этот веб-сайт содержит рекламу от ad.foxytracking.com, которая при загрузке устанавливает файл cookie, принадлежащий домену рекламы (ad.foxytracking.com). Затем пользователь посещает другой веб-сайт www.foo.com, который также содержит рекламу от ad.foxytracking.com и устанавливает файл cookie, принадлежащий этому домену (ad.foxytracking.com). В конце концов, оба этих cookie будут отправлены рекламодателю при загрузке их рекламы или посещении их веб-сайта. Затем рекламодатель может использовать эти cookie для создания истории просмотров пользователя на всех веб-сайтах, на которых размещена реклама этого рекламодателя.

По состоянию на 2014 год некоторые веб-сайты устанавливали cookie для чтения более чем на 100 сторонних доменах^[15]. В среднем на одном веб-сайте было установлено 10 файлов cookie, при этом максимальное количество файлов cookie (как для сторонних, так и для третьих сторон) может превышать 800^[16]. Большинство современных веб-браузеров содержит настройки конфиденциальности, которые могут блокировать сторонние cookie.

Супер-cookie — это cookie-файл с источником домена верхнего уровня (например, .ru) или общедоступным суффиксом (например, .co.uk). Обычные cookie, напротив, имеют происхождение от конкретного доменного имени, например example.com.

Супер-cookie могут быть потенциальной проблемой безопасности и поэтому часто блокируются веб-браузерами. Если браузер разблокирует вредоносный веб-сайт, злоумышленник может установить супер-cookie и потенциально нарушить или выдать себя за законные запросы пользователей на другой веб-сайт, который использует тот же домен верхнего уровня или общедоступный суффикс, что и вредоносный веб-сайт. Например, супер-cookie с происхождением .com может злонамеренно повлиять на запрос к example.com, даже если файл cookie не был создан с сайта example.com. Это может быть использовано для подделки логинов или изменения информации пользователя.

Публичный список суффиксов^[17] помогает снизить риск, который представляют супер-cookie. Публичный список суффиксов — это инициатива кросс-вендоров, целью которого является предоставление точного и актуального списка суффиксов доменных имен. В старых версиях браузеров может отсутствовать актуальный список, и поэтому они будут уязвимы для супер-cookie из определённых доменов.

Термин «supercookie» (супер-cookie) иногда используется для отслеживания технологий, которые не используют файлы cookie HTTP. В августе 2011 года на веб-сайтах Microsoft были обнаружены два таких механизма «супер-cookie»: синхронизация файлов cookie, которая порождает cookie MUID (уникальный идентификатор машины), и cookie ETag^[18]. Из-за внимания средств массовой информации Microsoft позже отключила этот код^[19].

Поскольку cookie можно очень легко удалить из браузера, программисты ищут способы идентифицировать пользователей даже после полной очистки истории браузера. Одним из таких решений являются зомби-cookie (или evercookie, или persistent cookie) — неудаляемые или трудно удаляемые cookie, которые можно восстановить в браузере с помощью JavaScript. Это возможно потому, что для хранения куки сайт одновременно использует все доступные хранилища браузера (HTTP ETag, Session Storage, Local Storage, Indexed DB), в том числе и хранилища приложений, таких как Flash Player (Local Shared Objects), Microsoft Silverlight (Isolated Storage) и Java (Java persistence API). Когда программа обнаруживает отсутствие в браузере cookie-файла, информация о котором присутствует в других хранилищах, она тут же восстанавливает его на место и тем самым идентифицирует пользователя для сайта.

RFC 6265 даёт конкретные указания, как нужно интерпретировать каждый из параметров cookie:

• name устанавливает имя cookie-файла.
• value сохраняет значение cookie, которое будет идентифицировать пользователя или содержать служебную информацию.
• expires и max-age определяют срок жизни cookie, по истечении которого она будет автоматически удалена. Если не указать этот параметр или установить его значение в ноль, то cookie будут автоматически удалены при закрытии браузера. Для параметра expires указывается конечная дата в формате Tue, 01-Sep-2020 10:50:22 GMT, тогда как для max-age устанавливается количество секунд жизни cookie с момента установки её в браузер.
• path указывает путь к директории на сервере, для которой будут доступны cookie. Если указать корневой каталог /, то cookie будут доступны всему домену. По умолчанию значением является текущая директория, из которой cookie устанавливаются в браузер.
• domain отмечает, какой домен или поддомен имеет доступ к этой cookie. Для того чтобы сделать cookie доступными для всего домена (включая поддомены), нужно просто указать имя домена (например example.com).
• secure параметр указывает браузеру, что cookie должны передаваться на сервер только по защищённому https-соединению.
• httponly параметр запрещает доступ к cookie посредством API document.cookie. Эта возможность была предложена в качестве меры для эффективного предотвращения краж cookie посредством XSS-атак.
• samesite — это относительно новый параметр (определённый в RFC 6265bis), который сообщает браузерам, что cookie не должны отсылаться с межсайтовыми запросами. Это в некотором роде обеспечивает защиту от межсайтовых подделок запроса (CSRF). У этого параметра есть три состояния, которые определяют поведение cookie для различных сценариев пользования сайтом.
  1. samesite=none прямо указывает, что на передачу cookie-файлов не накладывается никаких ограничений.
  2. samesite=lax разрешает передачу cookie только безопасными HTTP-методами, которыми, согласно RFC 7231, являются GET, HEAD, OPTIONS и TRACE.
  3. samesite=strict, или просто samesite, является самым строгим вариантом безопасности и блокирует отправку cookie с любыми запросами от других ресурсов. Cookie будут передаваться только в пределах того домена, с которого они и были установлены.

В 2015 году был утверждён документ, обновляющий спецификацию RFC 6265, в котором добавили набор ограничений на имена для файлов cookie. Для обеспечения дополнительной безопасности специалистами были предложены специальные префиксы имён __Secure- и __Host-, указывающие браузеру на необходимость соблюдения специальных требований при получении файлов cookie от сервера^[20].

• Cookie с префиксом __Secure- должны устанавливаться:
  1. С параметром secure;
  2. Через безопасное https-соединение.
• Cookie с префиксом __Host- должны устанавливаться:
  1. С параметром secure;
  2. Через безопасное https-соединение.
  3. Без параметра domain;
  4. С параметром path=/.

При нарушении хотя бы одного из перечисленных требований установка cookie-файла в браузер будет отклонена. Поддержка префиксов реализована в браузерах Chrome 49+, Firefox 50+ и Opera 36+^[21].

При включении всех вышеперечисленных параметров запрос на установку cookie от сервера будет иметь следующий вид:

Set-Cookie: __Secure-name=value; max-age=31536000; domain=example.com; path=/; secure; httponly; samesite=lax

Как и любой другой HTTP-заголовок, cookie должны передаваться в браузер до того, как будут переданы какие-либо другие данные, включая пустые строки и пробельные символы (это ограничение HTTP-протокола).

Запрашивая страницу, браузер отправляет веб-серверу короткий текст с HTTP-запросом. Например, для доступа к странице http://www.example.org/index.html браузер отправляет на сервер www.example.org следующий запрос:1

Сервер отвечает, отправляя запрашиваемую страницу вместе с текстом, содержащим HTTP-ответ. Там может содержаться указание браузеру сохранить cookie:

Строка Set-cookie отправляется лишь тогда, когда сервер желает, чтобы браузер сохранил cookie. В этом случае, если cookie поддерживаются браузером и их приём включён, браузер запоминает строку name=value (имя = значение) и отправляет её обратно серверу с каждым последующим запросом. Например, при запросе следующей страницы http://www.example.org/spec.html браузер пошлёт серверу www.examle.org следующий запрос:

Этот запрос отличается от первого запроса тем, что содержит строку, которую сервер отправил браузеру ранее. Таким образом, сервер узна́ет, что этот запрос связан с предыдущим. Сервер отвечает, отправляя запрашиваемую страницу и, возможно, добавив новые cookie.

Значение cookie может быть изменено сервером путём отправления новых строк Set-Cookie: name=new_value. После этого браузер заменяет старое cookie с тем же name на новую строку.

Cookie также могут устанавливаться программами на языках типа JavaScript, встроенными в текст страниц, или аналогичными скриптами, работающими в браузере. В JavaScript для этого используется свойство cookie объекта document — document.cookie. Например, document.cookie="temperature=20" создаст cookie под именем «temperature» и значением 20^[22].

Cookie могут использоваться сервером для опознания ранее аутентифицированных пользователей. Это происходит следующим образом^[23]:

1. Пользователь вводит имя пользователя и пароль в текстовых полях страницы входа и отправляет их на сервер.
2. Сервер получает имя пользователя и пароль, проверяет их и, при их правильности, отправляет страницу успешного входа, прикрепив cookie с неким идентификатором сессии. Эта cookie может быть действительна не только для текущей сессии браузера, но может быть настроена и на длительное хранение.
3. Каждый раз, когда пользователь запрашивает страницу с сервера, браузер автоматически отправляет cookie с идентификатором сессии серверу. Сервер проверяет идентификатор по своей базе идентификаторов и, при наличии в базе такого идентификатора, «узнаёт» пользователя.

Этот метод широко используется на многих сайтах, например на Yahoo!, в Википедии и в Facebook'е.

Многие браузеры (в частности Opera, FireFox) путём редактирования свойств cookie могут управлять поведением веб-сайтов. Изменив срок истечения непостоянных (сессионных) cookie, можно, например, получить формально-неограниченную сессию после авторизации на каком-либо сайте. Возможность редактирования cookie стандартными средствами отсутствует в Internet Explorer’е. Но, воспользовавшись иными механизмами, например, JavaScript, пользователь может изменить cookie-файл. Более того, существует возможность заменить сессионные cookie постоянными (с указанием срока годности).

Однако серверное программное обеспечение может отслеживать такие попытки. Для этого сервер выдаёт cookie на определённый срок и записывает дату окончания cookie у себя или, в зашифрованном виде, в самих cookie, каждый раз, когда пользователь обращается к серверу. Если cookie, присланный браузером, имеет дату годности, отличную от той, что хранится на сервере или содержатся в cookie, значит, имеет место попытка подмены даты годности cookie. Сервер может отреагировать, например, запросив у пользователя повторную авторизацию.

Большинство современных браузеров поддерживает cookie,^[24] и, как правило, пользователь может выбрать, должны cookie использоваться или нет. Наиболее распространены следующие настройки браузеров^[25]:

1. Полное отключение cookie.
2. Удаление cookie при закрытии браузера.
3. Различение сторонних cookie с третьей стороны и соответствующее обращение с ними (например, ограничение или запрет для них).
4. Обработка cookie на основе «белого» и/или «чёрного» списков, обновляемых пользователем или изготовителем браузера. Cookie из «чёрного списка» блокируются.
5. Запрет cookie от определённых доменов (разновидность «чёрного списка»).
6. Установка разумных сроков истечения cookie.

Большинство браузеров, поддерживающих JavaScript, позволяет пользователю увидеть активные на данном сайте cookie, набрав javascript:alert(document.cookie) или javascript:prompt(document.cookie) в адресной строке браузера^[25]. Некоторые браузеры содержат менеджер cookie, позволяющий пользователю выборочно просмотреть и удалить cookie, хранящиеся в браузере.

Существует заблуждение, что cookie являются программами и могут самостоятельно отслеживать действия пользователей, хотя это только фрагменты данных, хранящиеся на компьютере браузером^[26]. Согласно опросу, проведённому американской компанией Insight Express в 2005 году, 25 % респондентов уверены в этом^[27].

Cookie значительным образом влияют на анонимность пользователей Интернета и конфиденциальность пользовательской информации. Хотя cookie отправляются только на серверы домена, для которого они предназначены, веб-страница может подгружать изображения или другие компоненты из других доменов. Куки, получаемые во время подгрузки этих компонентов из других доменов, называются «сторонними»^[28].

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

Создание профиля пользователей рассматривается как потенциальная угроза приватности даже при отслеживании в рамках одного домена, но особенно это актуально при отслеживании на нескольких доменах с использованием сторонних cookie. По этой причине в некоторых странах cookie регулируются законодательством.

Правительство Соединённых Штатов приняло строгие законы в отношении cookie в 2000 году, после того, как выяснилось, что Агентство по борьбе с наркотиками США использовало cookie для отслеживания пользователей, просмотревших их антинаркотическую рекламу в сети. В 2002 году Дэниел Брандт установил, что ЦРУ устанавливает на компьютеры постоянные cookie со сроком хранения до 2010 года. Когда ЦРУ было уведомлено о неправомерности подобного использования cookie, управление заявило, что это было непреднамеренно и прекратило их установку^[29]. 25 декабря 2005 года Брандт обнаружил, что Агентство национальной безопасности оставляло пару постоянных cookie после обновления программного обеспечения. После этого сообщения Агентство немедленно отключило cookie^[30].

Директива Европейского союза 2002/58/ЕС о конфиденциальности и электронных средствах связи^[31] содержит нормы, касающиеся использования cookie. В частности, статья 5(3) устанавливает, что хранение данных (в том числе cookie) может осуществляться лишь если:

• пользователю предоставляется информация о том, как эти данные используются;
• пользователь имеет возможность отказаться от этого.

В 2009 году Директива 2009/136/ЕС^[32] внесла изменения в Директиву 2002/58/ЕС, которые вступили в силу мае 2011 года. Изменения ужесточили требования к порядку сбора информации о посетителях сайтов. Согласно новым правилам владельцы сайтов должны получать предварительное согласие посетителей на сбор информации (в том числе cookie) и сообщать о действующих на сайте инструментах сбора информации^[33].

В мае 2018 года в Евросоюзе вступил в силу Общий регламент защиты персональных данных, заменивший действующую Директиву 2002/58/ЕС, относящийся ко всем сайтам, посещаемым из Евросоюза, и приравнивающий большую часть cookie к другим персональным данным. В изначальном проекте предполагалось, что настройки браузера могут признаваться достаточным выражением согласия пользователя на установку cookie^[34], а согласно окончательной версии, достаточно уведомления об установке cookie^[35].

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

Многие браузеры, включая Safari от Apple и Internet Explorer версий 6 и 7 от Microsoft, поддерживают спецификации P3P, которые позволяют определить, следует ли разрешать сторонние cookie. Браузер Opera позволяет пользователям отказаться от сторонних cookie и создать глобальные или выборочные профили безопасности для веб-доменов^[36]. Firefox 2 был лишён этой опции, но она была восстановлена в версии 3.

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

Если на компьютере используется более одного браузера, то, как правило, каждый имеет отдельное хранилище для cookie. Поэтому cookie идентифицируют не человека, а сочетание учётной записи, компьютера, и браузера. Таким образом, любой человек, который использует несколько учётных записей, компьютеров или браузеров, имеет несколько наборов cookie.

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

Cookie могут быть украдены с помощью анализа трафика — это называется взломом сессии. Сетевой трафик может быть перехвачен не только его отправителем и получателем (особенно в публичных сетях Wi-Fi). Этот трафик включает в себя и cookie, передаваемые через незашифрованные HTTP-сессии. Там, где сетевой трафик не шифруется, злоумышленники могут прочесть сообщения пользователей сети, в том числе их cookie, используя программы, называемые снифферами.

Шифрование сервером данных в cookie снимает вопрос о их безопасности, однако возможна подмена cookie злоумышленником. Для невозможности доступа даже к зашифрованным cookie может помочь установление между пользователем и сервером шифрованного соединения с использованием протокола HTTPS. Сервер также может использовать специальный флаг при установке cookie, после чего браузер будет передавать их только по надёжному каналу, например через SSL-соединение^[7].

Однако большое число веб-сайтов, даже использующих безопасные HTTPS-сессии для идентификации пользователя, затем отправляет cookie и другие данные более простым незашифрованным HTTP-соединением. Злоумышленники могут легко перехватить cookie других пользователей и использовать их на соответствующих веб-сайтах^[37].

Для того чтобы гарантировать передачу cookie только через HTTPS-сессию, cookie должны иметь атрибут Secure.

Другой способ кражи cookie — межсайтовый скриптинг и несанкционированная отправка cookie на серверы, которые не должны получать их. Современные браузеры могут исполнять фрагменты кода, полученные с сервера. Если cookie доступны во время этого исполнения, их содержимое может в той или иной форме оказаться на серверах, которые не должны получать к ним доступ. Шифрование cookie не поможет в этом случае^[38].

Следующий вид межсайтового скриптинга, как правило, используют на сайтах, где пользователям разрешено отправлять сообщения с HTML-содержимым. При вставке соответствующего PHP/Javascript-кода в сообщение атакующий может получить cookie других пользователей.

Эти атаки можно предотвратить установкой флага HttpOnly^[39], делающего cookie недоступными для скриптов со стороны клиента. Тем не менее, веб-разработчики должны предусматривать защиту от межсайтового скриптинга на стадии разработки веб-сайтов^[40].

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

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

Каждый сайт должен иметь свои собственные cookie, и сайт example1.com не должен изменять или устанавливать cookie другого сайта example2.org. Уязвимости веб-браузеров позволяют вредоносным сайтам нарушать это правило. Это похоже на подмену cookie, но здесь злоумышленник атакует пользователей с уязвимыми браузерами, а не сайт напрямую. Целью таких атак могут быть идентификаторы сессий.

Для защиты пользователям рекомендуется использовать последние версии браузеров, в которых эта проблема исправлена.

Cookie могут вызвать противоречия между клиентом и сервером. Если пользователь получает cookie, а затем нажимает кнопку «Назад» в браузере, то состояние браузера уже другое по сравнению с моментом получения cookie. Для примера возьмём электронный магазин с корзиной покупок, основанной на применении cookie: пользователь добавляет покупку в корзину, затем нажимает кнопку «Назад», но покупка остаётся в корзине, хотя пользователь, возможно, хотел отменить покупку. Это может привести к путанице и ошибкам. Веб-разработчики должны помнить об этом и принимать меры для решения таких ситуаций.

Постоянные cookie критикуются экспертами за свой долгий срок хранения, который позволяет веб-сайтам отслеживать пользователей и создавать их профиль с течением времени^[41]. Здесь затрагиваются и вопросы безопасности, поскольку украденные постоянные cookie могут использоваться на протяжении значительного периода времени.

Кроме того, правильно составленная вредоносная программа, которая может быть запущена после аутентификации пользователя, сможет перенести сессионные cookie на компьютер злоумышленника, что в первом приближении позволит посещать защищённый сайт без ввода имени пользователя и пароля сколь угодно долгое время.

Обычные cookie имеют хоть и очень большой, но ограниченный «срок жизни», после чего удаляются. Кроме того, любые cookie в браузере можно удалить с помощью специальной опции. В результате браузер перестаёт идентифицировать посетителя при повторном заходе на сайт. Польский специалист Сами Камкар решил систематизировать наиболее «живучие» cookie, в результате чего появилась JavaScript-библиотека под названием evercookie. Такие чудо-cookie теоретически позволяют идентифицировать любого посетителя сайта при его возвращении на страницу. Сайт, использующий библиотеки Everycookie, без труда обходит все меры по сохранению анонимности (хотя некоторые антивирусы могут определять такие сайты как опасные). Для защиты от Everycookie рекомендуется использование режима Private Browsing либо специальных программ, таких, как Mil Shield.

Файлы cookie были изначально представлены, чтобы предоставить пользователям возможность записывать товары, которые они хотят приобрести, когда они перемещаются по веб-сайту (виртуальная «корзина покупок» или «корзина покупок»)^[42][43]. Однако сегодня содержимое корзины покупок пользователя обычно хранится в базе данных на сервере, а не в файле cookie о клиенте. Чтобы отслеживать, какой пользователь относится к какой корзине покупок, сервер отправляет клиенту файл cookie, содержащий уникальный идентификатор сеанса (обычно длинную строку случайных букв и цифр). Поскольку файлы cookie отправляются на сервер при каждом запросе клиента, этот идентификатор сеанса будет отправляться обратно на сервер каждый раз, когда пользователь посещает новую страницу на веб-сайте, которая позволяет серверу узнать, какую корзину покупок отобразить пользователю.

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

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

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

Многие веб-сайты используют cookie для персонализации в соответствии с предпочтениями пользователя. Пользователи выбирают свои предпочтения, вводя их в веб-форму и отправляя форму на сервер. Сервер кодирует настройки в cookie и отправляет cookie обратно в браузер. Таким образом, каждый раз, когда пользователь получает доступ к странице на веб-сайте, сервер может персонализировать страницу в соответствии с предпочтениями пользователя. Например, поисковая система Google однажды использовала cookie, чтобы позволить пользователям (даже незарегистрированным) решать, сколько результатов поиска на странице они хотят видеть.

Файлы cookie используются для отслеживания привычек пользователей в Интернете. Это также можно сделать в некоторой степени, используя IP-адрес компьютера, запрашивающего страницу, или поле referer заголовка HTTP-запроса, но cookie-файлы позволяют повысить точность. Это можно продемонстрировать, если пользователь запрашивает страницу сайта, но запрос не содержит cookie, сервер предполагает, что это первая страница, которую посетил пользователь. Таким образом, сервер создаёт уникальный идентификатор (обычно последовательность случайных букв и цифр) и отправляет его в виде файла cookie в браузер вместе с запрашиваемой страницей.

С этого момента cookie будет автоматически отправляться браузером на сервер каждый раз, когда запрашивается новая страница с сайта. Сервер не только отправляет страницу как обычно, но также сохраняет URL запрошенной страницы, дату / время запроса и файл cookie в файле журнала.

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

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

Этот ненадёжный метод отслеживания пользователей основан на хранении IP-адресов компьютеров, просматривающих страницы. Данная техника доступна с самого появления World Wide Web, которая требует знания IP-адреса клиента для загрузки страницы. Эту информацию можно хранить на сервере вне зависимости от того, используются cookie или нет.

Тем не менее этот способ менее надёжен, чем cookie, поскольку компьютеры и прокси могут совместно использоваться несколькими пользователями, а один компьютер может использовать разные IP-адреса в разных сессиях (динамический IP-адрес).

Отслеживание по IP-адресу может оказаться невозможным и при использовании систем сохранения анонимности (например, Tor). В таких системах один браузер может иметь несколько IP-адресов, и несколько пользователей могут использовать один IP-адрес, в результате чего отслеживание IP-адреса не представляется возможным.

Более прогрессивная методика основана на встраивании данных в URL. Обычно для этого используется строка запроса, но так же могут задействоваться и другие части URL. Языки JavaScript и PHP активно используют эти механизмы при отключённых cookie.

Веб-сервер добавляет строку запроса к ссылке на веб-страницу при её отправке в браузере. Когда пользователь переходит по ссылке, браузер возвращает строку запроса серверу.

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

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

Другой недостаток строки запроса проявляется в вопросах безопасности: хранение идентификатора сессии в строке запроса упрощает проведение атаки. Передача идентификатора в cookie более безопасна.

Одним из способов отслеживания сессии с помощью выполняемой на стороне сервера программы является использование веб-форм со скрытыми полями. Этот метод очень похож на строку запроса URL и обладает почти теми же преимуществами и недостатками, а если параметры формы отправляются HTTP-методом GET, то поля фактически станут частью URL, который браузер отправит на сервер. Но большинство форм обрабатывается HTTP POST, при которой информация не является ни частью URL, ни cookie.

Этот подход даёт два преимущества в вопросе отслеживания: во-первых, вставка информации в HTML-код и в POST, а не в URL, означает, что средний пользователь её просто не заметит, во-вторых, информация сессии не копируется с копированием URL (например, когда пользователь отправляет ссылку по электронной почте). Недостаток метода состоит в том, что информация сессии содержится в HTML-коде, поэтому веб-страница должна генерироваться каждый раз, когда её запрашивают, что увеличивает нагрузку на веб-сервер.

Протокол HTTP включает в себя базовую аутентификацию и шифрование, которые разрешают доступ к странице, только когда пользователь введёт правильное имя пользователя и пароль. Если сервер запрашивает подобное, то браузер обращается к пользователю и, получив нужные данные, сохраняет и использует их для доступа к другим страницам, не требуя от пользователя вводить их заново. С точки зрения пользователя эффект тот же, что и при использовании cookie: имя пользователя и пароль требуются лишь однажды, и потом пользователь получает доступ к сайту. При базовой аутентификации сочетание имени пользователя и пароля отправляется на сервер при каждом запросе браузера в незашифрованном виде. Это означает, что если кто-то перехватывает трафик, он сможет получить эту информацию и впоследствии использовать. При шифрованной аутентификации имя пользователя и пароль шифруются со случайным ключом, созданным сервером.

Некоторые веб-браузеры позволяют странице сохранять информацию локально для последующего извлечения. Internet Explorer, например, поддерживает сохранение информации в истории, избранном, XML-хранилище, или позволяет провести прямое сохранение веб-страницы на диск^[44].

JSON Web Token (JWT) — это автономный пакет информации, который можно использовать для хранения информации о личности и подлинности пользователя. Это позволяет использовать их вместо файлов cookie сеанса. В отличие от файлов cookie, которые автоматически присоединяются к каждому HTTP-запросу браузером, JWT должны быть явно присоединены веб-приложением к каждому HTTP-запросу.

Все современные веб-браузеры могут хранить довольно большой объём данных (2-32 МБ) через JavaScript, используя свойство DOM window.name. Эти данные могут использоваться вместо файлов cookie сеанса и также являются междоменными. Техника может быть объединена с объектами JSON / JavaScript для хранения сложных наборов переменных сеанса^[45] на стороне клиента.

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

Например, страница может содержать ссылку <script type="text/javascript" src="example.js">. Скрипт устанавливает уникальный идентификатор для пользователя (например, var userId = 3243242;). После первоначального посещения каждый раз, когда пользователь заходит на страницу, этот файл будет загружаться из кэша, а не загружаться с сервера. Таким образом, его содержание никогда не изменится.

Единственное преимущество этого способа — межсайтовая работа, что позволяет несанкционированно следить за пользователем. Недостатки — нетривиальная передача этой информации на сервер и крайняя неуправляемость: браузер может потерять закэшированные данные когда угодно в зависимости от настроек, объёма памяти и дискового места. Mozilla Firefox 85+ не допускает межсайтового слежения через кэш^[46].

Большинство современных браузеров поддерживают cookie и позволяют пользователю отключать их. Ниже приведены общие варианты^[47]:

• Полностью включить или отключить cookie, чтобы они всегда были приняты или всегда блокировались.
• Для просмотра и выборочного удаления файлов cookie используется менеджер файлов cookie.
• Чтобы полностью стереть все личные данные, в том числе cookie.
• По умолчанию Internet Explorer разрешает сторонние cookie только в том случае, если они сопровождаются P3P-полем «CP» (компактная политика)^[48].

• Magic cookie
• Web Storage
• Локальные общие объекты
• Браузер
• JSON Web Token
• FLoC (Federated Learning of Cohorts) — перспективная замена куки^[49]

• RFC 6265 (англ.) — текущая официальная спецификация для cookie
• RFC 2964 (англ.) — «Использование механизмов управления состоянием HTTP-сессии»
• RFC 2965 (англ.) — «Механизмы контроля состояния HTTP-сессии. Новая ревизия. HTTP-Cookies 2»
• Что такое cookies и как с ними работать