如果在基于 cookie 的访问限制的站点上使用 AJAX，则 JavaScript 需要访问 cookie。 HttpOnly cookie 可以在 AJAX 网站上工作吗？
编辑：如果指定了 HttpOnly，Microsoft 通过禁止 JavaScript 访问 cookie 创建了一种防止 XSS 攻击的方法。 FireFox 后来采用了这个。所以我的问题是：如果您在 StackOverflow 之类的网站上使用 AJAX，是否可以选择 Http-Only cookie？
编辑 2：问题 2。如果 HttpOnly 的目的是阻止 JavaScript 访问 cookie，并且您仍然可以通过 JavaScript 通过 XmlHttpRequest 对象检索 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，然后将其发布到外部域。似乎维基百科和黑客在这一点上同意我的观点，但我希望接受再教育......
最终编辑： 啊，显然两个网站都错了，这实际上是一个bug in FireFox。 IE6& 7 实际上是目前唯一完全支持 HttpOnly 的浏览器。
重申我学到的一切：
HttpOnly 限制对 IE7 & 和 FireFox 中的 document.cookie 的所有访问（不确定其他浏览器）
HttpOnly 从 IE7 中 XMLHttpObject.getAllResponseHeaders() 的响应标头中删除 cookie 信息。
XMLHttpObjects 只能提交到它们起源的域，因此不会跨域发布 cookie。
编辑：此信息可能不再是最新的。
是的，HTTP-Only 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，并且您仍然可以通过 JavaScript 通过 XmlHttpRequest 对象检索 cookie，那么 Http-Only 的意义何在？
考虑这种情况：
我找到了一种将 JavaScript 代码注入页面的途径。
Jeff 加载页面，我的恶意 JavaScript 修改了他的 cookie 以匹配我的。
杰夫为您的问题提交了出色的答案。
因为他是用我的 cookie 数据而不是他的数据提交的，所以答案将成为我的。
您投票支持“我的”出色答案。
我的真实账户明白了这一点。
使用仅 HTTP cookie，第二步将是不可能的，从而挫败了我的 XSS 尝试。
编辑 4：抱歉，我的意思是您可以将 XMLHttpRequest 发送到 StackOverflow 域，然后将 getAllResponseHeaders() 的结果保存到字符串，正则表达式输出 cookie，然后将其发布到外部域。似乎维基百科和黑客在这一点上同意我的观点，但我希望接受再教育......
这是正确的。您仍然可以通过这种方式进行会话劫持。它确实大大减少了即使是针对您的 XSS 攻击也可以成功执行的人。
但是，如果您回到我的示例场景，您可以看到 HTTP-Only 在哪里成功切断了依赖于修改客户端 cookie 的 XSS 攻击（并不少见）。
归结为以下事实：a）没有任何一项改进可以解决所有漏洞；b）任何系统都不会完全安全。 HTTP-Only 是支持 XSS 的有用工具。
同样，即使 XmlHttpRequest 的跨域限制不能 100% 成功阻止所有 XSS 攻击，您仍然做梦也想不到取消限制。
是的，它们对于基于 Ajax 的站点来说是一个可行的选择。身份验证 cookie 不用于由脚本操作，而只是由浏览器包含在向服务器发出的所有 HTTP 请求中。
脚本不需要担心会话 cookie 的内容 - 只要您通过了身份验证，那么用户或脚本向服务器发起的任何请求都将包含适当的 cookie。脚本本身不能知道 cookie 的内容这一事实并不重要。
对于用于身份验证以外的任何 cookie，如果您希望脚本能够修改或读取它们，则可以在没有 HTTP only 标志的情况下设置它们。您可以选择哪些 cookie 仅应为 HTTP，因此，例如 UI 首选项（排序顺序、折叠左侧窗格或不折叠）等任何非敏感信息都可以在 cookie 中与脚本共享。
我真的很喜欢仅 HTTP 的 cookie——它是那些专有的浏览器扩展之一，这是一个非常好的想法。
不一定，这取决于你想做什么。你能详细说明一下吗？ AJAX 不需要访问 cookie 即可工作，它可以自己发出请求以提取信息，AJAX 调用发出的页面请求可以访问 cookie 数据并将其传递回调用脚本，而无需 Javascript 直接访问饼干
作为澄清 - 从服务器的角度来看，AJAX 请求所请求的页面本质上与用户单击链接完成的标准 HTTP get 请求没有什么不同。所有正常的请求属性：user-agent、ip、session、cookies等都被传递给服务器。
还有一点。
Ajax 并不严格要求使用 cookie，但正如其他海报所提到的那样，它们可能很有用。将 cookie 标记为 HTTPOnly 以将其从脚本中隐藏只能部分起作用，因为并非所有浏览器都支持它，而且还因为有一些常见的解决方法。
奇怪的是 XMLHTTPresponse 标头提供了 cookie，从技术上讲，服务器不必在响应中返回 cookie。在客户端上设置后，它会一直保持设置，直到过期。尽管有些方案会随着每个请求更改 cookie 以防止重复使用。因此，您可以通过将服务器更改为不在 XMLHTTP 响应中提供 cookie 来避免这种解决方法。
但总的来说，我认为应该谨慎使用 HTTPOnly。存在跨站点脚本攻击，攻击者安排用户使用简单的 post 表单提交来自另一个站点的类似 ajax 的请求，而不使用 XMLHTTP，并且您的浏览器仍然活动的 cookie 将对请求进行身份验证。
如果您想确保 AJAX 请求经过身份验证，则请求本身和 HTTP 标头需要包含 cookie。例如，通过使用脚本或独特的隐藏输入。 HTTPOnly 会阻碍这一点。
通常需要 HTTPOnly 的有趣原因是防止您网页中包含的第三方内容窃取 cookie。但是有很多有趣的理由让我们对包含第三方内容非常谨慎，并积极过滤它。
当您进行 AJAX 调用时，浏览器会自动处理 Cookie，因此您的 Javascript 无需处理 Cookie。
因此，我假设 JavaScript 需要访问您的 cookie。
来自您浏览器的所有 HTTP 请求都会传输您针对相关站点的 cookie 信息。 JavaScript 既可以设置也可以读取 cookie。根据定义，Ajax 应用程序不需要 Cookie，但大多数 Web 应用程序都需要它们来维护用户状态。
对您的问题的正式回答 - “如果使用 AJAX，JavaScript 是否需要访问 cookie？” - 因此是“不”。例如，考虑使用 Ajax 请求提供自动建议选项的增强搜索字段。在这种情况下，不需要 cookie 信息。
不，AJAX 调用请求的页面也可以访问 cookie，这就是检查您是否登录的原因。
您可以使用 Javascript 进行其他身份验证，但我不相信它，我总是更喜欢在后端进行任何类型的身份验证检查。
是的，cookie 对 Ajax 非常有用。
将身份验证放在请求 URL 中是不好的做法。上周有一条新闻是关于从 google 缓存中获取 URL 中的身份验证令牌。
不，没有办法防止攻击。较旧的浏览器仍然允许通过 javascript 访问 cookie。您只能绕过http等。只要付出足够的努力，您想出的任何东西都可以解决。诀窍是让它付出太多努力而不值得。
如果您想让您的网站更安全（没有完美的安全性），您可以使用过期的身份验证 cookie。然后，如果 cookie 被盗，攻击者必须在它过期之前使用它。如果他们不这样做，那么您有一个很好的迹象表明该帐户存在可疑活动。时间窗口越短，安全性越好，但它对服务器生成和维护密钥的负载就越大。
csrftoken in cookies。我认为需要csrf检查的 AJAX 调用将不起作用，除非您将 csrf 令牌放在隐藏的 HTML 元素中以便 JS 检索它。