Войти
HTTP cookie (называется также веб-файл cookie, Интернет-файл cookie, файл cookie или просто файл cookie ) представляет собой небольшой фрагмент данных хранятся на компьютере пользователя с помощью веб-, пока просматривает веб-сайт . Файлы cookie были разработаны как надежный механизм, позволяющий записывать действия пользователя в Интернете информацию с отслеживанием состояний (например, товары, добавленные в корзину интернет-магазин ) или записывать действия пользователя в Интернете (включая щелчки край кнопки, вход в или запись страниц, которые были посещены в ). Их также можно использовать для запоминания фрагментов информации, которые пользователь ранее вводил в поля формы, такие как имена, адреса, пароли и номера платежных карт.
Cookies. выполнять функции важные в современном веб. Возможно, наиболее важно, что файлы cookie аутентификации являются наиболее распространенным методом, используемым веб-серверами, чтобы узнать, вошел ли пользователь в систему или нет, и в какой аккаунт записи они зарегистрированы. в с. Без механизма сайта не знал бы, отправить ли страницу, ввести конфиденциальную информацию, или потребовать от пользователя аутентификации себя, войти в систему. Безопасность файла cookie аутентификации обычно зависит от выдачи веб-сайта и веб-браузер пользователя, а также от того, зашифрованы данные cookie. Уязвимости системы безопасности могут хакеру прочитать данные cookie, использовать их для получения доступа к данным пользователя или использовать для получения доступа (с учетными данными пользователя) на веб- сайт, которому принадлежит файл cookie (примеры см. в разделе межсайтовый скриптинг и подделка межсайтовых запросов ).
отслеживающие файлы cookie, и особенно сторонние файлы cookie для использования, обычно используются в качестве способов сбора долгосрочных записей исторических просмотров отдельных пользователей - потенциальная проблема конфиденциальности, которая побудила Американского американского законодателя в 2011 году. Закон требует, чтобы все веб-сайты, ориентированные на государства-члены Европейского Союза, имели «предоставленное » от пользователей перед сохранением второстепенных файлов cookie на своих устройствах.
Google Project Zero, исследователь Янн Хорн сообщил, как файлы cookie могут быть прочитаны посредниками, такими как провайдеры доступа Wi-Fi. В таких случаях он рекомендует использовать браузер в режиме инкогнито.
HTTP-файлы cookie используют свое имя с популярной выпечкой. Термин «cookie» был придуман программистом веб-Лу Монтулли. Он былан от термина «magic cookie », который представляет собой пакет данных, который программа получает и отправляет обратно без изменений, и используется программистами Unix.
Волшебные файлы cookie уже использовались в вычислениях, когда компьютерный программист Лу Монтулли в июне 1994 г. придумал использовать их в веб-коммуникациях. В то время он был сотрудником Netscape Communications, которая разрабатывала приложение электронной коммерции для MCI. Винт Серф и Джон Кленсин представляли MCI в технических обсуждениях с Netscape Communications. MCI не хотела, чтобы ее серверы сохраняли частичные состояния транзакций, поэтому они попросили Netscape, чтобы сохранить это состояние на компьютере каждого пользователя. Файлы cookie позволили решить проблему надежной реализации проблему корзины для покупок.
. Вместе с Джоном Джаннандреа Монтулли в том же году оригинальную спецификацию файлов cookie Netscape. Версия 0.9beta Mosaic Netscape, выпущенная 13 октября 1994 г., поддерживала файлы cookie. Первое использование файлов cookie (вне лабораторий) было проверкой посещений посетителей веб-сайта Netscape уже этот сайт. Montulli подал заявку на патент на технологию cookie в 1995 году, и US 5774670 был предоставлен в 1998 году. Поддержка cookie была интегрирована в Internet Explorer в версии 2, выпущенной в октябре 1995 года.
В то время о внедрении файлов cookie не было широко известно широкой публике. В частности, по умолчанию принимались файлы cookie, и пользователи не уведомлялись об их настройках. Широкая общественность узнала о файле cookie после того, как Financial Times опубликовала о них статью 12 февраля 1996 года. В том же году файлы cookie привлекли большое внимание средств массовой информации, особенно из-за использования угроз для конфиденциальности. Файлы cookie обсуждались на двух слушаниях Федеральной торговой комиссии США в 1996 и 1997 годах.
Разработка официальных спецификаций файлов cookie уже продолжалась. В частности, первые обсуждения формальной спецификации начались в апреле 1995 года в списке рассылки www-talk . Была сформирована специальная рабочая группа в рамках Инженерной группы Интернета (IETF). Два альтернативных предложения по введению состояния транзакции HTTP были предложены Брайаном Белендорфом и Дэвидом Кристолом соответственно. Но группа, управляемая самим Кристолом и Лу Монтулли, вскоре решила использовать спецификацию Netscape в качестве отправной точки. В феврале 1996 года рабочая группа определила сторонние файлы cookie как серьезную конфиденциальность. Спецификация, разработанная группа, в итоге опубликована как RFC 2109 в феврале 1997 года. В ней указывается, что сторонние файлы cookie либо вообще не разрешены, либо по крайней мере, не включены по умолчанию.
В то время рекламные компании уже использовали сторонние файлы cookie. Рекомендации относительно сторонних файлов cookie в RFC 2109 не выполнялись Netscape и Internet Explorer. RFC 2109 был заменен RFC 2965 в октябре 2000 года.
RFC 2965 добавил заголовок Set-Cookie2, который неофициально стал называться «RFC 2965 -style cookies» в отличие от исходного заголовка Set-Cookie, который назывался «печенье в стиле Netscape». Set-Cookie2использовался редко, однако он был объявлен устаревшим в RFC 6265 в апреле 2011 года, который был написан как окончательная спецификация для файлов cookie, используемых в реальном мире.
Сеансовые куки, также известные как куки в памяти, временные куки или непостоянные куки, существуют только во временной, пока пользователь перемещается по сайту. Веб-браузеры обычно удаляют файлы cookie сеанса, когда пользователь закрывает браузер. В отличие от других файлов cookie, сеансовые файлы cookie не имеют назначенной даты истечения срока действия, поэтому браузер распознает их как файлы cookie сеанса.
Вместо того, чтобы истекать при закрытии веб-сайтов, как это делают файлы cookie сеанса, постоянный файл cookie истекает в определенную дату или через некоторое время. Это означает, что в течение всего срока службы файла cookie (может быть настолько длинным или коротким, насколько ему нужны его создатели), информация будет передаваться на сервер каждый раз, когда пользователь использует веб-сайт, которому он принадлежит, или каждый раз, когда пользователь просматривает ресурс, принадлежащий этому сайту, с другого сайта (например, реклама).
По этой причине постоянные файлы cookie иногда называют отслеживающими cookie-файлами, поскольку они привычными сообщениями о привычках пользователя к просмотру веб-страниц в течение длительного периода времени. Однако они также используются по «законным» причинам (например, для того, чтобы пользователи оставались в своих учетных данных на веб-сайтах, чтобы избежать повторного ввода учетных данных для входа при каждом посещении).
Защищенный файл cookie может передаваться только через зашифрованное соединение (например, HTTPS ). Они не могут быть переданы через незашифрованные соединения (например, HTTP ). Это снижает вероятность того, что файл cookie будет подвергнут краже через перехват. Файл cookie становится безопасным путем добавления к нему флага Secure.
HTTP-файл cookie не может быть доступен клиентским API, таким как JavaScript. Это ограничение устраняет угрозу кражи файлов cookie с помощью межсайтовых сценариев (XSS). Однако файл cookie остается уязвимым для атак межсайтовой трассировки (XST) и подделки межсайтовых запросов (XSRF). Эта характеристика присваивается файлу cookie путем добавления к нему флага HttpOnly.
В 2016 году Google Chrome версии 51 представил новый вид cookie с атрибутом SameSite. Атрибут SameSiteможет иметь значение Strict, Laxили None. С атрибутом SameSite = Strictбраузеры должны отправлять эти файлы cookie только с запросами, исходящими из того же домена / сайта, что и домен домена. Это эффективно атакчит атаки подделки межсайтовых запросов (XSRF). SameSite = Laxне ограничит исходный сайт, но заставит домен быть таким же, как домен cookie, эффективно блокируя третий -стартийные (межсайтовые) файлы cookie. Атрибут SameSite = Noneразрешает сторонние (межсайтовые) файлы cookie. Файл cookie того же сайта включен в новый проект RFC для «Cookie-файлов: механизм управления состоянием HTTP» для обновлений RFC6265 (если он утвержден).
Chrome, Firefox, Microsoft Edge - все начали поддерживать файлы cookie одного сайта. Ключом к развертыванию является обработка файлов cookie без определенного атрибута SameSite. Chrome обрабатывает эти файлы cookie, как раньше SameSite = None, при этом все веб-сайты / приложения будут работать как раньше. Google намеревался изменить это значение по умолчанию на SameSite = Lax в феврале 2020 года, это изменение нарушит работу этих приложений / веб-сайтов, если они будут отвечать на сторонние / межсайтовые файлы cookie, но без определенного атрибута SameSite. Учитывая обширные изменения для веб-разработчиков и обстоятельств COVID-19, Google временно отменил изменение файла cookie SameSite.
Обычно атрибут файла cookie соответствует домену, который отображается в адресной строке веб-сайта. Это называется файлом cookie. Однако сторонний файл cookie принадлежит к домену, отличному от того, который указан в адресной строке. Этот тип файлов cookie обычно появляется, когда веб-страницы содержат контент с внешних веб-сайтов, например баннерную рекламу. Это открывает возможности для использования истории пользователя часто используется рекламодателями в попытке показывать релевантную рекламу каждому пользователю.
В качестве примера предположим, что пользователь посещает www.example.org. Этот веб-сайт содержит рекламу с сайта ad.foxytracking.com, которая при загрузке устанавливает файл cookie, принадлежащий домену объявления (ad.foxytracking.com). Затем пользователь посещает другой веб-сайт, www.foo.com, который также содержит файл cookie от ad.foxytracking.comи устанавливает файл cookie, принадлежащий этому домену (ad. foxytracking.com). В конце концов, оба файла cookie будут отправлены рекламодателю при загрузке его рекламы или посещении его веб-сайта. Затем рекламодатель может использовать эти файлы cookie для создания истории просмотров пользователя на всех веб-сайтах, с помощью поля заголовка HTTP referer.
По состоянию на 2014 год некоторые веб-сайты устанавливают файлы cookie для чтения более чем для 100 сторонних доменов. В среднем на одном веб-сайте установлено 10 файлов cookie, при этом максимальном количестве файлов cookie (собственных и собственных) больше 800.
Большинство современных веб-браузеров содержат настройки, которые заблокировать сторонние файлы cookie. Google Chrome представил новые функции для блокировки сторонних файлов cookie. Отныне они теперь по умолчанию заблокированы в режиме инкогнито, в то время как пользователь может также заблокировать их в обычном режиме просмотра. В обновлении также добавлена возможность блокировать собственные файлы cookie.
Некоторые браузеры блокируют сторонние файлы cookie. С июля 2020 года Apple Safari, Firefox и Brave по умолчанию блокируют все сторонние файлы cookie. Safari позволяет встроенным сайтам использовать API доступа к хранилищу для запроса разрешения на установку основных файлов cookie. Chrome начать блокировать сторонние файлы cookie к 2022 году.
Супер-cookie - это файл cookie, являющийся доменом верхнего уровня (например, .com) или общедоступный суффикс (например, .co.uk). Обычные файлы cookie, напротив, имеют происхождение от определенного доменного имени, например, example.com.
Супер-файлы cookie могут потенциальную угрозу безопасности и поэтому часто блокируются веб-браузерами. В случае разблокировки браузером злоумышленник, контролирующий вредоносный веб-сайт, может установить супер-файл cookie и нарушить или выдать себя за законные запросы пользователей к другому веб-сайту, который имеет тот же домен верхнего уровня или общедоступный суффикс, что и отрицательный веб- сайт. Например, супер-файл cookie с помощью .comможет злонамеренно повлиять на запрос, сделанный к example.com, даже если файл cookie не исходит от example.com. Это может быть использовано для подделки логинов или изменений информации пользователя.
Список общедоступных суффиксов помогает снизить риск, связанный с использованием супер-файлов cookie. Список общедоступных суффиксов - это межпроизводственная инициатива, цель которой - предоставить точный и актуальный список суффиксов доменных имен. В старых версиях браузеров может не быть актуального списка, и поэтому они уязвимы для супер-файлов cookie из определенных доменов.
Термин «супер-cookie» иногда используется для технологий, которые не используются на файлы cookie HTTP. В августе 2011 года на веб-сайте Microsoft были обнаружены два таких механизма «супер-файлов cookie»: синхронизация файлов cookie, которые воспроизводит файлы cookie MUID (уникальный идентификатор компьютера), и файлы cookie ETag. Из-за средств массовой информации информации Microsoft позже отключила этот код.
Зомби-cookie - это файл cookie, который автоматически воссоздается после удаления. Это достигается путем хранения файлов cookie в нескольких местах, таких как Локальный общий объект Flash, Веб-хранилище HTML5 и в других местах на стороне клиента и даже на стороне сервера. При обнаружении отсутствия файла cookie файл cookie создается заново с использованием данных, хранящихся в этих местах.
Файл cookie состоит из следующих компонентов:
Secureи HttpOnly).Файлы cookie были изначально предоставлены пользователям возможность записывать товары, которые они хотят приобрести, во время навигации по веб-сайту (виртуальная «корзина для покупок» или «корзина для покупок»). Однако сегодня корзина покупок пользователя обычно хранится в базе данных на сервере., а не в файле cookie на клиенте. Чтобы указать, какой пользователь назначен какой корзине покупок, сервер отправляет клиентский файл cookie, который содержит уникальный идентификатор сеанса (обычно длинная строка букв и цифр). на сервер с каждым запросом, который делает клиент, этот идентификатор сеанса будет отправляться обратно на сервер каждый раз, когда пользователь посещает новую страницу на веб-сайте, что позволяет серверу знать какую корзину отображать пользова телю.
Еще одно популярное использование co okies предназначен для входа на веб-сайты. Когда пользователь посещает страницу входа на веб-сайт, веб-сервер обычно отправляет клиенту файл cookie, содержащий уникальный идентификатор сеанса. Когда пользователь успешно входит в систему, сервер запоминает, что этот конкретный идентификатор сеанса был аутентифицирован, и предоставляет пользователю доступ к своим службам.
Поскольку файлы cookie сеанса содержат только уникальный идентификатор сеанса, это делает количество личной информации, которую веб-сайт может сохранить о каждом пользователе, практически безграничным - веб-сайт не ограничивается ограничениями, касающимися размера файла cookie. Сеансовые файлы cookie также помогают сократить время загрузки страницы, поскольку объем информации в файле cookie сеанса невелик и требует небольшой полосы пропускания.
Файлы cookie могут использоваться для запоминания информации о пользователе, чтобы с течением времени показывать ему соответствующий контент. Например, веб-сервер может отправить файл cookie, содержащий имя пользователя, которое в последний раз использовалось для входа на веб-сайт, чтобы его можно было заполнить автоматически при следующем входе пользователя в систему.
Многие веб-сайты используют файлы cookie для персонализация на основе предпочтений пользователя. Пользователи выбирают свои предпочтения, вводя их в веб-форму и отправляя форму на сервер. Сервер кодирует настройки в файле cookie и отправляет файл cookie обратно в браузер. Таким образом, каждый раз, когда пользователь обращается к странице на веб-сайте, сервер может персонализировать страницу в соответствии с предпочтениями пользователя. Например, поисковая система Google когда-то использовала файлы cookie, чтобы позволить пользователям (даже незарегистрированным) решать, сколько результатов поиска на странице они хотят видеть. Кроме того, DuckDuckGo использует файлы cookie, чтобы позволить пользователям устанавливать предпочтения просмотра, такие как цвета веб-страницы.
Файлы cookie для отслеживания используются для отслеживания привычек пользователей при просмотре веб-страниц. В некоторой степени это также можно сделать, используя IP-адрес компьютера, запрашивающего страницу, или поле referer заголовка запроса HTTP, но файлы cookie позволяют для большей точности. Это можно продемонстрировать следующим образом:
Анализируя этот файл журнала, затем можно найти узнать, какие страницы посетил пользователь, в какой последовательности и как долго.
Корпорации используют веб-привычки пользователей, отслеживая файлы cookie для сбора информации о покупательских привычках. Wall Street Journal обнаружил, что на пятидесяти ведущих веб-сайтах Америки на компьютерах установлено в среднем шестьдесят четыре устройства отслеживания, в результате чего было получено 3180 файлов отслеживания. Затем данные могут быть собраны и проданы участвующим в торгах корпорациям.
Возможное взаимодействие между веб-браузером и веб-сервером, содержащим веб-страницу, при котором сервер отправляет файл cookie в браузер, а браузер отправляет его обратно при запросе другой страницы. Файлы cookie представляют собой произвольные фрагменты данных, обычно выбираемые и сначала отправляемые веб-сервером и сохраняемые на клиентском компьютере веб-браузером. Затем браузер отправляет их обратно на сервер с каждым запросом, вводя состояния (память предыдущих событий) в транзакции HTTP без сохранения состояния. Без файлов cookie каждый запрос веб-страницы или компонента веб-страницы был бы изолированным событием, в значительной степени не связанным со всеми другими просмотрами страниц, сделанными пользователем на веб-сайте. Хотя файлы cookie обычно устанавливаются веб-сервером, они также могут быть установлены клиентом с помощью языка сценариев, например JavaScript (если не установлен флаг HttpOnlyфайла cookie, и в этом случае файл cookie не может быть изменен языками сценариев).
Спецификации файлов cookie требуют, чтобы браузеры соответствовали следующим требованиям для поддержки файлов cookie:
Файлы cookie устанавливаются с помощью Set-CookieHTTP-заголовок, отправленный в HTTP-ответе с веб-сервера. Этот заголовок предписывает веб-браузеру сохранить файл cookie и отправить его в будущих запросах на сервер (браузер проигнорирует этот заголовок, если он не поддерживает файлы cookie или отключил файлы cookie).
Например, браузер отправляет свой первый запрос на главную страницу веб-сайта 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 = среда, 9 июня 2021 г., 10:18:14 GMT...
HTTP-ответ сервера содержит содержимое домашней страницы веб-сайта. Но он также указывает браузеру установить два файла cookie. Первый, «тема», считается файлом cookie сеанса, поскольку он не имеет атрибута Expiresили Max-Age. Сессионные куки-файлы предназначены для удаления браузером при закрытии браузера. Второй, «sessionToken», считается постоянным файлом cookie, поскольку он содержит атрибут Expires, который указывает браузеру удалить файл cookie в определенную дату и время.
Затем браузер отправляет еще один запрос на посещение страницы spec.htmlна веб-сайте. Этот запрос содержит HTTP-заголовок Cookie, который содержит два файла cookie, которые сервер дал браузеру указание установить:
GET /spec.html HTTP / 1.1 Host: www.example.org Cookie: theme = легкий; sessionToken = abc123…
Таким образом, сервер знает, что этот запрос связан с предыдущим. Сервер ответит, отправив запрошенную страницу, возможно, включая дополнительные заголовки Set-Cookieв ответ, чтобы добавить новые файлы cookie, изменить существующие файлы cookie или удалить файлы cookie.
Значение cookie может быть изменено сервером путем включения заголовка Set-Cookieв ответ на запрос страницы. Затем браузер заменяет старое значение новым значением.
Значение cookie может состоять из любого печатаемого символа ASCII (от !до ~, Unicode \ u0021до \ u007E) за исключением ,и ;и пробельные символы. Имя файла cookie исключает те же символы, а также =, поскольку это разделитель между именем и значением. Стандарт файлов cookie RFC 2965 является более строгим, но не реализуется браузерами.
Термин «крошка cookie» иногда используется для обозначения пары имя-значение cookie.
Файлы cookie также могут быть установлены с помощью языков сценариев, таких как JavaScript, которые работают в браузере. В JavaScript для этой цели используется объект document.cookie. Например, инструкция document.cookie = "temperature = 20"создает файл cookie с именем «temperature» и значением «20».
Дополнительно к имени и значению файлы cookie также могут иметь один или несколько атрибутов. Браузеры не включают атрибуты cookie в запросы к серверу - они отправляют только имя и значение cookie. Атрибуты файлов cookie используются браузерами, чтобы определить, когда удалить файл cookie, заблокировать файл cookie или отправить файл cookie на сервер.
Атрибуты Домени Путьопределяют область действия файла cookie. По сути, они сообщают браузеру, какому веб-сайту принадлежит файл cookie. По очевидным причинам безопасности файлы cookie могут быть установлены только для верхнего домена текущего ресурса и его поддоменов, но не для другого домена и его поддоменов. Например, веб-сайт example.orgне может установить файл cookie с доменом foo.com, потому что это позволит веб-сайту example.orgуправлять файлы cookie foo.com.
Если атрибуты файла cookie Домени Путьне указаны сервером, они по умолчанию соответствуют домену и пути запрошенного ресурса. Однако в большинстве браузеров есть разница между файлом 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 установлен с доменом или без него.
Ниже приведен пример некоторых заголовков HTTP-ответа Set-Cookie, которые отправляются с веб-сайта после входа пользователя в систему. HTTP-запрос был отправлен на веб-страницу в документах.foo.comсубдомен:
HTTP / 1.0 200 OK Set-Cookie: LSID = DQAAAK… Eaem_vYg; Путь = / accounts; Срок действия истекает = среда, 13 января 2021 г., 22:23:01 GMT; Безопасный; HttpOnly Set-Cookie: HSID = AYQEVn… DKrdst; Домен =.foo.com; Путь = /; Срок действия истекает = среда, 13 января 2021 г., 22:23:01 GMT; HttpOnly Set-Cookie: SSID = Ap4P… GTEq; Домен = foo.com; Путь = /; Срок действия истекает = среда, 13 января 2021 г., 22:23:01 GMT; Безопасный; HttpOnly…
Первый файл cookie, LSID, не имеет атрибута Домени имеет атрибут Путь, равный / accounts. Это указывает браузеру использовать cookie только при запросе страниц, содержащихся в docs.foo.com/accounts(домен является производным от домена запроса). Два других файла cookie, 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для значений. of YY, где YY больше или равно 0 и меньше или равно 69.
В качестве альтернативы можно использовать атрибут Max-Age, чтобы установить срок действия cookie как интервал секунды в будущем относительно времени, когда браузер получил cookie. Ниже приведен пример трех заголовков Set-Cookie, которые были получены с веб-сайта после входа пользователя в систему:
HTTP / 1.0 200 OK Set-Cookie: lu = Rg3vHJZnehYLjVg7qi3bZjzg; Срок действия истекает = Вт, 15 января 2013 г., 21:47:38 GMT; Путь = /; Домен =.example.com; HttpOnly Set-Cookie: made_write_conn = 1295214458; Путь = /; Домен =.example.com Set-Cookie: reg_fb_gate = удалено; Срок действия истекает = Thu, 01 Jan 1970 00:00:01 GMT; Путь = /; Домен =.example.com; HttpOnly
Срок действия первого файла cookie, lu, истекает 15 января 2013 года. До этого времени он будет использоваться клиентским браузером. Второй файл cookie, made_write_conn, не имеет срока годности, что делает его файлом cookie сеанса. Он будет удален после того, как пользователь закроет свой браузер. Значение третьего файла cookie, reg_fb_gate, изменено на «удалено», и срок его действия истекает в прошлом. Браузер немедленно удалит этот файл cookie, потому что срок его действия уже прошел. Обратите внимание, что файл cookie будет удален только в том случае, если атрибуты домена и пути в поле Set-Cookieсовпадают со значениями, используемыми при создании файла cookie.
По состоянию на 2016 год Internet Explorer не поддерживал Max-Age.
Атрибуты Secureи HttpOnlyподдерживают не имеют связанных значений. Скорее, наличие только их имен атрибутов указывает на то, что их поведение должно быть включено.
Атрибут Secureпредназначен для ограничения обмена файлами cookie зашифрованной передачей, предписывая браузерам использовать файлы cookie только через безопасные / зашифрованные соединения. Однако, если веб-сервер устанавливает cookie с атрибутом безопасности из незащищенного соединения, cookie все равно может быть перехвачен, когда он отправляется пользователю с помощью атак типа «человек посередине». Поэтому для максимальной безопасности файлы cookie с атрибутом Secure следует устанавливать только через безопасное соединение.
Атрибут HttpOnlyпредписывает браузерам не предоставлять файлы cookie по каналам, отличным от запросов HTTP (и HTTPS). Это означает, что к файлу cookie нельзя получить доступ через языки сценариев на стороне клиента (в частности, JavaScript ), и поэтому его нельзя легко украсть с помощью межсайтового скриптинга (широко распространенная методика атаки).
Большинство современных браузеров поддерживают файлы cookie и позволяют пользователю отключать их. Ниже приведены общие варианты:
По умолчанию Internet Explorer разрешает использование сторонних файлов cookie, только если они сопровождаются полем P3P «CP» (компактная политика).
Также существуют дополнительные инструменты для управления разрешениями на использование файлов cookie.
Файлы cookie имеют важные последствия для конфиденциальности и анонимности веб-пользователей. Хотя файлы cookie отправляются только на сервер, устанавливающий их, или на сервер в том же домене Интернета, веб-страница может содержать изображения или другие компоненты, хранящиеся на серверах в других доменах. Cookies that are set during retrieval of these components are called third-party cookies. The older standards for cookies, RFC 2109 and RFC 2965, specify that browsers should protect user privacy and not allow sharing of cookies between servers by default. However, the newer standard, RFC 6265, explicitly allows user agents to implement whichever third-party cookie policy they wish. Most browsers, such as Mozilla Firefox, Internet Explorer, Opera, and Google Chrome, do allow third-party cookies by default, as long as the third-party website has Compact Privacy Policy published. Newer versions of Safari block third-party cookies, and this is planned for Mozilla Firefox as well (initially planned for version 22 but postponed indefinitely).
In this fictional example, an advert Компания ising разместила баннеры на двух сайтах. Размещая изображения баннеров на своих серверах и используя сторонние файлы cookie, рекламная компания может отслеживать просмотр пользователей на этих двух сайтах. Рекламные компании используют сторонние файлы cookie для отслеживания пользователя на нескольких сайтах. В частности, рекламная компания может отслеживать пользователя на всех страницах, на которых размещены рекламные изображения или веб-ошибки. Знание страниц, которые посещает пользователь, позволяет рекламной компании настраивать таргетинг рекламных объявлений на предполагаемые предпочтения пользователя.
Операторы веб-сайтов, которые не раскрывают потребителям использование сторонних файлов cookie, рискуют подорвать доверие потребителей в случае обнаружения использования файлов cookie. Четкое раскрытие информации (например, в политике конфиденциальности ), как правило, устраняет любые негативные последствия такого обнаружения файлов cookie.
Возможность создания профиля пользователя представляет собой угрозу конфиденциальности, особенно при отслеживании выполняется в нескольких доменах с использованием сторонних файлов cookie. По этой причине в некоторых странах есть законы о файлах cookie.
Правительство Соединенных Штатов установило строгие правила по установке файлов cookie в 2000 году после того, как стало известно, что Белый дом Управление наркополитики использовало файлы cookie для отслеживания пользователей компьютеров, просматривающих его антинаркотическая реклама в Интернете. В 2002 году активист по защите конфиденциальности Дэниел Брандт обнаружил, что ЦРУ оставляло постоянные файлы cookie на компьютерах, которые посещали его веб-сайт. Получив уведомление о нарушении политики, ЦРУ заявило, что эти файлы cookie не были установлены намеренно, и прекратило их установку. 25 декабря 2005 г. Брандт обнаружил, что Агентство национальной безопасности (АНБ) оставляло два постоянных файла cookie на компьютерах посетителей из-за обновления программного обеспечения. После получения уведомления АНБ немедленно отключило файлы cookie.
В 2002 году Европейский Союз выпустил Директиву о конфиденциальности и электронных коммуникациях, которая требует согласие конечных пользователей на размещение файлов cookie и аналогичных технологий для хранения и доступа к информации на оборудовании пользователей. В частности, пункт 3 статьи 5 предписывает, что хранение данных на компьютере пользователя может осуществляться только в том случае, если пользователю предоставлена информация о том, как эти данные используются, и пользователю предоставляется возможность запретить эту операцию сохранения.
Директива 95/46 / EC определяет «согласие субъекта данных» как «любое свободно данное конкретное и осознанное указание его пожеланий, с помощью которого субъект данных выражает свое согласие с личными данными, относящимися к его обработке». Согласие должно включать в себя некоторую форму общения, при которой отдельные лица сознательно заявляют о своем согласии.
В 2009 году в политику были внесены поправки Директивой 2009/136 / ЕС, которая включала изменение в статью 5, параграф 3. Вместо того, чтобы иметь возможность для пользователей отказаться от хранения файлов cookie, пересмотренная Директива требует получения согласия на хранение файлов cookie.
В июне 2012 года европейские органы защиты данных приняли заключение, в котором разъясняется, что некоторые файлы cookie пользователи могут быть освобождены от требования получения согласия:
Ответ отрасли был в основном отрицательным. Роберт Бонд из юридической фирмы Speechly Bircham имеет последствия как «далеко идущие и невероятно обременительные» для «всех британских компаний». Саймон Дэвис из Privacy International утверждает, что надлежащее исполнение «уничтожит всю отрасль».
Спецификация P3P предлагает серверу возможность заявить политику конфиденциальности, используя HTTP-заголовок , который указывает какую он собирает и для какой цели. Эти политики включают (но не ограничиваются) использование информации, собранной с помощью файлов cookie. Согласно спецификации P3P, браузер может принимать или отклонять файлы cookie, сравнивая политику конфиденциальности с сохраненными пользовательскими настройками или спрашивая пользователя, представляя ему политику конфиденциальности, объявленную сервером. Однако спецификация P3P подверглась критике со стороны веб-разработчиков за ее сложность. На некоторых веб-сайтах это неправильно реализовано. Например, Facebook в шутку использовал «HONK» в заголовке P3P в течение некоторого периода. Только Internet Explorer обеспечивает адекватную поддержку спецификации.
конфиденциальные файлы cookie могут быть заблокированы большинством браузеров, конфиденциальность конфиденциального сообщения со стороны рекламных и отслеживающих компаний, не оказывающих отрицательного воздействия на работу пользователя в Интернете. Многие рекламные операторы имеют возможность настройки от поведенческой рекламы, при этом файле cookie в браузере останавливает поведенческую рекламу.
Большинство веб-сайтов используют файлы cookie в качестве единственных ресурсов для пользовательских сессий, потому что другие методы идентификации веб-пользователей имеют ограничения уязвимости. Если веб-сайт использует файлы cookie в качестве приложений сеанса, злоумышленники могут имитировать запросы пользователей, украв полный набор файлов cookie жертв. С точки зрения веб-сервера, запрос злоумышленника ту же аутентификацию, что и запросы жертвы; таким образом, запрос выполняется от имени сеансавы.
Здесь используются различные сценарии кражи файлов cookie и перехвата пользовательских сеансов (даже без кражи пользовательских файлов cookie), которые работают с веб-сайтами, используя только файлы cookie HTTP для идентификации пользователя.
Cookie может быть украден другим компьютерам, которому разрешено чтение из сети Трафик в сети может быть перехвачен и прочитан компьютерами в сети, кроме отправителя и получателя (особенно через незашифрованный открытый Wi-Fi ). Этот трафик включает файлы cookie, отправленные в обычные незашифрованные сеансах HTTP. Если сетевой трафик не зашифрован, злоумышленники могут читать сообщения других пользователей в сети, включая файлы cookie HTTP, а также все содержимое разговоров с целью атаки типа «человек посередине».
Злоумышленник может использовать перехваченные файлы cookie, чтобы выдать себя за пользователя и выполнить неудачную задачу, как перевод денег с банковского счета.
Эту проблему можно решить, обеспечивая безопасность связи между компьютером пользователя и сервером, используя Transport Layer Security (протокол HTTPS ) для шифрования соединения. Сервер может указать флаг Безопасныйпри установке cookie, что заставит браузер отправлять cookie только по зашифрованному каналу, например по TLS-соединению.
Если злоумышленник может заставить 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, браузеры жертв будут отправлять все файлы cookie, связанные с example.comна сервер злоумышленника.
Если злоумышленник может это сделать, как правило, это вина провайдеров интернет-услуг в том, что они неправильно защищают свои DNS-серверы. Однако серьезность этой атаки может быть уменьшена, если веб-сайт использует безопасные файлы cookie. В этом случае злоумышленник столкнется с проблемой получения сертификата TLS целевого веб-сайта от центра , поскольку безопасные файлы могут передаваться только через зашифрованное соединение. Без соответствующего сертификата TLS браузеры будут отображать предупреждающее сообщение о недействительном сертификате злоумышленника, что удержать пользователей от посещения мошеннического веб-сайта злоумышленника и отправки злоумышленнику своих файлов cookie.
Куки также могут быть украдены с помощью метода, называемого межсайтовым скриптингом. Это происходит, когда злоумышленник использует веб-сайт, который позволяет своим пользователям публиковать нефильтрованный контент HTML и JavaScript. Размещая вредоносный код HTML и JavaScript, злоумышленник может заставить веб-браузер отправить файлы cookie на веб-сайт, управляемый злоумышленником.
Например, злоумышленник может опубликовать сообщение на www.example.comсо следующей ссылкой:
Щелкните здесь!
Межсайтовый скриптинг: файл cookie, который отправляется другой стороной. Когда другой пользователь нажимает на эту ссылку, браузер показывает фрагмент кода в атрибуте onclick, заменяя таким образом document.cookieсо списком файлов cookie, доступных с текущей страницы. В результате этот список файлов cookie отправляется на сервер attacker.com. Если злонамеренная публикация злоумышленника находится на веб-сайте HTTPS https://www.example.com, защищенные файлы cookie также будут отправлены на сайт attacker.com в виде простого текста.
Разработчики веб-сайта обязаны отфильтровывать такой вредоносный код.
Такие атаки можно предотвратить с помощью файлов cookie HttpOnly. Эти файлы cookie не будут доступны для языков сценариев на стороне клиента, таких как JavaScript, и поэтому злоумышленник не сможет собрать эти файлы cookie.
В старых версиях многих браузеров были дыры в реализации в реализации XMLHttpRequest API. Этот API позволяет указывать прокси-сервер, который будет получать ответ, и этот прокси-сервер не подчиняется одинакового поведения происхождения. Например, жертва читает сообщение злоумышленника на www.example.com, и сценарий злоумышленника выполняется в браузере жертвы. Сценарий генерирует запрос к www.example.comс прокси-сервером attacker.com. Требуется запрос для www.example.com, все файлы cookie example.comбудут отправляться вместе с запросом, но маршрутизироваться через прокси-сервер злоумышленника. Следовательно, злоумышленник сможет получить файлы cookie жертвы.
Эта атака не будет работать с безопасными файлами cookie, поскольку они могут передаваться только через HTTPS соединения, а протокол HTTPS сквозного шифрования (т. Е. информация зашифровывается в браузере пользователя и расшифровывается на целевом сервере). В этом случае прокси-сервер будет видеть только необработанные зашифрованные байты HTTP-запроса.
, Боб может просмотреть чат-форум, где другой пользователь, Мэллори, разместил сообщение. Предположим, что Мэллори создал элемент изображения HTML, который назван действием на веб-сайте банка Боба (а не на файл изображения), например,
Если банк Боба хранит его аутентификационную информацию в файле cookie, и если срок действия cookie еще не истек, тогда попытка Боба загрузить изображение отправит форму вывод с его файлом cookie, тем авторизуя транзакцию без одобрения Боба.
Cookiejacking - это форма взлома, при которой злоумышленник может получить доступ к сессионным cookie-файлам пользователя Internet Explorer. Обнаруженный Розарио Валотта, исследователь в области безопасности Интернета, эксплойт позволяет злоумышленнику получить файл cookie с любого сайта и таким образом, имя пользователя и пароль, обманув пользователя перетаскивание объекта по экрану. Хотя Microsoft сочла ошибку маловероятной из-за «необходимого уровня взаимодействия с пользователем» и необходимости, чтобы пользователь уже вошел на веб-сайт, файл cookie которого был украден, Валотта смогла использовать социальную инженерию атака для получения за три дня файлов cookie 80 пользователей Facebook из 150 его друзей.
Помимо проблем с конфиденциальностью, файлы cookie также имеют некоторые технические недостатки. В частности, они не всегда идентифицируют пользователей, их можно использовать для атак на систему безопасности, и они часто расходуются с архитектурным стилем программного обеспечения передачи репрезентативного состояния (REST ).
Если на компьютере используется более одного, каждый обычно отдельную область хранения для cookie. Следовательно, файлы cookie идентифицируют не человека, а комбинацию учетной записи пользователя, компьютера и веб-. Таким образом, любой, кто использует несколько учетных записей, компьютеров или браузеров, имеет несколько наборов файлов cookie.
Точно так же файлы cookie не делают различных между использованием, которые используют одну и ту же учетную запись пользователя, компьютер и браузер.
Использование файлов cookie может вызвать несоответствие между состоянием клиента и состоянием, сохраненным в файле cookie. Если пользователь получает файл cookie, а затем нажимает кнопку «Назад» в браузере, состояние обычно не такое, как до этого приобретения. Если пользователь нажимает кнопку, чтобы добавить товар в корзину, и нажимает кнопку «Назад», товар остается в. корзине. Возможно, это не было намерением пользователя, который, возможно, хотел отменить добавление элемента. Это может привести к ненадежности, путанице и ошибкам. Поэтому веб-разработчики должны знать об этой проблеме и принимать меры для разрешения ситуации.
Некоторые операции, которые можно выполнять с помощью файлов cookie, можно также выполнять с помощью других механизмов.
A Веб-токен JSON (JWT) - это автономный пакет информации, который можно использовать для хранения информации об идентичности и подлинности пользователя. Это позволяет использовать их вместо файлов cookie сеанса. В отличие от файлов cookie, которые автоматически прикрепляются браузером к каждому HTTP-запросу, JWT должны быть явно прикреплены к каждому HTTP-веб-запросу.
Протокол HTTP включает протоколы аутентификации доступа и дайджест-аутентификации доступа, которые разрешают доступ к веб-странице только в том случае, если пользователь ввел правильное имя пользователя и пароль. Если серверу требуются такие учетные данные для предоставления доступа к веб-странице, браузер запрашивает их у пользователя и после службы поддержки, браузер отслеживает и отправляет их в каждом последующем запросе. Эта информация может установить для установки пользователя.
Некоторые пользователи могут отслеживаться на основе IP-адреса компьютера, запрашивающего страницу. Сервер знает IP-адрес компьютера, на котором запущен браузер (или прокси , если он используется), теоретически может связать сеанс пользователя с этим IP-адресом.
Однако IP-адреса обычно не являются надежным способом системы идентификации пользователя. Многие компьютеры предназначены для использования одним пользователем, такими как офисные или домашние ПК, которые используются через преобразователи сетевых адресов (NAT). Это означает, что несколько компьютеров будут иметь общий IP-адрес. Более того, некоторые системы, такие как Tor, предназначены для сохранения анонимности в Интернете, что делает отслеживание по IP-адресу непрактичным, невозможным или представляет угрозу безопасности.
Более точный метод основан на встраивании информации в URL. Часть строки запроса URL-адрес - это часть, которая обычно используется для этой цели, но могут использовать эту строку и другие части. Оба механизма сеанса Java Servlet и PHP используют этот метод, если файлы cookie не включены.
Этот метод состоит из того, что веб-сервер сервер строки запроса, содержит идентификатор сеанса, ко всем ссылкам внутри веб-страницы. Когда пользователь переходит по ссылке, браузер отправляет запрос на сервер, позволяя серверу идентифицировать пользователя и поддерживать состояние.
Эти типы строк запроса очень похожи на файлы cookie, поскольку оба отправляют произвольные фрагменты информации, выбранные сервером, и оба отправляют обратно на сервер при каждом запросе. Однако есть некоторые отличия. Строка запроса является частью URL-адреса, при повторном использовании этого URL-адреса на сервере будет отправлена та же прикрепленная часть информации, что может привести к путанице. Например, если предпочтения пользователя закодированы в строке запроса URL-адреса, и пользователь отправляет этот URL-адрес другому пользователю по электронной почте, эти предпочтения будут отключены и для этого другого пользователя.
Более того, если один и тот же пользователь обращается к одной и той же странице несколько раз из разных источников, нет гарантии, что каждый раз будет одна и та же строка запроса. Например, если пользователь посещает страницу, перейдя с внутренней страницы на сайт в первый раз, а затем посещает ту же страницу, перейдя из внешней поисковой системы во второй раз, строки запроса, вероятно, будут другие. Если бы в этой ситуации использовались файлы cookie, они были бы такими же.
Другие недостатки строк запроса связаны с безопасностью. Сохранение данных, идентифицирующих сеанс, в строке запроса позволяет использовать атаки фиксации сеанса, атаки с логированием referer и другие эксплойты безопасности. Передача идентификаторов сеансов в виде файлов cookie HTTP более безопасна.
Другой формой отслеживания сеанса является использование веб-форм со скрытыми полями. Этот метод очень похож на использование строк запроса URL для хранения информации и имеет многие из тех же преимуществ и недостатков. Фактически, если форма обрабатывается с помощью метода HTTP GET, этот метод аналогичен использованию строк запроса URL-адреса, поскольку метод GET добавляет поля формы к URL-адресу в виде строки запроса. Но большинство форм обрабатываются с помощью HTTP POST, в результате чего информация формы, включая скрытые поля, отправляется в теле HTTP-запроса, которое не является частью URL-адреса или файла cookie.
Этот подход дает два преимущества с точки зрения трекера. Во-первых, наличие отслеживающей информации, размещенной в теле HTTP-запроса, а не в URL-адресе, означает, что средний пользователь не заметит ее. Во-вторых, информация о сеансе не копируется, когда пользователь копирует URL-адрес (например, чтобы добавить страницу в закладки или отправить ее по электронной почте).
Все текущие веб-браузеры могут хранить довольно большой объем данных (2–32 МБ) с помощью JavaScript, используя свойство DOM имя окна. Эти данные могут использоваться вместо файлов cookie сеанса, а также являются междоменными. Этот метод может быть объединен с объектами JSON / JavaScript для хранения сложных наборов переменных сеанса на стороне клиента.
Обратной стороной является то, что каждое отдельное окно или вкладка изначально будет иметь пустое свойство window.nameпри открытии. Кроме того, это свойство может использоваться для отслеживания посетителей на разных веб-сайтах, что делает его важным для конфиденциальности в Интернете.
В некоторых отношениях это может быть более безопасно, чем файлы cookie, поскольку его содержимое не отправляется автоматически сервер обрабатывает каждый запрос, например файлы cookie, поэтому он не уязвим для атак с использованием сетевых файлов cookie. Однако, если не принять специальных мер для защиты данных, они уязвимы для других атак, поскольку данные доступны на разных веб-сайтах, открытых в одном окне или на одной вкладке.
Apple использует метод отслеживания, который называется «идентификатор для рекламодателей» (IDFA). Этот метод присваивает уникальный идентификатор каждому пользователю, который покупает устройство Apple iOS (например, iPhone или iPad). Затем этот идентификатор используется рекламной сетью Apple, iAd, для определения рекламы, которую люди просматривают и на которые отвечают.
Поскольку ETag кэшируются браузером и возвращаются с последующими запросами. для того же ресурса сервер отслеживания может просто повторять любой ETag, полученный от браузера, чтобы гарантировать, что назначенный ETag сохраняется бесконечно (аналогично постоянным файлам cookie). Дополнительные заголовки кэширования также могут улучшить сохранность данных ETag.
ETag могут быть сброшены в некоторых браузерах путем очистки кеша браузера .
Некоторые веб-браузеры поддерживают механизмы сохранения, которые позволяют странице хранить информацию локально для дальнейшего использования.
Стандарт HTML5 (который в некоторой степени поддерживают большинство современных веб-браузеров) включает JavaScript API под названием Веб-хранилище, который позволяет два типа хранилища: локальное хранилище и сеанс место хранения. Локальное хранилище ведет себя аналогично постоянным файлам cookie, в то время как хранилище сеанса ведет себя аналогично cookie сеанса, за исключением того, что хранилище сеанса привязано к времени жизни отдельной вкладки / окна (также известное как сеанс страницы), а не к весь сеанс браузера, как файлы cookie сеанса.
Internet Explorer поддерживает постоянную информацию в истории браузера, в избранном браузере, в хранилище XML («данные пользователя») или непосредственно на веб-странице, сохраненной на диске.
Некоторые подключаемые модули веб-браузера также включают механизмы сохранения. Например, Adobe Flash имеет Локальный общий объект, а Microsoft Silverlight имеет изолированное хранилище.
Браузер кеш также может использоваться для хранения информации, которая может использоваться для отслеживания отдельных пользователей. Этот метод использует тот факт, что веб-браузер будет использовать ресурсы, хранящиеся в кэше, вместо того, чтобы загружать их с веб-сайта, когда он определяет, что в кеше уже есть самая последняя версия ресурса.
Например, веб-сайт может обслуживать файл JavaScript с кодом, задающим уникальный идентификатор пользователя (например, var userId = 3243242;). После первого посещения пользователя каждый раз, когда пользователь обращается к странице, этот файл будет загружаться из кеша, а не с сервера. Таким образом, его содержание никогда не изменится.
A отпечаток браузера - это информация, собираемая о конфигурации браузера, например номер версии, разрешение экрана и операционная система, с целью идентификации. Отпечатки пальцев можно использовать для полной или частичной идентификации отдельных пользователей или устройств, даже если файлы cookie отключены.
Базовая информация о конфигурации веб-браузера уже давно собирается службами веб-аналитики, чтобы точно измерить реальный человеческий веб-трафик и учесть различные формы мошенничества с кликами. С помощью языков сценариев на стороне клиента возможен сбор гораздо более эзотерических параметров. Ассимиляция такой информации в одну строку составляет отпечаток устройства. В 2010 году EFF измерял не менее 18,1 бит энтропии, возможной при отпечатках браузера. Создание отпечатков пальцев, более новый метод, утверждает, что добавляет еще 5,7 бит.
Интернет-портал 
Портал компьютерного программирования Эта статья основана на материалах, взятых из Free On-line Dictionary of Computing до 1 ноября 2008 г. и включенных в соответствии с условиями «перелицензирования» GFDL, версия 1.3 или новее.
Этот аудиофайл был создан на основе редакции этой статьи от 28 мая 2016 г., и не отражает последующие правки. () | На Wikimedia Commons есть материалы, связанные с HTTP-куки. |
