http - cookie 的域属性是否发送回服务器？

Question

如果 evil.example.com 设置一个域属性设置为 .example.com 的 cookie，浏览器将在对 foo.example.com 的请求中包含此 cookie。

The Tangled Web请注意，对于 foo.example.com，此类 cookie 与 foo.example.com 设置的 cookie 基本上没有区别。但是根据the RFC , cookie 的域属性应该发送到服务器，这将使 foo.example.com 能够区分并拒绝由 evil.example.com 设置的 cookie。

当前浏览器实现的状态如何？域是否与 cookie 一起发回？

Answer 1

RFC 2109 和 RFC 2965 是标准化 cookie 处理的历史尝试。不幸的是，它们与浏览器的实际操作毫无相似之处，应该完全忽略。

真实世界的行为主要是由原始的 Netscape cookie_spec 定义的，但作为一个规范，这是非常有缺陷的，这导致了一系列浏览器差异，大约 -

• 接受什么日期格式；
• 如何处理多个匹配的同名cookie；
• 非 ASCII 字符如何工作(或不工作)；
• 引用/转义；
• 域匹配是如何完成的。

RFC 6265 试图清理这个烂摊子，并明确规定浏览器应该做什么。它没有说浏览器应该发送 domain 或 path，因为历史上没有浏览器这样做过。

因为您无法检测到 cookie 来自父域(*)，所以如果您想将 cookie 分开，则必须注意主机名以避免域重叠 - 在特别是对于 IE，即使您不设置 domain，在 example.com 上设置的 cookie 也将始终继承到 foo.example.com.

因此:如果您认为将来可能需要一个带有单独 cookie 的子域(不应该能够从其父级读取敏感 cookie)，请不要为您的站点使用“无 www”主机名；如果您真的需要一个完全独立的 cookie 上下文，以防止 evil.example.com 将 cookie 值注入(inject)其他 example.com 站点，那么您别无选择，只能使用完全独立的域名。

一种可能对某些攻击模型有效的替代方法是对您生成的每个 cookie 值进行签名，例如使用 HMAC .

*:有一种方法。尝试删除与您想要的 cookie 具有相同域 和路径 设置的 cookie。如果 cookie 在您这样做时消失了，那么它一定有那些 domain 和 path 设置，所以原来的 cookie 没问题。如果那里仍然有 cookie，则它来自其他地方，您可以忽略它。如果没有 JavaScript，这样做很不方便、不切实际，而且也不是无懈可击的，因为原则上攻击者可能会同时删除他们注入(inject)的 cookie。