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的domain属性应该发送到服务器，这样foo.example.com就可以区分并拒绝evil.example.com设置的cookie。 / p>

当前浏览器实施的状态是什么？域名是否通过cookie发回？

Answer 1

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

真实世界的行为主要是由最初的Netscape cookie_spec定义的，但这作为一个规范非常不足，导致了一系列的浏览器差异 -

• 接受的日期格式;
• 多个匹配时如何处理具有相同名称的Cookie;
• 非ASCII字符如何工作（或不工作）;
• 引用/逃逸;
• 如何完成域匹配。

RFC 6265试图清理这些混乱，并明确地编写浏览器应该做的目标。它并不是说浏览器应该发送domain或path，因为历史记录中没有浏览器曾经这样做过。

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

所以：如果您认为将来可能想要一个具有单独cookie的子域名（不应该从其父级读取敏感的cookie），请不要为您的站点使用“no-www”主机名;如果你确实需要一个完全独立的cookie上下文，为了防止evil.example.com将cookie值注入其他example.com站点，那么你别无选择，只能使用完全独立的域名。

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

*：有一种方法。尝试使用与所需Cookie相同的domain和path设置删除 Cookie。如果cookie在您执行此操作时消失，那么它必须具有domain和path设置，因此原始Cookie可以正常运行。如果那里还有一个cookie，它来自其他地方你可以忽略它。这是不方便的，没有JavaScript是不切实际的，也不是不漏水的，因为原则上攻击者可能会同时删除他们注入的cookie。

Answer 2

目前的Cookie标准是RFC 6265。此版本简化了Cookie:标头。浏览器只发送cookie name=value对，而不是域名等属性。有关此标头的规范，请参见RFC的4.2节。此外，请参阅第8.6节弱完整性，其中讨论了foo.example.com可以为.example.com设置Cookie的事实，而bar.example.com将无法分辨这不是它自己设定的cookie。

Answer 3

我会相信Zalewski的书和他https://code.google.com/p/browsersec/wiki/Main的任何RFC。浏览器对许多HTTP功能的实现是众所周知的混乱和非标准。