Установка файлов cookie с помощью JavaScript в локальном файле HTML

У меня есть следующее дерево каталогов:

  + 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



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 и директива о конфиденциальности
Оцените статью
clickpad.ru
Добавить комментарий