У меня есть следующее дерево каталогов:
+ folder1 | --- folder2 | ------ page1.html | --- page2.html
Если я установил какой-нибудь файл cookie на page1.html
с помощью JavaScript, какой путь будет использоваться для этого файла cookie?
Изменить:
Позвольте мне объяснить это лучше. Я работаю с локальным файлом. Доступ к page1.html
осуществляется через /home/user/.../folder1/folder2/page1.html
, а не через клиентский компьютер с использованием HTTP Сервер.
Просто для пояснения:
Похоже, что некоторые браузеры (например, Chrome) не сохраняют файлы cookie при использовании файла :///
, но и Firefox, и Internet Explorer работают.
На странице MDC для document.cookie
:
Если не указано, [аргумент
path
] по умолчанию соответствует текущему пути к текущему местоположению документа.
Итак, в вашем случае это будет /folder1/folder2/
.
Сначала я не заметил, что вы в заголовке вопроса указал «местный» — не уверен, что это было обновлено, когда я писал свой ответ. Файлы cookie не устанавливаются при просмотре с использованием протокола file:///
, в зависимости от браузера.
Браузеры не хранят файлы cookie для протокола URL file://
, он просто и тихо не сможет ничего установить. Так что, если это действительно «локально», а не в домене, у вас может быть проблема.
3
Если вы используете Mac, вы можете закрыть Chrome и перезапустить его следующим образом:
/Applications/Google Chrome.app/Contents/ MacOS/Google Chrome --enable-file-cookies
После этого вы сможете устанавливать файлы cookie для локальных файлов.
1
установите —enable-file-cookies для Chrome, и он должен работать для вас. Кроме того, есть некоторые функции, которые вам также необходимо установить «принимать все файлы cookie», чтобы они работали, но если вы это сделаете, убедитесь, что вы сделали это, прежде чем вернуться в Интернет.
2
В качестве обходного пути вы можете использовать Tampermonkey с доступом к локальным файлам (как включить локальные htm-страницы в сценарий Tampermonkey?) Таким образом, вы будете использовать хранилище Tampermonkey и сможете устанавливать и получать свои данные с помощью функций GM_getValue (данные) и GM_setValue (данные). Я использовал это для своей локальной HTML-страницы, которую я использовал как настраиваемую альтернативу проводнику Windows
Использование файлов cookie HTTP
HTTP cookie (веб-файл cookie, файл cookie браузера) — это небольшой фрагмент данных, который отправляет сервер в веб-браузер пользователя. Браузер может сохранить его и отправить обратно с более поздними запросами на тот же сервер. Как правило, он используется, чтобы определить, поступили ли два запроса из одного и того же браузера — например, чтобы пользователь оставался в системе. Он запоминает информацию о состоянии для протокола HTTP без сохранения состояния.
Файлы cookie в основном используются для трех целей:
- Управление сеансом
- Логины, корзины покупок, результаты игр или что-то еще, что сервер должен запомнить
- Персонализация
- Пользовательские настройки, темы и другие настройки
- Отслеживание
- Запись и анализ поведения пользователя
Куки-файлы когда-то использовались для общего хранилища на стороне клиента. Хотя это было законно, когда они были единственным способом хранить данные на клиенте, теперь рекомендуется использовать современные API-интерфейсы хранилища. Файлы cookie отправляются с каждым запросом, поэтому они могут ухудшить производительность (особенно для мобильных подключений для передачи данных). Современные API для клиентского хранилища — это API веб-хранилища ( localStorage
и sessionStorage
) и IndexedDB.
Чтобы просмотреть сохраненные файлы cookie (и другое хранилище, которое может использовать веб-страница), вы можете включить инспектор хранилища в инструментах разработчика и выбрать файлы cookie в дереве хранилища.
После получения HTTP-запроса сервер может отправить один или несколько заголовков Set-Cookie
с ответом. Файл cookie обычно сохраняется в браузере, а затем файл cookie отправляется с запросами на тот же сервер внутри HTTP-заголовка Cookie
. Можно указать дату истечения срока или продолжительность, после которой cookie больше не будет отправляться. Могут быть установлены дополнительные ограничения для определенного домена и пути, ограничивающие отправку файла cookie. Подробнее об атрибутах заголовка, упомянутых ниже, см. В справочной статье Set-Cookie
.
Код Set-Cookie
HTTP-заголовок ответа отправляет файлы cookie с сервера пользовательскому агенту. Простой файл cookie устанавливается следующим образом:
Set-Cookie: =>
Это показывает, что сервер отправляет заголовки, чтобы сообщить клиент для хранения пары файлов cookie:
HTTP/2.0 200 OKContent-Type: text/htmlSet-Cookie: yummy_cookie = chocoSet-Cookie: вкусный_cookie = клубника [содержимое страницы]
GET/sample_page.html HTTP/2.0Host: www.example.orgCookie: yummy_cookie = choco; вкусно_cookie = клубника
Set-Cookie
в различных серверных приложениях:
- PHP
- Узел. JS
- Python
- Ruby on Rails
время жизни cookie можно определить двумя способами:
- Session cookie удаляются по окончании текущего сеанса. Браузер определяет, когда заканчивается «текущий сеанс», и некоторые браузеры используют восстановление сеанса при перезапуске, что может привести к тому, что файлы cookie сеанса будут длиться бесконечно долго.
- Постоянные файлы cookie удаляются в дату, указанную атрибутом
Expires
, или по истечении периода времени, указанного вMax-Age
атрибут.
Например:
Set-Cookie: id = a3fWa; Срок действия истекает = чт, 31 октября 2021 года, 07:28:00 по Гринвичу;
Примечание : когда срок действия истекает
дата установлена, время и дата устанавливаются относительно клиента, на котором установлен файл cookie, а не сервера.
Если ваш сайт аутентифицирует пользователей, он должен сгенерировать заново и повторно отправить файлы cookie сеанса, даже уже существующие, всякий раз, когда пользователь аутентифицируется. Этот метод помогает предотвратить атаки фиксации сеанса, когда третья сторона может повторно использовать сеанс пользователя.
Существует несколько способов обеспечить безопасную отправку файлов cookie и не доступны для непреднамеренных сторон или сценариев: атрибут Secure
и атрибут HttpOnly
.
Файл cookie с Secure отправляется на сервер только с зашифрованным запросом по протоколу HTTPS, а не с незащищенным HTTP (кроме локального хоста), и поэтому к нему не может легко получить доступ злоумышленник. средний нападающий. Небезопасные сайты (с http:
в URL-адресе) не могут устанавливать файлы cookie с атрибутом Secure
. Однако не следует полагать, что Secure
предотвращает любой доступ к конфиденциальной информации в файлах cookie; например, он может быть прочитан и изменен кем-то, у кого есть доступ к жесткому диску клиента (или JavaScript, если атрибут HttpOnly
не установлен).
Файл cookie с атрибутом HttpOnly
недоступен для API JavaScript Document.cookie
; он отправляется только на сервер. Например, файлы cookie, которые сохраняют сеансы на стороне сервера, не обязательно должны быть доступны для JavaScript и должны иметь атрибут HttpOnly
. Эта мера предосторожности помогает смягчить атаки межсайтовых сценариев (XSS).
Вот пример:
Set-Cookie: id = a3fWa; Срок действия истекает = Thu, 21 Oct 2021 07:28:00 GMT; Безопасный; HttpOnly
Атрибуты Domain
и Path
определяют область файла cookie: по каким URL-адресам файлы cookie должны отправляться.
Атрибут домена
Атрибут Домен
указывает каким хостам разрешено получать cookie. Если не указано, по умолчанию используется тот же хост, который установил cookie, за исключением субдоменов . Если указан Domain
, то субдомены всегда включаются. Следовательно, указание Domain
менее ограничительно, чем его пропуск. Однако это может быть полезно, когда субдоменам необходимо обмениваться информацией о пользователе.
Например, если установлен Domain = mozilla.org
, тогда файлы cookie доступны на субдоменах, таких как developer.mozilla.org
.
Атрибут пути
Атрибут Path
указывает путь URL-адреса, который должен существовать в запрошенном URL-адресе для отправки заголовка Cookie
. Символ % x2F
(«/») считается разделителем каталогов, и подкаталоги также совпадают.
Например, если Path = /docs
установлен, эти пути совпадают:
/docs
-
/docs/Web/
/docs/Web/HTTP
атрибут SameSite
Атрибут SameSite
позволяет серверам указывать, будут ли отправляться файлы cookie с запросами из разных источников (где сайт определяется регистрируемым доменом), что обеспечивает некоторую защиту против атак с подделкой межсайтовых запросов (CSRF).
Принимает три возможных значения: Strict
, Lax
и Нет
. При использовании Strict
cookie отправляется только на тот же сайт, что и тот, который его создал; Lax
аналогичен, за исключением того, что файлы cookie отправляются, когда пользователь переходит на сайт источника cookie, например, переходя по ссылке с внешнего сайта; Нет
указывает, что файлы cookie отправляются как при исходящих, так и при межсайтовых запросах, но только в безопасных контекстах (т. е. если SameSite = None
, тогда также должен быть установлен атрибут Secure
). Если атрибут SameSite
не установлен, то файл cookie обрабатывается как Lax
.
Вот пример:
Set-Cookie: mykey = myvalue; SameSite = Strict
Стандарт, связанный с SameSite
, недавно изменен (MDN документирует новое поведение выше). См. Таблицу совместимости браузера cookie для получения информации о том, как атрибут обрабатывается в определенных версиях браузера:
-
SameSite = Lax
— новое значение по умолчанию, еслиSameSite
не указан. Раньше по умолчанию файлы cookie отправлялись для всех запросов. - Файлы cookie с
SameSite = None
теперь также должны указыватьSecure
атрибут (они требуют безопасного контекста).
Конструкция механизма cookie такова, что сервер не может подтвердить, что cookie был установлен в безопасном источнике или даже сообщить , где изначально был установлен файл cookie.
Уязвимое приложение в субдомене может установить файл cookie с доменом
, который дает доступ к этому cookie на всех других поддоменах. Этим механизмом можно злоупотреблять при атаке фиксации сеанса . Смотрите фиксацию сеанса для основных методов смягчения.
Однако в качестве меры глубокой защиты можно использовать префиксы файлов cookie для утверждения конкретных фактов о файлах cookie. Доступны два префикса:
__Host-
- Если у имени файла cookie есть этот префикс, он принимается в заголовке
Set-Cookie
, только если он также отмечен атрибутомSecure
, был отправлен из безопасного источника, не включает атрибутДомен
, а для атрибутаPath
установлено значение/
. Таким образом, эти файлы cookie можно рассматривать как «заблокированные доменом». __Secure-
- Если имя файла cookie имеет этот префикс принимается в заголовке
Set-Cookie
, только если он отмечен атрибутомSecure
и был отправлен из безопасного источника. Это слабее, чем префикс__ Host-
.
Файлы cookie с этими префиксами, которые не соответствуют их ограничениям, отклоняются браузером. Обратите внимание, что это гарантирует, что если субдомен будет создавать cookie с префиксом, он будет либо ограничен субдоменом, либо полностью проигнорирован. Поскольку сервер приложений проверяет наличие определенного имени файла cookie только при определении, аутентифицирован ли пользователь или верен ли токен CSRF, это эффективно действует как мера защиты от фиксации сеанса.
На сервере приложений веб-приложение должно проверять полное имя файла cookie, включая префикс — пользовательские агенты не удаляют префикс из файла cookie перед его отправкой. в заголовке Cookie
запроса.
Дополнительные сведения о префиксах файлов cookie и текущем состоянии поддержки браузером см. в разделе «Префиксы» в Set- Справочная статья о файлах cookie.
Новые файлы cookie могут быть созданы с помощью JavaScript с использованием свойства Document.cookie
, а существующие файлы cookie также могут быть доступны из JavaScript, если Флаг HttpOnly
не установлен.
document.cookie = "yummy_cookie = choco"; document.cookie = "вкусный_cookie = клубничный"; console. log (document.cookie);
Файлы cookie созданы через JavaScript не может включать флаг HttpOnly
.
Обратите внимание на проблемы безопасности в разделе «Безопасность» ниже. Файлы cookie, доступные для JavaScript, могут быть украдены через XSS.
Безопасность
Информация должна храниться в файлах cookie с понимание того, что все значения файлов cookie видны и могут быть изменены конечным пользователем. В зависимости от приложения может быть желательно использовать непрозрачный идентификатор, который просматривается сервером, или исследовать альтернативные механизмы аутентификации/конфиденциальности, такие как веб-токены JSON.
Способы для предотвращения атак с использованием файлов cookie:
- Используйте атрибут
HttpOnly
для предотвращения доступа к значениям файлов cookie через JavaScript. - Файлы cookie, которые используются для конфиденциальной информации (например, для проверки подлинности), должны иметь короткий срок жизни, а атрибуту
SameSite
присвоено значениеStrict
илиLax
. (См. Файлы cookie SameSite выше.) В браузерах, поддерживающих SameSite, это гарантирует, что файл cookie аутентификации не будет отправляться с межсайтовыми запросами, поэтому такой запрос фактически не аутентифицируется для сервера приложений.
Отслеживание и конфиденциальность
Файл cookie связан с доменом. Если этот домен совпадает с доменом страницы, на которой вы находитесь, файл cookie называется основным файлом cookie . Если домен другой, это сторонний файл cookie . Хотя сервер, на котором размещена веб-страница, устанавливает собственные файлы cookie, страница может содержать изображения или другие компоненты, хранящиеся на серверах в других доменах (например, рекламные баннеры), которые могут устанавливать сторонние файлы cookie. В основном они используются для рекламы и отслеживания в Интернете. См., Например, типы файлов cookie, используемых Google.
Сторонний сервер может создать профиль истории просмотров и привычек пользователя на основе файлов cookie, отправленных ему одним и тем же браузером при доступе к нескольким сайтам . Firefox по умолчанию блокирует сторонние файлы cookie, которые, как известно, содержат трекеры. Сторонние файлы cookie (или просто файлы cookie отслеживания) также могут быть заблокированы другими настройками или расширениями браузера. Блокировка файлов cookie может привести к тому, что некоторые сторонние компоненты (например, виджеты социальных сетей) не будут работать должным образом.
Серверы могут (и должны) установить атрибут SameSite файлов cookie, чтобы указать, должны ли файлы cookie могут быть отправлены на сторонние сайты.
Законодательство или нормативные акты, регулирующие использование файлов cookie, включают:
- Общие правила конфиденциальности данных (GDPR) в Европейском союзе.
- Директива ЕС о конфиденциальности данных
- Закон Калифорнии о конфиденциальности потребителей
Эти правила имеют глобальный охват, потому что они применяются к любому сайту в World Wide сети, к которому получают доступ пользователи из этих юрисдикций (ЕС и Калифорния, с оговоркой, что закон Калифорнии применяется, помимо прочего, только к организациям с валовой выручкой более 25 миллионов долларов США.)
Эти правила включают такие требования, как:
- Уведомление пользователей о том, что ваш сайт использует файлы cookie.
- Разрешение пользователям отказаться от получения g некоторые или все файлы cookie.
- Разрешить пользователям использовать большую часть вашего сервиса без получения файлов cookie.
Могут быть другие правила, регулирующие использование куки в вашем регионе. Вы должны знать и соблюдать эти правила. Есть компании, которые предлагают код «баннера cookie», который помогает вам соблюдать эти правила.
Другие способы хранения информации в браузере
Другой подход к хранению данных в браузере — API веб-хранилища. Окно. Свойства sessionStorage и window.localStorage соответствуют сессионным и постоянным куки-файлам по продолжительности, но имеют большие пределы хранения, чем куки-файлы, и никогда не отправляются на сервер. Более структурированные и большие объемы данных могут быть сохранены с помощью API IndexedDB или библиотеки, построенной на нем.
Были созданы другие методы, позволяющие воссоздавать файлы cookie после их удаления, известные как » зомби-куки. Эти методы нарушают принципы конфиденциальности и контроля пользователей, могут нарушать правила конфиденциальности данных и могут подвергнуть веб-сайт, использующий их, юридической ответственности.
-
Set-Cookie
Cookie
-
Document.cookie
Navigator.cookieEnabled
- Файлы cookie SameSite
- Проверка файлов cookie с использованием хранилища Инспектор
- Спецификация файлов cookie: RFC 6265
- HTTP cookie в Википедии
- Файлы cookie, GDPR и директива о конфиденциальности