HttpOnly cookie如何处理AJAX请求?

Sha*_*awn 191 cookies ajax httponly

如果在具有基于cookie的访问限制的站点上使用AJAX,则JavaScript需要访问cookie.HttpOnly cookies是否可以在AJAX网站上运行?

编辑:如果指定了HttpOnly,Microsoft通过禁止JavaScript访问cookie创建了一种防止XSS攻击的方法.FireFox后来采用了这个.所以我的问题是:如果你在一个网站上使用AJAX,比如StackOverflow,那么Http-Only cookies是一个选择吗?

编辑2:问题2.如果HttpOnly的目的是阻止JavaScript访问cookie,你仍然可以通过XmlHttpRequest对象通过JavaScript检索cookie,那么HttpOnly有什么意义呢?

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

当浏览器收到这样的cookie时,它应该像往常一样在以下的HTTP交换中使用它,但不能让它对客户端脚本可见.[32] 该HttpOnly标志不是任何标准的一部分,并未在所有浏览器中实现.请注意,目前没有阻止通过XMLHTTPRequest读取或写入会话cookie.[33].

我知道document.cookie当你使用HttpOnly时会被阻止.但似乎您仍然可以在XMLHttpRequest对象中读取cookie值,从而允许使用XSS.HttpOnly如何让你更安全?通过使cookie基本上只读?

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

<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>
Run Code Online (Sandbox Code Playgroud)

编辑4:对不起,我的意思是你可以将XMLHttpRequest发送到StackOverflow域,然后将getAllResponseHeaders()的结果保存到字符串中,正则输出cookie,然后将其发布到外部域.似乎维基百科和哈克斯在这一方面同意我,但我希望能够重新接受教育......

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

重申我所学到的一切:

  • HttpOnly限制对IE7和FireFox中的document.cookie的所有访问(不确定其他浏览器)
  • HttpOnly从IE7中的XMLHttpObject.getAllResponseHeaders()中的响应头中删除cookie信息.
  • XMLHttpObjects只能提交给它们来自的域,因此没有cookie的跨域发布.

编辑:此信息可能不再是最新的.

Dav*_*ard 62

是的,HTTP-Only cookie可以用于此功能.它们仍将被提供给服务器的XmlHttpRequest请求.

在Stack Overflow的情况下,cookie将作为XmlHttpRequest请求的一部分自动提供.我不知道Stack Overflow身份验证提供程序的实现细节,但cookie数据可能会自动用于验证您的身份,而不是"投票"控制器方法.

更一般地,是饼干不是必需的AJAX.XmlHttpRequest支持(甚至是旧版浏览器上的iframe远程处理)是技术上所需要的.

但是,如果要为启用AJAX的功能提供安全性,则应用与传统站点相同的规则.您需要一些方法来识别每个请求背后的用户,并且cookie几乎总是达到目的的手段.

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

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 成功地切断依赖于修改客户端的cookie(并不少见)的XSS攻击.

它归结为这样一个事实:a)没有任何一项改进可以解决所有漏洞,而且b)任何系统都不会完全安全.HTTP-Only 支持XSS的有用工具.

同样,即使X​​mlHttpRequest上的跨域限制在防止所有XSS攻击方面没有100%成功,您仍然不会想要删除限制.


tho*_*ter 5

是的,它们是基于 Ajax 的站点的可行选择。身份验证 cookie 不是由脚本操作的,而是由浏览器简单地包含在向服务器发出的所有 HTTP 请求中。

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

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

我真的很喜欢 HTTP only cookie - 它是那些专有浏览器扩展之一,这是一个非常好的想法。


Gle*_*ven 4

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