Блог

HTTP cookies

Редакция Lodoss Team
0

Cookies - один из механизмов, на которых построена работа в сети Internet. Многие пользователи и даже разработчики не понимают большой разницы между печеньками и cookies в браузере — и зря! Неправильное использование HTTP cookies может привести как минимум к получению конфиденциальной информации о действиях пользователей и, в ряде случаев, к взлому и потере всех средств на банковских счетах. Именно поэтому недавно в европейском союзе был принят закон GDPR, который обязывает сайты бережно относиться к cookies и другой персональной информации, а также спрашивать у пользователя разрешение на сохранение и передачу этой информации.

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

Cookie используются для 3-х целей:

1.Управления сеансом (логины, корзины для виртуальных покупок);
2.Персонализации (пользовательские предпочтения);
3.Мониторинга (запись и анализ поведения пользователя);

Ранее cookies использовались в качестве хранилища информации на стороне пользователя. Это могло иметь смысл в отсутствии вариантов, когда они были единственным способом хранения данных на пользователе. В настоящее время рекомендуется использовать API современных Web хранилищ. Так как cookies пересылаются с каждым запросом, они могут слишком сильно снижать производительность (особенно в мобильных устройствах). Современные API для клиентского хранилища — это API Web storage, API (localStorage и sessionStorage) и IndexedDB.

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

Заголовки Set-Cookie и Cookie

Заголовок Set-Cookie HTTP-отклика используется для отправки cookie с сервера на клиентское приложение (браузер). Простой cookie может задаваться так:

Этот заголовок с сервера дает клиенту указание сохранить cookie (это делают, например, PHP, Node.js, Python и Ruby on Rails). Отклик, отправляемый браузеру, содержит заголовок Set-Cookie, и cookie запоминается браузером.

Теперь, с каждым новым запросом к серверу, при помощи заголовка Cookie браузер будет возвращать серверу все сохраненные ранее cookies.

Простой cookie, пример которого приведен выше, представляет собой сессионный cookie (session cookie) - такие cookie удаляется при завершении работы клиента, поскольку в нем не указана директива Expires или Max-Age. Однако, если в браузере включено автоматическое восстановление сеанса, что случается очень часто, cookie сеанса может храниться постоянно, как если бы браузер никогда не закрывался.

Постоянные cookies

Постоянные cookie (permanent cookies) удаляются не с закрытием клиента, а при наступлении определенной даты (атрибут Expires) или после определенного интервала времени (атрибут Max-Age).

Secure ("безопасные") и HttpOnly cookies

"Безопасные" (secure) cookie отправляется на сервер только с зашифрованным запросом по протоколу SSL и HTTPS. Однако важные данные никогда не следует передавать или хранить в cookies, поскольку сам их механизм весьма уязвим в отношении безопасности, а флаг secure никакого дополнительного шифрования или средств защиты не обеспечивает.

Начиная с Chrome 52 and Firefox 52, незащищенные сайты (http:) не могут создавать сookie с флагом secure.

Чтобы помочь смягчить атаки межсайтовых сценариев (XSS), файлы cookie HttpOnly недоступны для документа Document.cookie API, они отправляются только на сервер. Устанавливайте этот флаг для тех cookie, к которым не требуется обращаться через JavaScript. Например, файлы cookie, сохраняющие сеансы на стороне сервера, не должны быть доступны JavaScript, и должен быть установлен флаг HttpOnly.

Область видимости cookies

Директивы Domain и Path определяют область видимости сookie: на какие URL-адреса должны быть отправлены файлы cookie.

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

Например, если задано Domain=mozilla.org, то cookie включены и в поддоменах, например, в developer.mozilla.org.

Атрибут Path указывает URL, который должен быть в запрашиваемом ресурсе на момент отправки заголовка Cookie.  Символ %x2F ("/") интерпретируется как разделитель разделов, подразделы также включаются.

Если задано Path=/docs, то подходят и такие пути, как:

1."/docs"
2."/docs/Web/"
3."/docs/Web/HTTP"

Cookie SameSite

Cookie SameSite позволяют серверам декларировать, что cookie не должны отсылаться с межсайтовыми запросами, что в некотором роде обеспечивает защиту от межсайтовых подделок запроса (CSRF). Cookie SameSite находятся пока в стадии эксперимента и поддерживаются не всеми браузерами.

Доступ из JavaScript посредством Document.cookie

Cookie можно создавать через JavaScript при помощи свойства Document.cookie. Если флаг HttpOnly не установлен, то и доступ к существующим cookies можно получить через JavaScript.

Учитывайте, пожалуйста, вытекающие из этого проблемы в отношении безопасности, подчеркнутые ниже (раздел Security). Cookie, доступные для JavaScript, могут быть похищены посредством XSS.

Удаление


Для удаления cookie сервер должен передать Set-Cookie c истекшим временем жизни, например:

Безопасность

