如果 evil.example.com 设置了一个域属性设置为 .example.com 的 cookie，浏览器将在对 foo.example.com 的请求中包含此 cookie。
The Tangled Web指出，对于 foo.example.com，此类 cookie 在很大程度上与 foo.example.com 设置的 cookie 没有区别。但是根据RFC，cookie 的域属性应该被发送到服务器，这将使 foo.example.com 可以区分和拒绝由 evil.example.com 设置的 cookie。
当前浏览器实现的状态是什么？域是否与 cookie 一起发回？
RFC 2109 和 RFC 2965 是标准化 cookie 处理的历史尝试。不幸的是，它们与浏览器实际所做的没有相似之处，应该完全忽略。
真实世界的行为主要是由最初的 Netscape cookie_spec 定义的，但这作为一个规范是非常有缺陷的，这导致了一系列浏览器的差异，大约 -
RFC 6265 试图清理这些混乱并明确规定浏览器应该做什么。它并没有说浏览器应该发送domainor path，因为历史上没有浏览器这样做过。
因为您无法检测到 cookie 来自父级domain(*)，所以如果您想将 cookie 分开，您必须注意主机名以避免重叠域 - 特别是对于 IE，即使您不这样做set domain，设置的 cookieexample.com将始终继承到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:标题。浏览器只发送 cookiename=value对，而不是域等属性。有关此标头的规范，请参阅 RFC 的第 4.2 节。此外，请参阅第 8.6 节，弱完整性，其中讨论了 foo.example.com 可以为 .example.com 设置 cookie 的事实，而 bar.example.com 将无法判断它不是它设置的 cookie本身。
我会相信 Zalewski 的书和他的https://code.google.com/p/browsersec/wiki/Main超过任何 RFC。浏览器对许多 HTTP 特性的实现是出了名的混乱和不标准。