如果 evil.example.com 设置了域属性设置为 .example.com 的 cookie，浏览器将在对 foo.example.com 的请求中包含此 cookie。
The Tangled Web 指出，对于 foo.example.com，此类 cookie 在很大程度上与 foo.example.com 设置的 cookie 没有区别。但是根据the RFC，cookie 的 domain 属性应该发送到服务器，这样 foo.example.com 就可以区分和拒绝由 evil.example.com 设置的 cookie。
当前浏览器实现的状态如何？域是否与 cookie 一起发回？
【问题讨论】：
标签： http cookies browser security
我会相信 Zalewski 的书和他的 https://code.google.com/p/browsersec/wiki/Main 超过任何 RFC。浏览器对许多 HTTP 功能的实现是出了名的混乱和不标准。
【讨论】：
RFC 2109 和 RFC 2965 是标准化 cookie 处理的历史尝试。不幸的是，它们与浏览器的实际功能完全不同，应该完全忽略。
真实世界的行为主要是由最初的 Netscape cookie_spec 定义的，但作为一个规范，这是非常有缺陷的，这导致了一系列浏览器的差异，大约 -
RFC 6265 试图清理这些混乱并明确规定浏览器的目标是做什么。它并没有说浏览器应该发送domain 或path，因为历史上没有浏览器这样做过。
由于您无法检测到 cookie 来自父 domain(*)，因此如果您希望将 cookie 分开，则必须注意主机名以避免域重叠 - 特别是对于 IE，其中即使您没有设置domain，在example.com 上设置的cookie 也将始终继承到foo.example.com。
所以：如果您认为将来可能想要一个带有单独 cookie 的子域（不应该能够从其父级读取敏感 cookie），请不要为您的站点使用“无 www”主机名；如果您确实需要一个完全独立的 cookie 上下文，以防止 evil.example.com 将 cookie 值注入其他 example.com 站点，那么您别无选择，只能使用完全独立的域名。
可能对某些攻击模型有效的替代方法是对您生成的每个 cookie 值进行签名，例如使用 HMAC。
*：有一种方法。尝试删除与您想要的 cookie 具有相同 domain 和 path 设置的 cookie。如果这样做时 cookie 消失了，那么它一定有 domain 和 path 设置，所以原始 cookie 是可以的。如果那里还有一个 cookie，它来自其他地方，你可以忽略它。如果没有 JavaScript，这样做很不方便、不切实际，而且也不是无懈可击的，因为原则上攻击者可能会同时删除他们注入的 cookie。
【讨论】：
Cookie 的当前标准是RFC 6265。此版本简化了Cookie: 标头。浏览器只发送 cookie name=value 对，而不是像域这样的属性。有关此标头的规范，请参阅 RFC 的第 4.2 节。此外，请参阅第 8.6 节，弱完整性，其中讨论了 foo.example.com 可以为 .example.com 设置 cookie，而 bar.example.com 无法分辨的事实它不是它自己设置的cookie。
【讨论】：
$_COOKIE 变量只包含名称和值，不包含属性。