Как работают домены файлов cookie браузера?

StackOverflow https://stackoverflow.com/questions/1062963

Вопрос

Из-за странных проблем с файлами cookie домена / поддомена, которые я получаю, я хотел бы знать, как браузеры обрабатывают файлы cookie.Если они делают это по-разному, было бы также неплохо знать различия.

Другими словами, когда браузер получает файл cookie, этот файл cookie МОЖЕТ содержать домен и путь, привязанный к нему.Или нет, и в этом случае браузер, вероятно, заменяет их некоторыми значениями по умолчанию.Вопрос 1:что это такое?

Позже, когда браузер собирается сделать запрос, он проверяет свои файлы cookie и отфильтровывает те, которые он должен отправить для этого запроса.Он делает это, сопоставляя их с путем запроса и доменом.Вопрос 2:каковы правила подбора?

Добавлено:

Причина, по которой я спрашиваю об этом, заключается в том, что меня интересуют некоторые крайние случаи.Нравится:

  • Будет ли печенье для .example.com быть доступным для www.example.com?
  • Будет ли печенье для .example.com быть доступным для example.com?
  • Будет ли печенье для example.com быть доступным для www.example.com?
  • Будет ли печенье для example.com быть доступным для anotherexample.com?
  • Будет www.example.com иметь возможность установить файл cookie для example.com?
  • Будет www.example.com иметь возможность установить файл cookie для www2.example.com?
  • Будет www.example.com иметь возможность установить файл cookie для .com?
  • И т.д.

Добавлено 2:

Кроме того, может ли кто-нибудь подсказать, как мне следует установить файл cookie, чтобы:

  • Он может быть установлен любым из следующих способов www.example.com или example.com;
  • Он доступен обоим www.example.com и example.com.
Это было полезно?

Решение

Хотя есть RFC 2965 (Set-Cookie2, уже устаревший RFC 2109) это следует определите файл cookie в настоящее время большинство браузеров не полностью поддерживают это, а просто соответствуют оригинальная спецификация от Netscape.

Существует различие между Домен значение атрибута и действующий домен:первое взято из Set-Cookie поле заголовка, и последнее является интерпретацией значения этого атрибута.Согласно RFC 2965, должно применяться следующее:

  • Если Набор-Cookie поле заголовка не делает иметь Домен атрибут, действующий домен - это домен запроса.
  • Если есть Домен атрибут присутствует, его значение будет использоваться в качестве эффективного домена (если значение не начинается с . это будет добавлено клиентом).

Имея действующий домен, он также должен домен-совпадение текущий запрошенный домен для установки;в противном случае файл cookie будет изменен.То же правило применяется и при выборе файлов cookie для отправки в запросе.

Сопоставляя эти знания с вашими вопросами, следует применять следующее:

  • Печенье с Domain=.example.com будет быть доступным для www.example.com
  • Печенье с Domain=.example.com будет быть доступным для example.com
  • Печенье с Domain=example.com будет преобразован в .example.com и таким образом будет также будут доступны для www.example.com
  • Печенье с Domain=example.com будет нет быть доступным для anotherexample.com
  • www.example.com будет иметь возможность установить файл cookie для example.com
  • www.example.com будет нет иметь возможность установить файл cookie для www2.example.com
  • www.example.com будет нет иметь возможность установить файл cookie для .com

И установить и прочитать файл cookie для / by www.example.com и example.com, установите его для .www.example.com и .example.com соответственно.Но первый (.www.example.com) будет доступен только для других доменов ниже этого домена (например, foo.www.example.com или bar.www.example.com) где .example.com также может быть доступен с любого другого домена ниже example.com (например, foo.example.com или bar.example.com).

Другие советы

Предыдущие ответы немного устарели.

RFC 6265 был опубликован в 2011 году на основе консенсуса браузеров того времени.С тех пор возникли некоторые сложности с общедоступными доменами с суффиксами.Я написал статью, объясняющую текущую ситуацию - http://bayou.io/draft/cookie .domain.html

Подводя итог, правила, которым следует следовать в отношении домена файлов cookie:

  • Тот Самый исходный домен домен файла cookie - это домен отправителя запроса.

  • Если исходным доменом является IP-адрес, атрибут домена файла cookie не должен быть установлен.

  • Если атрибут домена файла cookie не задан, файл cookie применим только к его исходному домену.

  • Если установлен доменный атрибут файла cookie,

    • файл cookie применим к этому домену и всем его поддоменам;
    • домен файла cookie должен совпадать с исходным доменом или являться родительским по отношению к нему
    • домен файла cookie не должен быть TLD, общедоступным суффиксом или родительским элементом общедоступного суффикса.

Из этого можно сделать вывод, что файл cookie всегда применим к своему исходному домену.

Домен cookie не должен иметь начальную точку, как в .foo.com - просто используйте foo.com

В качестве примера,

  • x.y.z.com может установить домен cookie для себя или родителей - x.y.z.com, y.z.com, z.com.Но не com, который является общедоступным суффиксом.
  • файл cookie с доменом=y.z.com применим к y.z.com, x.y.z.com, a.x.y.z.com и т.д.

Примеры общедоступных суффиксов - com, edu, uk, co.uk, blogspot.com, compute.amazonaws.com

Для получения более подробной информации ознакомьтесь с содержанием RFC2965.Конечно, это не обязательно означает, что все браузеры ведут себя абсолютно одинаково.

Однако в общем случае правилом для пути по умолчанию, если он не указан в файле cookie, является путь в URL, с которого поступил заголовок Set-Cookie.Аналогично, по умолчанию для Домена используется полное имя хоста в URL-адресе, с которого был получен Set-Cookie.

