HttpOnly cookie 如何与 AJAX 请求配合使用？

Question

如果在基于 cookie 的访问限制的站点上使用 AJAX，则 JavaScript 需要访问 cookie。 HttpOnly cookies 能在 AJAX 网站上工作吗？

编辑 Microsoft 创建了一种防止 XSS 攻击的方法，如果指定了 HttpOnly，则不允许 JavaScript 访问 cookie。 FireFox后来采用了这一点。 所以我的问题是：如果您在 StackOverflow 等网站上使用 AJAX，是否可以选择 Http-Only cookie？

编辑2：问题2。如果HttpOnly的目的是阻止JavaScript访问cookie，并且您仍然可以通过XmlHttpRequest对象通过JavaScript检索cookie，HttpOnly的意义是什么< /强>？

编辑3：以下是维基百科的引用：

当浏览器收到这样的 cookie 时，它​​应该在接下来的 HTTP 交换中照常使用它，但不会使其对客户端脚本可见。[32] HttpOnly 标志不属于任何标准，并且并未在所有浏览器中实现。 请注意，当前无法阻止通过 XMLHTTPRequest 读取或写入会话 cookie。 [33]。

据我所知，当您使用 HttpOnly 时，document.cookie 会被阻止。 但似乎您仍然可以读取 XMLHttpRequest 对象中的 cookie 值，从而允许 XSS。 HttpOnly 如何让您更安全？ 通过使cookie本质上只读？

在您的示例中，我无法写入您的 document.cookie，但我仍然可以窃取您的 cookie 并使用 XMLHttpRequest 对象将其发布到我的域。

<script type="text/javascript">
    var req = null;
    try { req = new XMLHttpRequest(); } catch(e) {}
    if (!req) try { req = new ActiveXObject("Msxml2.XMLHTTP"); } catch(e) {}
    if (!req) try { req = new ActiveXObject("Microsoft.XMLHTTP"); } catch(e) {}
    req.open('GET', 'http://stackoverflow.com/', false);
    req.send(null);
    alert(req.getAllResponseHeaders());
</script>

编辑4：抱歉，我的意思是您可以将 XMLHttpRequest 发送到 StackOverflow 域，然后将 getAllResponseHeaders() 的结果保存到字符串中，用正则表达式输出 cookie，然后将其发布到外部领域。 看起来维基百科和 ha.ckers 都同意我的观点，但我很乐意接受再教育...

最终编辑：啊，显然两个网站都错了，这实际上是一个 FireFox 中的错误。 IE6和IE6 7 实际上是目前唯一完全支持 HttpOnly 的浏览器。

重申一下我所学到的一切：

• HttpOnly 限制 IE7 和 IE7 中对 document.cookie 的所有访问。 和 FireFox（不确定其他浏览器）
• HttpOnly 从 IE7 中的 XMLHttpObject.getAllResponseHeaders() 中的响应标头中删除 cookie 信息。
• XMLHttpObject 只能提交到它们源自的域，因此不存在 cookie 的跨域发布。

编辑：此信息可能不再是最新的。

Answer 1

澄清一下 - 从服务器的角度来看，AJAX 请求所请求的页面本质上与用户单击链接完成的标准 HTTP get 请求没有什么不同。 所有正常的请求属性：用户代理、ip、会话、cookies 等都会传递到服务器。

Answer 2

这还有一点。

Ajax 并不严格要求 cookie，但正如其他发帖者提到的那样，它们可能很有用。 将 cookie 标记为 HTTPOnly 以将其隐藏在脚本中只能部分起作用，因为并非所有浏览器都支持它，而且还因为有常见的解决方法。

奇怪的是 XMLHTTPresponse 标头提供了 cookie，从技术上讲，服务器不必随响应返回 cookie。 一旦在客户端上设置，它就会保持设置状态直到过期。 尽管有一些方案会根据每个请求更改 cookie，以防止重复使用。 因此，您可以通过更改服务器以不在 XMLHTTP 响应上提供 cookie 来避免这种解决方法。

但总的来说，我认为 HTTPOnly 应该谨慎使用。 存在跨站点脚本攻击，其中攻击者安排用户使用简单的发布表单（不使用 XMLHTTP）提交来自另一个站点的类似 ajax 的请求，并且浏览器的仍然活动的 cookie 将验证该请求。

如果您想确保 AJAX 请求经过身份验证，则请求本身和 HTTP 标头需要包含 cookie。 例如，通过使用脚本或独特的隐藏输入。 HTTPOnly 会阻碍这一点。

通常需要 HTTPOnly 的有趣原因是防止网页上包含的第三方内容窃取 cookie。 但有很多有趣的原因让我们对包含第三方内容持谨慎态度，并积极过滤它。

Answer 3

不一定，这取决于你想做什么。 你能详细说明一下吗？ AJAX 不需要访问 cookie 即可工作，它可以自行发出请求来提取信息，AJAX 调用发出的页面请求可以访问 cookie 数据和信息。 将其传递回调用脚本，无需 Javascript 直接访问 cookie

Answer 4

当您进行 AJAX 调用时，浏览器会自动处理 Cookie，因此您的 Javascript 无需处理 Cookie。

Answer 5

<块引用>

因此我假设 JavaScript 需要访问您的 cookie。

来自浏览器的所有 HTTP 请求都会传输相关站点的 cookie 信息。 JavaScript 既可以设置也可以读取cookie。 根据定义，Ajax 应用程序不需要 Cookie，但大多数 Web 应用程序都需要它们来维护用户状态。

