概括。是的，这是可能的。这不是浏览器错误。它是 cookie 设计功能的一部分。没有浏览器可以避免这种情况。Cookie 是一种古老的技术，它们的安全模型只是松散地与网络的其他部分集成在一起。细节混乱而丑陋。

血淋淋的细节

该站点可以使用范围或范围blog.example.com设置 cookie 。如果用户访问，后一种范围的 cookie 将被发送回。blog.example.comexample.comsecure.example.comsecure.example.com

如果站点secure.example.com设置了 cookie 的范围example.com，那么站点blog.example.com可以任意覆盖该 cookie。每当浏览器看到与 cookie jar 中已有的具有相同名称和范围的 cookie 时，它​​们就会丢弃旧的 cookie 值并用新的 cookie 覆盖它。因此，blog.example.com可以覆盖任何范围为example.com.

更糟糕的是，一个 cookie 可以用另一个范围覆盖一个 cookie。假设secure.example.com设置一个带有 scopesecure.example.com和 name的 cookie SESSIONID。接下来假设blog.example.com设置一个具有范围example.com和相同名称的 cookie。最后，假设用户访问该站点secure.example.com。怎么了？这很丑陋：浏览器以某种未定义的顺序发送两个 cookie，而服务器没有可靠的方法来判断哪个 cookie 值来自哪个站点。因此，服务器可以检测到它处于混乱状态，但没有很好的方法来解开自己。更糟糕的是，一些 Web 应用程序框架可能会隐藏应用程序代码的混淆，使用其中一个 cookie 值并默默地忽略另一个。这可能会导致某些行为有效，例如blog.example.com从secure.example.com，在没有人合理预期它可能能够做到的情况下。

（附带说明，该secure标志并不能防止 cookie 被覆盖。事实上，HTTP 站点可以使用secure标志覆盖 cookie ，只要域名相关适当。该secure标志提供机密性保护，但不提供完整性保护.)

最后，还有另一种删除 cookie 的方法：恶意站点可以设置大量 cookie，超出浏览器将存储的 cookie 数量的固定限制。结果是浏览器“忘记”了来自其他站点的旧 cookie。这允许blog.example.com删除所有由设置的 cookie secure.example.com（不管它们的范围），然后设置一个新的 cookie，其范围example.com将被发送回secure.example.com——这与覆盖现有 cookie 的效果大致相同。这可能是您在提到“cookie jar overflow”时所想到的。

讨论

很乱。遗憾的是，这就是 cookie 在 Internet 上的工作方式。如果要避免，最简单的防御方法是为不受信任的站点使用新的二级域。可能有更好的防御方法不限制您的站点的命名，但我不知道它是什么。

作为一般说明，对于此类有关 Web 工作原理的问题，我强烈推荐浏览器安全手册。它挤满了金块。在这种情况下，您可能需要阅读其关于cookie 的同源策略的材料。