Может ли 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, вы читаете:

       * Set-Cookie от запроса-хоста x.foo.com для домена = .foo.com будет
         быть принятым.

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

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

       Выбор домена
            Полное имя хоста исходного сервера должно соответствовать домену
            Доменный атрибут куки

Так у нас есть совпадение доменов?

   * A является строкой полного доменного имени и имеет форму 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's nsCookieService.cpp

а также

Chrome's cookie_monster.cc

Для перспективы в то , что фактические сайты делают, пытаются играть с wgetпомощью --save-cookies, --load-cookiesи --debugпосмотреть , что происходит.

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

— медина
источник

Так как же www.example.com и example.com (которые обычно указывают на один и тот же сайт) используют одни и те же файлы cookie? Ведущий. не требуется в большинстве браузеров, иначе это общее использование не будет работать.

— Джеймс Райан

Ведущая точка поддерживается только последними RFC. example.com может установить куки для «example.com» и «.example.com»; последний может быть прочитан www.example.com. Используйте показанные команды wget, чтобы увидеть, что происходит.

— Медина

@medina, может ли пользователь установить куки на 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-файлы (особенно то, как они будут отправлены обратно на любой веб-сайт). В модели также есть правило, что «браузеры не отправляют куки на доменные имена, которые их не устанавливают».

При этом домен domain.com должен иметь возможность устанавливать файлы cookie для js.domain.com. Однако js.domain.com может устанавливать файлы cookie только для себя. Но это все зависит от того, какой браузер вы используете.

— Тони
источник