Поділитися файлами cookie між субдоменом та доменом

У мене два питання. Я розумію, що якщо я вказати домен як .mydomain.com(з провідною крапкою) у файлі cookie, всі купони можуть мати спільний домен .

Чи можете subdomain.mydomain.comотримати доступ до файлу cookie, створеного в mydomain.com(без wwwсубдомену)?

Чи можете mydomain.com(без wwwсубдомену) отримати доступ до файлів cookie, якщо вони створені в subdomain.mydomain.com?

Два домени mydomain.comі subdomain.mydomain.comможуть спільно використовувати файли cookie лише у тому випадку, коли домен явно вказаний у Set-Cookieзаголовку. В іншому випадку область cookie обмежена хостом запиту. (Це позначається як "cookie-only 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 vs no-www та файли cookie
• тестовий сценарій cookie, щоб випробувати його

Я не впевнений, що відповідь @cmbuckley показує повну картину. Що я читаю:

Якщо в атрибутах cookie не вказано інше, файл 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 в інші домени. Тож хтось може переписати файли 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 Узгодження домену

Збіг домену

Рядок домену відповідає даній рядку домену, якщо виконується принаймні одне з наступних умов:

1. Рядок домену та рядок однакові. (Зверніть увагу, що і доменний рядок, і рядок у цій точці будуть утворені в нижній регістр.)

2. Виконано всі наведені нижче умови:

   • Рядок домену - це суфікс рядка.

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

   • Рядок - це ім'я хоста (тобто не IP-адреса).

Отже, "subdomain.mydomain.com" домен відповідає "mydomain.com", але "mydomain.com" НЕ відповідає домену "subdomain.mydomain.com"

Перевірте і цю відповідь .

В обох випадках так можна, і це поведінка за замовчуванням як для IE, так і для Edge.

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

Будьте уважні, якщо ви працюєте на localhost! Якщо ви зберігаєте файл cookie у js, як це:

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

Це може бути недоступним для вашого субдомену, наприклад sub.localhost. Для вирішення цього питання потрібно скористатися Віртуальним хостом . Наприклад, ви можете налаштувати свій віртуальний хост, ServerName localhost.comтоді ви зможете зберігати файли cookie у вашому домені та субдомені так:

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