Обмен cookie между поддоменом и доменом

У меня два вопроса. Я понимаю, что если я указываю домен как .mydomain.com(с ведущей точкой) в куки, то все субдомены могут совместно использовать куки.

Может ли subdomain.mydomain.comполучить доступ к cookie, созданному в mydomain.com(без wwwсубдомена)?

Может ли mydomain.com(без wwwсубдомена) получить доступ к cookie, если он создан в subdomain.mydomain.com?

2 домена mydomain.comи subdomain.mydomain.comмогут совместно использовать куки, если домен явно указан в Set-Cookieзаголовке. В противном случае область действия cookie ограничивается узлом запроса. (Это называется «cookie только для хоста». См. Что такое cookie только для хоста? )

Например, если вы отправили следующий заголовок из subdomain.mydomain.com, тогда cookie не будет отправляться для запросов mydomain.com:

Set-Cookie: name=value

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

Set-Cookie: name=value; domain=mydomain.com

Этот файл cookie будет отправлен для любого субдомена mydomain.com, включая вложенные субдомены, например subsub.subdomain.mydomain.com.

В RFC 2109 домен без ведущей точки означал, что его нельзя использовать на поддоменах, и только начальная точка ( .mydomain.com) позволяла бы его использовать в нескольких поддоменах (но не в домене верхнего уровня, так что вы спросили: невозможно в старшей спецификации).

Однако все современные браузеры уважают более новую спецификацию RFC 6265 и будут игнорировать любую начальную точку, что означает, что вы можете использовать cookie на поддоменах, а также доменах верхнего уровня.

Таким образом, если вы установите cookie, как во втором примере выше mydomain.com, он будет доступен subdomain.mydomain.com, и наоборот. Это также может быть использовано для разрешения sub1.mydomain.comи sub2.mydomain.comобмена файлами cookie.

Смотрите также:

• www против no-www и печенье
• тестовый скрипт cookie, чтобы попробовать его

Я не уверен, что ответ @cmbuckley показывает полную картину. Я читаю это:

Если атрибуты cookie не указывают на иное, cookie возвращается только исходному серверу (а не, например, каким-либо поддоменам), и срок его действия истекает в конце текущего сеанса (как определено агентом пользователя). Пользовательские агенты игнорируют нераспознанные куки.

RFC 6265

Также

8.6.  Weak Integrity

   Cookies do not provide integrity guarantees for sibling domains (and
   their subdomains).  For example, consider foo.example.com and
   bar.example.com.  The foo.example.com server can set a cookie with a
   Domain attribute of "example.com" (possibly overwriting an existing
   "example.com" cookie set by bar.example.com), and the user agent will
   include that cookie in HTTP requests to bar.example.com.  In the
   worst case, bar.example.com will be unable to distinguish this cookie
   from a cookie it set itself.  The foo.example.com server might be
   able to leverage this ability to mount an attack against
   bar.example.com.

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

Потрясающий тестовый сайт cookie, предоставленный @cmbuckley / для тех, кто пропустил его в своем ответе, как я; стоит прокрутить вверх и вверх /:

• http://scripts.cmbuckley.co.uk/cookies.php

Вот пример использования API cookie DOM ( https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie ), поэтому мы можем сами убедиться в этом.

Если мы выполним следующий JavaScript:

document.cookie = "ключ = значение"

Это похоже на выполнение:

document.cookie = "ключ = значение; домен = mydomain.com"

Ключ cookie становится доступным (только) на домене mydomain.com .

Теперь, если вы выполните следующий JavaScript на mydomain.com:

document.cookie = "ключ = значение; домен = .mydomain.com"

Ключ cookie становится доступным для mydomain.com, а также subdomain.mydomain.com .

Наконец, если вы попытаетесь выполнить на subdomain.mydomain.com следующее:

document.cookie = "ключ = значение; домен = .mydomain.com"

Ключ cookie становится доступным для subdomain.mydomain.com ? Я был немного удивлен, что это разрешено; Я предполагал, что для субдомена будет нарушением безопасности возможность установки файла cookie в родительском домене.

Пожалуйста, обратите внимание, что вы можете установить cookie с субдомена в домене.

(отправлено в ответе на запрос subdomain.mydomain.com)

Set-Cookie: name=value; Domain=mydomain.com // GOOD

Но вы НЕ МОЖЕТЕ установить cookie из домена на поддомене.

(отправлено в ответе на запрос mydomain.com)

Set-Cookie: name=value; Domain=subdomain.mydomain.com // Browser rejects cookie

ПОЧЕМУ ?

Согласно спецификации RFC 6265 раздел 5.3.6 Модель хранения

Если канонизированный хост-запрос не соответствует домену-атрибуту домена: полностью проигнорируйте файл cookie и прервите эти шаги.

и RFC 6265, раздел 5.1.3.

Соответствие доменов

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

1. Строка домена и строка идентичны. (Обратите внимание, что и строка домена, и строка будут канонизированы в нижний регистр на этом этапе.)

2. Выполнены все следующие условия:

   • Строка домена является суффиксом строки.

   • Последний символ строки, который не включен в строку домена, является символом% x2E (".").

   • Строка является именем хоста (т. Е. Не IP-адресом).

Таким образом, домен «subdomain.mydomain.com» соответствует «mydomain.com», но «mydomain.com» НЕ соответствует домену «subdomain.mydomain.com»

Проверьте этот ответ также.

В обоих случаях да, это может, и это поведение по умолчанию для IE и Edge.

Другие ответы добавляют ценную информацию, но в основном описывают поведение в Chrome. Важно отметить, что в IE поведение совершенно иное. Очень полезный тестовый скрипт CMBuckley демонстрирует, что в (скажем) Chrome файлы cookie не распределяются между корнем и поддоменами, когда домен не указан. Однако тот же тест в IE показывает, что они являются общими. Этот случай IE ближе к описанию возврата домой в ссылке CMBuckley www-or-not-www. Я знаю, что это так, потому что у нас есть система, которая использует разные файлы cookie стека служб как в корневом, так и в поддомене. Все работало нормально, пока кто-то не получил к нему доступ в IE, и две системы боролись за то, чья сессионная cookie победит, пока мы не взорвем кэш.

Будьте осторожны, если вы работаете на localhost! Если вы сохраните свой файл cookie в js, как это:

document.cookie = "key=value;domain=localhost"

Это может быть недоступно для вашего субдомена, как sub.localhost. Для решения этой проблемы вам нужно использовать виртуальный хост . Например, вы можете настроить свой виртуальный хост, ServerName localhost.comпосле чего вы сможете хранить куки в своем домене и субдомене следующим образом:

document.cookie = "key=value;domain=localhost.com"

Простое решение

setcookie("NAME", "VALUE", time()+3600, '/', EXAMPLE.COM);

Пятый параметр Setcookie определяет (под) домены, для которых доступен файл cookie. Установка его в (EXAMPLE.COM) делает его доступным для любого субдомена (например: SUBDOMAIN.EXAMPLE.COM)

Ссылка: http://php.net/manual/en/function.setcookie.php