Чи може subdomain.example.com встановити файл cookie, який може читати example.com?

Я просто не можу повірити, що це досить важко визначити.

Навіть прочитавши RFC, мені незрозуміло, чи може сервер на сайті subdomain.example.com встановити файл cookie, який може читати example.com.

subdomain.example.com може встановити файл cookie, атрибутом якого є домен .example.com. RFC 2965, схоже, прямо вказує, що такий файл cookie не надсилатиметься на сторінку example.com, але потім однаково говорить, що якщо ви встановите Domain = example.com, крапка буде попередньою, як якщо б ви сказали .example.com. У сукупності це, здається, говорить про те, що якщо повернення example.com встановлює файл cookie з Domain = example.com, він не повертає цей файл cookie! Це не може бути правильним.

Хто-небудь може уточнити, які правила насправді є?

http cookies subdomain

— Еван Плейс
джерело

Це питання мало бути закритим / перенесеним назад, коли його задали, але оскільки він привернув багато уваги, я збираюся його заблокувати, а не закривати. Дивіться stackoverflow.com/questions/3089199/… про дупу, на правильному сайті.

— Кріс Ш

Відповіді:

Цитуючи з того самого RFC2109, який ви читали:

       * Буде встановлено cookie від запиту-хоста x.foo.com для Domain = .foo.com
         бути прийнятим.

Так subdomain.example.comможна встановити файл cookie для .example.com. Все йде нормально.

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

       Вибір домену
            Повнокваліфіковане ім’я хоста-сервера повинно відповідати домену
            атрибут домену файлу cookie

То ми маємо збіг домену?

   * A - рядок FQDN і має вигляд NB, де N - не порожнє ім'я
     рядок, B має вигляд .B ', а B' - рядок FQDN. (Отже, xycom
     .y.com, але не y.com.)

Але тепер example.comне буде відповідати домену .example.comвідповідно до визначення. Але www.example.com(або будь-яке інше "не порожнє ім'я" в домені) буде. Цей RFC теоретично застарів RFC2965 , який диктував речі щодо примушування провідної точки для доменів в Set-Cookie2операціях.

Більш важливим, як зазначає @Tony, є реальний світ. Щоб ознайомитися з тим, що роблять фактичні користувацькі агенти, див

Firefox 3 nsCookieService.cpp

Cookie_monster.cc Chrome

Для перспективи в те , що фактичні сайти роблять, намагаються грати з wgetдопомогою --save-cookies, --load-cookiesі --debugподивитися , що відбувається.

Ви, ймовірно, виявите, що насправді більшість сайтів використовують деяку комбінацію Set-Cookieстарих специфікацій RFC зі значеннями "Host", неявно без провідної точки (як це робить twitter.com ) або встановлення значень домену (з провідною крапкою) та перенаправлення на такий сервер www.example.com(як це робить google.com ).

— медіна
джерело

тож як www.example.com та example.com (які зазвичай вказують на один і той же сайт) використовують однакові файли cookie? Провідні. не може бути потрібним у більшості браузерів, інакше це звичайне використання не працює.

— JamesRyan

Провідну крапку вимушує лише новіший RFC. example.com може встановити файли cookie для "example.com" та ".example.com"; останню можна прочитати на www.example.com. Використовуйте показані команди wget, щоб побачити, що відбувається.

— медіна

@medina, Чи може користувач встановити файли cookie на x1.yz та прочитати їх на x2.yz ?

— Pacerier

@Pacerier Тільки якщо (1) ви встановите cookie для y.z(2) користувальницький агент реалізує RFC 6265.

— Майкл Хемптон

@MichaelHampton, чи не переглядають браузери RFC 6265?

— Pacerier

Якщо веб-переглядач реалізує RFC 6265 , який повинен робити будь-який сучасний веб-переглядач, то набір файлів cookie .example.comбуде проігноровано провідною крапкою (розділ 5.2.3), а файл cookie буде надісланий до голого домену та всім субдоменів.

Не покладайтеся на таку поведінку, якщо у вас є значний трафік із старих браузерів; ця RFC датується лише 2011 роком.

— Майкл Хемптон
джерело

Це не повинно бути можливим. Однак, як ви сказали, оскільки це не є широко документально підтвердженим стандартом, це залежить від того, який саме програмний продукт ви використовуєте.

Більшість сучасних браузерів дотримуються визначеної "моделі веб-безпеки". Ця модель ефективно керує поведінкою браузерів щодо безпеки щодо таких речей, як файли cookie (зокрема, як вони будуть відправлені назад на будь-який веб-сайт). Модель також має правило, що "браузери не надсилають файли cookie на доменні імена, які їх не встановлювали".

Зважаючи на це, domain.com повинен мати можливість встановлювати файли cookie для js.domain.com. Однак, js.domain.com може встановлювати файли cookie лише для себе. Але все це залежить від того, який браузер ви використовуєте.

— Тоні
джерело