对您的问题的正式回答是这样的：“如果使用 AJAX，JavaScript 是否需要访问 cookie？” - 因此是“不”。 例如，考虑使用 Ajax 请求来提供自动建议选项的增强搜索字段。 在这种情况下不需要 cookie 信息。

Answer 6

不，AJAX 调用请求的页面也可以访问 cookie 这就是检查您是否登录的方法。

您可以使用 Javascript 进行其他身份验证，但我不相信它，我总是更喜欢在后端进行任何类型的身份验证检查。

Answer 7

是的，cookie 对于 Ajax 非常有用。

将身份验证放在请求 URL 中是不好的做法。 上周有一篇关于从 google 缓存获取 URL 中的身份验证令牌的新闻。

不，没有办法阻止攻击。 较旧的浏览器仍然允许通过 JavaScript 对 cookie 进行简单的访问。 你可以只绕过http，等等。只要有足够的努力，无论你想出什么，都可以绕过。 诀窍是让太多的努力变得不值得。

如果您想让您的网站更加安全（没有完美的安全性），您可以使用过期的身份验证 cookie。 那么，如果cookie被盗，攻击者必须在它过期之前使用它。 如果他们不这样做，那么您就有一个很好的迹象表明该帐户存在可疑活动。 时间窗口越短，安全性越好，但生成和维护密钥的服务器的负载就越大。

Answer 8

是的，仅 HTTP cookie 就适合此功能。 它们仍然会收到对服务器的 XmlHttpRequest 请求。

对于 Stack Overflow，cookie 会作为 XmlHttpRequest 请求的一部分自动提供。 我不知道 Stack Overflow 身份验证提供程序的实现细节，但 cookie 数据可能会自动用于在比“投票”控制器方法更低的级别验证您的身份。

更一般地说，AJAX 不需要 cookie。 XmlHttpRequest 支持（甚至是旧版浏览器上的 iframe 远程处理）就是技术上所需的全部。

但是，如果您想为支持 AJAX 的功能提供安全性，则适用与传统站点相同的规则。 您需要某种方法来识别每个请求背后的用户，而 cookie 几乎总是达到此目的的手段。

在您的示例中，我无法写入您的 document.cookie，但我仍然可以窃取您的 cookie 并使用 XMLHttpRequest 对象将其发布到我的域。

XmlHttpRequest 不会发出跨域请求（正是出于您所提到的各种原因）。

您通常可以注入脚本以使用 iframe 远程处理或 JSONP 将 cookie 发送到您的域，但 HTTP-Only 会再次保护 cookie，因为它无法访问。

除非您在服务器端破坏了 StackOverflow.com，否则您将无法窃取我的 cookie。

编辑2：问题2。如果Http-Only的目的是防止JavaScript访问cookie，并且您仍然可以通过XmlHttpRequest对象通过JavaScript检索cookie，那么Http-Only的意义是什么？

考虑这种情况：

• 我找到了一种将 JavaScript 代码注入页面的途径。
• Jeff 加载页面，我的恶意 JavaScript 修改他的 cookie 以匹配我的。
• 杰夫对你的问题给出了出色的答案。
• 因为他提交的是我的 cookie 数据而不是他的，所以答案将成为我的。
• 您对“我的”出色答案投了赞成票。
• 我的真实账户明白了这一点。

使用 HTTP-Only cookie，第二步将是不可能的，从而挫败了我的 XSS 尝试。

编辑 4：抱歉，我的意思是您可以将 XMLHttpRequest 发送到 StackOverflow 域，然后将 getAllResponseHeaders() 的结果保存到字符串中，正则表达式输出 cookie，然后将其发布到外部域。 看来维基百科和黑客在这一点上都同意我的观点，但我很乐意接受再教育......

这是正确的。 您仍然可以通过这种方式劫持会话。 不过，它确实大大减少了能够成功执行针对您的 XSS 攻击的人群。

但是，如果您回到我的示例场景，您可以看到 HTTP-Only 成功地切断了依赖于修改客户端 cookie 的 XSS 攻击（并不罕见）。

归根结底，a) 没有任何一项改进可以解决所有漏洞，b) 没有任何系统永远是完全安全的。 HTTP-Only是抵御 XSS 的有用工具。

同样，即使 XmlHttpRequest 的跨域限制不能 100% 成功地阻止所有 XSS 攻击，您仍然不会梦想消除该限制。

Answer 9

是的，它们对于基于 Ajax 的网站来说是一个可行的选择。 身份验证 cookie 不能由脚本操作，而只是由浏览器包含在向服务器发出的所有 HTTP 请求中。

脚本不需要担心会话 cookie 的内容 - 只要您通过了身份验证，那么由用户或脚本发起的对服务器的任何请求都将包含适当的 cookie。 脚本本身无法知道 cookie 的内容这一事实并不重要。

对于用于身份验证以外目的的任何 cookie，如果您希望脚本能够修改或读取这些 cookie，则可以在不使用 HTTP only 标志的情况下设置这些 cookie。 您可以选择哪些 cookie 应该仅是 HTTP，因此例如任何不敏感的内容，例如 UI 首选项（排序顺序、折叠左侧窗格或不折叠）都可以在 cookie 中与脚本共享。

我真的很喜欢仅 HTTP 的 cookie - 这是专有的浏览器扩展之一，真是一个绝妙的主意。