🍪Cookies🍪

🍪Cookies🍪

@frontenders_notes

Понятие


Возможное взаимодействие между браузером и сервером.

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

Спецификации указывают минимальные объёмы, которые должны предоставляться браузерами для хранения cookie. Так, браузер должен хранить по меньшей мере 300 cookie по 4096 байт каждая, и по меньшей мере 20 cookie для одного сервера или домена.

Популярные браузеры имеют соответствующий максимум хранящихся cookie для каждого домена:

На практике, некоторые браузеры могут накладывать более жёсткие ограничения. К примеру, Internet Explorer предоставляет 4096 байт для всех cookie в одном домене.

Имена cookie нечувствительны к регистру в соответствии с разделом 3.1 RFC 2965.

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

Хранение cookie также может ограничиваться в зависимости от веб-сервера, домена или поддомена, где они были созданы.

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

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

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

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

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

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

Поскольку cookie можно очень легко удалить из браузера, программисты ищут способы идентифицировать пользователей даже после полной очистки истории браузера. Одним из таких решений являются зомби-cookie (или evercookie, или persistent cookie) — не удаляемые или трудно удаляемые cookie, которые можно восстановить в браузере с помощью JavaScript. Это возможно потому, что для хранения куки сайт одновременно использует все доступные хранилища браузера (HTTP ETag, Session Storage, Local Storage, Indexed DB), в том числе и хранилища приложений, таких как Flash Player (Local Shared Objects), Microsoft Silverlight (Isolated Storage) и Java (Java persistence API). Когда программа обнаруживает отсутствие в браузере cookie-файла, информация о котором присутствует в других хранилищах — она тут же восстанавливает его на место и, тем самым, идентифицирует пользователя для сайта.


RFC 6265 даёт конкретные указания, как нужно интерпретировать каждый из параметров cookie:

  • name устанавливает имя cookie-файла.
  • value сохраняет значение cookie, которое будет идентифицировать пользователя или содержать служебную информацию.
  • expires и max-age определяют срок жизни cookie, по истечению которого она будет автоматически удалена. Если не указать этот параметр, или установить его значение в ноль, то cookie будут автоматически удалены при закрытии браузера. Для параметра expires указывается конечная дата в формате Tue, 01-Sep-2020 10:50:22 GMT, тогда как для max-age устанавливается количество секунд жизни cookie с момента установки её в браузер.
  • path указывает путь к директории на сервере, для которой будут доступны cookie. Если указать корневой каталог /, то cookie будут доступны всему домену. По умолчанию значением является текущая директория, из которой cookie устанавливаются в браузер.
  • domain отмечает, какой домен или поддомен имеет доступ к этой cookie. Для того, чтобы сделать cookie доступными для всего домена (включая поддомены), нужно просто указать имя домена (например example.com).
  • secure параметр указывает браузеру, что cookie должны передаваться на сервер только по защищённому https-соединению.
  • httponly параметр запрещает доступ к cookie посредством API document.cookie. Эта возможность была предложена в качестве меры для эффективного предотвращения краж cookie посредством XSS-атак.
  • samesite это относительно новый параметр (определённый в RFC 6265bis), который сообщает браузерам, что cookie не должны отсылаться с межсайтовыми запросами. Это в некотором роде обеспечивает защиту от межсайтовых подделок запроса (CSRF). У этого параметра есть три состояния, которые определяют поведение cookie для различных сценариев пользования сайтом.


Report Page