Важная информация никогда не должна храниться или передаваться в cookies HTTP, поскольку этот механизм сам по себе небезопасен.

Захват сессии (session hijacking) и XSS


Cookie часто используются в веб-приложениях для идентификации пользователя и сеанса работы, в котором он прошел процедуру аутентификации. Соответственно, похищение cookies из приложения может привести к захвату авторизованного сеанса пользователя. Кража cookies часто осуществляется посредством социальной инженерии (Social Engineering) и использования уязвимости приложения для XSS.

Атрибут HttpOnly помогает понизить эту угрозу, перекрывая доступ к cookies из JavaScript..

Межсайтовая подделка запроса (CSRF - Cross-site request forgery)

В Wikipedia приведен хороший пример CSRF. В сообщение (например, в чате или на форуме) включают (якобы) изображение, которое, на самом деле, представляет собой запрос к банковскому серверу на снятие денег:

Теперь, если вы зашли в свой банковский аккаунт, а cookie по-прежнему действительны (и никакой дополнительной проверки не требуется), то при загрузке HTML-документа с этим изображением деньги будут переведены с вашего счета. Для конечных точек, которым требуется POST-запрос, можно программно инициировать отправку <form> (возможно, в невидимом виде <iframe>) при загрузке страницы:

Есть несколько методов, которые следует использовать, чтобы предотвратить это:

1.GET запросы должны приводить к изменению данных. А запросы, приводящие к изменению данных должны использовать метод POST.

2.Маркер CSRF должен быть включен в элементы <form> через скрытое поле ввода. Этот маркер должен быть уникальным для каждого пользователя и храниться (например, в файле cookie) так, чтобы сервер мог искать ожидаемое значение при отправке запроса. Для всех запросов non-GET, которые могут выполнить действие - это поле ввода следует сравнить с ожидаемым значением. Если есть несоответствие, запрос должен быть прерван.

Этот метод защиты основан на том, что злоумышленник не может предсказать назначенный пользователем маркер CSRF. Маркер должен быть восстановлен при входе в систему.

3.Файлы cookie, используемые для конфиденциальных действий (например, сеансовые файлы cookie), должны иметь короткий срок службы с атрибутом SameSite, установленным в Strict или Lax. (см. файлы cookie SameSite выше). При поддержке браузеров это гарантирует, что файл cookie сеанса не будет отправлен вместе с межсайтовыми запросами, и поэтому запрос фактически не аутентифицируется на сервере приложений.

4.Должны быть развернуты как маркеры CSRF, так и файлы cookie SameSite. Это гарантирует, что все браузеры защищены и обеспечивает защиту, когда файлы cookie SameSite не могут помочь (например, атаки, исходящие из отдельного поддомена).

5.Дополнительные советы по профилактике см. в шпаргалке OWASP CSRF prevention.

Отслеживание и частные данные

Сторонние (Third-party) cookie

Cookies имеют домен, связанный с ними. Если он совпадает с доменом страницы, на которой вы находитесь, то их называют "cookies первого лица" (first-party cookies). Если это другой домен, их называют "сторонними cookies" (third-party cookies). Cookies первого лица отсылаются только на тот сервер, который их создал. Однако, страница может содержать изображения или другие компоненты (например, рекламные баннеры), хранящиеся на других серверах. Cookies, которые отправляются через эти сторонние компоненты, называются сторонними cookies и в основном используются для рекламы и отслеживания в интернете. В качестве примера можно рассмотреть типы файлов cookie, используемые Google. Большинство браузеров по умолчанию разрешают использование сторонних cookies, но есть расширения, позволяющие их блокировать (например, Privacy Badger от EFF).

Если вы не сообщите об использовании сторонних cookies, а пользователь обнаружит их самостоятельно, то доверие к вам может пошатнуться. Чтобы избежать этого, лучше предоставлять соответствующую информацию. В некоторых странах использование cookies регламентируется законодательством. Прочитать об этом можно, например, в Википедии в разделе cookie statement (создание cookie).

Не отслеживать (Do-Not-Track)

Для запрета на отслеживание со стороны приложения, или межсайтового отслеживания, можно использовать заголовок DNT, хотя технических или законодательных требований на этот счет нет. Подробнее об этом рассказывается в разделе заголовок DNT.

Директива Евросоюза о cookies

Правила по использованию cookies в Евросоюзе (ЕС) определены в Директиве 2009/136/EC Европарламента (Directive 2009/136/EC), вступившей в действие 25 мая 2011. Это не закон, как таковой, а рекомендация странам-членам ЕС принять законы, соответствующие её требованиям. В каждой стране на этот счет могут быть свои законы.

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

Подробнее об этом можно прочитать в соответствующем разделе Википедии (Wikipedia). За наиболее полной и точной информацией обращайтесь к законодательствам конкретных стран.

Хороший программист никогда не передает или хранит важные данные в cookies. Будь хорошим программистом!

HTTP cookies

0