什么时候适合在您的域上使用非 HttpOnly cookie？

Posted 2023-03-07

【中文标题】什么时候适合在您的域上使用非 HttpOnly cookie？

【英文标题】：When is it appropriate to have non-HttpOnly cookies on your domain?

【发布时间】：2014-04-24 04:05:06

【问题描述】：

我已阅读 OWASP information 以及一系列文章，包括 Jeff Atwood 的 Protecting Your Cookies 文章，但我仍然觉得我需要更好地了解 HttpOnly cookie。

这是因为我需要向网站添加一些 Google Adword tracking code。这个 javascript 需要设置和读取网站域上的 cookie，我认为这是一个问题。该网站是一个 .Net 应用程序，在 web.config 中有 httpOnlyCookies="true"，所以我认为最好的方法是替换 javascript 并从后端写入 cookie，以确保生成的 cookie 是 HttpOnly。然后我也可以轻松地在服务器端读取 cookie。

我了解设置 cookie 属性的 HttpOnly 可以在很大程度上防止 cookie 被客户端读取和操作。但我不明白的是：

鉴于上面的例子，我使用 javascript 实现会不会有问题？ 是否仍然可以使用 javascript 编写 cookie（但仍使用服务器端读取它）？我不认为 cookie 不是 HttpOnly cookie 如果我做对了（将所有内容移至服务器端实现），为什么 Google Analytic cookie 总是作为非 HttpOnly cookie 实现？他们肯定也构成安全问题吗？

正如标题所说，我想我要问的是 - 什么时候（如果有的话）在您的域上使用非 HttpOnly cookie 是合适的？

【问题讨论】：

保留不安全信息的 Cookie（例如，记住上次使用的浏览器窗口大小的 Cookie）实际上不是安全问题。谁在乎信息是否泄露？

任何时候你想要 JavaScript 能够读取cookie，你需要它不是HttpOnly。例如，您不想使用经过身份验证的会话密钥来执行此操作。

@mah 是的，这很明显 :) 问题是什么时候适合使用非 HttpOnly cookie？如果我可以在服务器端处理我所有的 cookie 实现，我应该吗？还是矫枉过正？如果是，为什么？

要回答这个问题，您必须首先考虑 cookie 的用途。如果它与用户对某些内容的显示方式的偏好有关，那么 JavaScript 处理可能是一个更好的解决方案。相反，如果它是关于显示什么数据的用户偏好（可能过滤掉数据），那么服务器端解决方案可能会更好（限制带宽），但 HttpOnly 可能并不重要（因为没有安全后果——或者不应该） . HttpOnly 实际上只对安全敏感的事情是必需的。

因此对于包含非敏感信息的 任何 cookie，可以忽略 HttpOnly 要求。就这么简单？

【参考方案1】：

所以这比我想象的要简单得多。根据上面@mah留下的cmets，当cookie包含非敏感信息时，将cookie标记为HttpOnly是多余的。

【参考方案2】：

httpOnly 选项是对窃取用户会话 cookie 的 JavaScript 技巧的响应。这是因为会话 cookie 是一个临时凭证，允许您访问用户在服务器上的登录会话。

如果是任何其他非会话 cookie，这实际上取决于您自己的风险评估。如果您并不真正担心在没有 httpOnly 的情况下会稍微增加曝光率，或者您只是有业务需要从 JavaScript 访问它们的值，请忽略此选项。

一些安全扫描程序或不称职的渗透测试团队会报告每个 cookie 缺少 httpOnly 标志，因为这很容易发现，并且允许他们轻松夸大他们的报告。但是解释httpOnly的实际目的和来源应该足以反驳。