Правила сопоставления для домена требуют, чтобы домен cookie соответствовал хосту, к которому направляется запрос.Файл cookie может указывать более широкое соответствие доменам, включая * .в домене установлен атрибут-Cookie (это единственная область, которая может варьироваться в браузерах).Сопоставление пути (при условии совпадения домена) заключается в том, что запрашиваемый путь должен находиться внутри пути, указанного в файле cookie.Обычно сеансовые файлы cookie устанавливаются с помощью path=/ или path=/ApplicationName/, поэтому файл cookie доступен для всех запросов в приложение.

Ответ на добавленный:

  • Будет ли доступен файл cookie для .example.com для www.example.com? ДА
  • Будет ли доступен файл cookie для .example.com для example.com? Не знаю
  • Будет ли доступен файл cookie для example.com для www.example.com? Не должен, но... *
  • Будет ли доступен файл cookie для example.com для anotherexample.com? НЕТ
  • Удастся ли www.example.com установить cookie для example.com? ДА
  • Удастся ли www.example.com установить cookie для www2.example.com? НЕТ (Кроме via .example.com)
  • Будет www.example.com быть в состоянии установить cookie для .ком? НЕТ (Вы не можете установить файл cookie на таком высоком уровне пространства имен, и вы не можете установить его для чего-то подобного.co.uk).

* Я не могу протестировать это прямо сейчас, но у меня есть подозрение, что, по крайней мере, IE7 / 6 будет обрабатывать путь example.com как будто это было .example.com.

Последним (точно третьим) RFC для этой проблемы является RFC-6265 (устаревает RFC-2965, который, в свою очередь, устаревает RFC-2109).

В соответствии с этим если сервер опустит атрибут Домена, агент пользователя вернет файл cookie только на сервер исходный сервер (сервер, на котором находится данный ресурс).Но это также предупреждение что некоторые существующие пользовательские агенты обрабатывают отсутствующий атрибут Домена так, как если бы атрибут Домена присутствовал и содержал текущее имя хоста (например, если example.com возвращает заголовок Set-Cookie без атрибута домена, эти пользовательские агенты также ошибочно отправят cookie на www.example.com).

Когда атрибут домена будет указан, он будет обрабатываться как полное доменное имя (если в атрибуте есть начальная точка, он будет проигнорирован).Сервер должен соответствовать домену, указанному в атрибуте (иметь точно такое же доменное имя или быть его поддоменом), чтобы получить этот файл cookie.Точнее , это указанный здесь.

Так, например:

  • атрибут файла cookie Domain=.example.com эквивалентно Domain=example.com
  • файлы cookie с такими атрибутами Домена будут Доступно для example.com и www.example.com
  • файлы cookie с такими атрибутами Домена будут недоступно для another-example.com
  • указание атрибута cookie, например Domain=www.example.com закроет путь для www4.example.com

PS:запятая в конце атрибута Домена приведет к тому, что агент пользователя проигнорирует этот атрибут =(

Известно, что RFC не отражают реальность.

Лучше проверить черновик-ietf-httpstate-файл cookie, незавершенная работа.

Существуют правила, которые определяют, примет ли браузер заголовок ответа Set-header (запись файлов cookie на стороне сервера), немного отличающиеся правила / интерпретации для набора файлов cookie с использованием Javascript (я не тестировал VBScript).

Затем существуют правила, которые определяют, будет ли браузер отправлять файл cookie вместе с запросом страницы.

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

Я был удивлен, прочитав раздел 3.3.2 об отказе от файлов cookie:

http://tools.ietf.org/html/rfc2965

Это говорит о том, что браузер должен отклонить файл cookie от x.y.z.com с доменом .z.com, потому что 'x.y' содержит точку.Итак, если я не неверно истолковываю RFC и / или вышеприведенные вопросы, могут быть добавлены вопросы:

Будет ли доступен файл cookie для .example.com для www.yyy.example.com?Нет.

Будет ли файл cookie, установленный исходным сервером www.yyy.example.com, с доменом .example.com, иметь значение, отправленное агентом пользователя на xxx.example.com?Нет.

Мы протестировали все это в последних версиях Chrome, Firefox, Safari в 2019 году.

Ответ на добавленный:

  • Будет ли доступен файл cookie для .example.com для www.example.com? ДА
  • Будет ли доступен файл cookie для .example.com для example.com? ДА
  • Будет ли доступен файл cookie для example.com для www.example.com? НЕТ, Домен без подстановочного знака соответствует только самому себе.
  • Будет ли доступен файл cookie для example.com для anotherexample.com? НЕТ
  • Удастся ли www.example.com установить cookie для example.com? НЕТ, он сможет установить cookie для '.example.com' , но не для 'example.com'.
  • Удастся ли www.example.com установить cookie для www2.example.com? НЕТ.Но он может установить cookie для .example.com, к которому www2.example.com можно получить доступ.
  • Будет www.example.com быть в состоянии установить cookie для .ком? НЕТ

Будет www.example.com иметь возможность установить файл cookie для .com?

Нет, но example.com.fr возможно, удастся установить файл cookie для example2.com.fr.Firefox защищает от этого, поддерживая список TLD: http://securitylabs.websense.com/content/Blogs/3108.aspx

Очевидно, Internet Explorer не разрешает двухбуквенным доменам устанавливать файлы cookie, что, я полагаю, объясняет, почему o2.ie просто перенаправляет на o2online.ie.Я часто задавался этим вопросом.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top