Як працюють домени файлів cookie браузера?

Через дивні проблеми з файлами cookie домену / субдоменів, я хотів би знати, як браузери обробляють файли cookie. Якщо вони роблять це по-різному, також непогано було б знати відмінності.

Іншими словами - коли веб-переглядач отримує файли cookie, МОЖЕ мати домен і шлях до нього. Або ні, у такому випадку браузер, ймовірно, замінює деякі параметри за замовчуванням. Питання 1: що вони?

Пізніше, коли браузер збирається зробити запит, він перевіряє файли cookie та фільтрує ті, які він повинен надіслати для цього запиту. Це робиться шляхом зіставлення їх з доступом до запиту та домену. Питання 2: які правила узгодження?

Причину, про яку я прошу, це те, що мене цікавлять деякі крайні випадки. Подібно до:

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

Додано 2:

Також хтось може підказати, як мені встановити печиво, щоб:

• Його можна встановити будь-яким www.example.comабо example.com;
• Він доступний www.example.comі example.com.

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

Існує відмінність між значенням атрибута Domain і ефективним доменом: перший береться з Set-Cookieполя заголовка, а другий - інтерпретація цього значення атрибута. Відповідно до RFC 2965, слід застосовувати наступне:

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

Маючи ефективний домен, він також повинен відповідати поточному запитуваному домену для встановлення; інакше файл cookie буде переглянуто. Це ж правило діє і для вибору файлів cookie, що надсилаються у запиті.

Складаючи ці знання на свої запитання, слід застосувати наступне:

• Файл cookie з Domain=.example.com буде доступний на веб-сайті www.example.com
• Файл cookie з Domain=.example.com буде доступний для example.com
• Файл cookie з Domain=example.comбуде перетворено на, .example.comі, таким чином , також буде доступний для www.example.com
• Cookie з Domain=example.comбуде НЕ доступний для anotherexample.com
• www.example.com буде мати можливість встановити печиво для example.com
• www.example.com буде НЕ бути в змозі встановити куки для www2.example.com
• www.example.com буде НЕ бути в змозі встановити куки для .com

І щоб встановити та прочитати файл cookie для / від 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:

• Домен походження з печива є областю запиту ініціюючого.

• Якщо початковий домен - це IP, атрибут домену файлу cookie не повинен встановлюватися.

• Якщо атрибут домену cookie не встановлений, файл cookie застосовується лише до його початкового домену.

• Якщо встановлено атрибут домену cookie,

  • файл cookie застосовний до цього домену та всіх його субдоменів;
  • домен файлу cookie повинен бути таким самим, як і батьківський, початкового домену
  • домен файлу cookie не повинен бути TLD, загальнодоступним суфіксом або батьківським відкритим суфіксом.

Звідси можна встановити, що файл cookie завжди застосовний до його початкового домену.

У домені cookie не повинно бути провідної точки, як у .foo.comпростому використанніfoo.com

Як приклад,

• x.y.z.comможна задати домен куки для себе або батьків - x.y.z.com, y.z.com, z.com. Але ні com, що є загальнодоступним суфіксом.
• печиво з доменом = 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-адресі, з якої надійшло набір Cookie.

Правила відповідності домену вимагають, щоб домен файлу cookie відповідав хосту, до якого робиться запит. Файл cookie може вказати ширшу відповідність домену, включивши *. в атрибуті домену Set-Cookie (ця область, для якої браузери можуть відрізнятися). Узгодження контуру (якщо припустити, що збігається домен) є простим питанням, що запитуваний шлях повинен знаходитися всередині шляху, визначеного в файлі cookie. Зазвичай файли cookie сеансу встановлюються шляхом path = / або path = / applicationName /, тому файл cookie доступний для всіх запитів у програмі.

• Чи буде cookie для .example.com доступним для www.example.com? Так
• Чи буде cookie для .example.com доступний для example.com? Не знаю
• Чи буде cookie for example.com доступним для www.example.com? Не повинен, але ... *
• Чи буде cookie for example.com доступним для anotherexample.com? Ні
• Чи зможе www.example.com встановити cookie для example.com? Так
• Чи зможе www.example.com встановити файл cookie для www2.example.com? Ні (за винятком .example.com)
• Чи зможе www.example.com встановити cookie для .com? Ні (Неможливо встановити файл cookie на такому високому просторі імен, а також не можна встановити його для чогось типу .co.uk) .

*Я не можу перевірити це зараз, але у мене є наголос, що принаймні IE7 / 6 буде ставитись до шляху так, example.comяк ніби він був .example.com.

Останнім (третім, точно) RFC для цього випуску є RFC-6265 (застарілий RFC-2965, що в свою чергу застаріває RFC-2109).

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

Коли атрибут Domain буде визначено, він буде розглядатися як повне ім'я домену (якщо в атрибуті є провідна крапка, він буде ігноруватися). Сервер повинен відповідати домену, вказаному в атрибуті (мати точно те саме ім’я домену або бути його субдоменом), щоб отримати це cookie. Більш точно це вказано тут .

Так, наприклад:

• атрибут cookie Domain=.example.comеквівалентнийDomain=example.com
• файли cookie з такими атрибутами домену будуть доступні для example.com та www.example.com
• файли cookie з такими атрибутами домену не будуть доступні для веб-сайту other-example.com
• Вказавши атрибут cookie, як, наприклад Domain=www.example.com, закриє шлях для www4.example.com

PS: кома в кінці в атрибуті Домен призведе до того, що агент користувача ігнорує атрибут = (

Я перевірив усі випадки в останніх Chrome, Firefox, Safari в 2019 році.

Відповідь додано:

• Чи буде cookie для .example.com доступним для www.example.com? ТАК
• Чи буде cookie для .example.com доступний для example.com? ТАК
• Чи буде cookie for example.com доступним для www.example.com? НЕТ , Домен без підстановки відповідає лише собі.
• Чи буде cookie for 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 для .com? НІ

Відомо, що RFC не відображають реальність.

Краще перевірити проект cookie-ietf-httpstate-cookie .

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

Потім є правила, які визначають, чи надсилатиме браузер cookie разом із запитом на сторінку.

Існують відмінності між основними двигунами браузера в тому, як обробляються збіги доменів і як інтерпретуються параметри значень шляху. Ви можете знайти деякі емпіричні докази в статті Як різні браузери по-різному поводжуються з файлами cookie

Я здивовано прочитав розділ 3.3.2 про відхилення файлів cookie:

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

Це говорить про те, що браузер повинен відхиляти файл cookie від xyzcom з доменом .z.com, оскільки "xy" містить крапку. Отже, якщо я неправильно трактую RFC та / або вищезазначені питання, можуть бути додані питання:

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

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

Чи 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. Я часто це замислювався.