HttpOnly Cookie如何使用AJAX请求？ [英] How do HttpOnly cookies work with AJAX requests?

问题描述

如果在具有基于Cookie的访问限制的网站上使用AJAX，JavaScript需要访问Cookie。 HttpOnly Cookie在AJAX网站上工作吗？

编辑：如果指定了HttpOnly，Microsoft通过禁止JavaScript访问Cookie创建了一种防止XSS攻击的方法。 FireFox后来采纳了这个。所以我的问题是：如果你在一个网站上使用AJAX，如StackOverflow，是Http-Only cookies一个选项吗？

问题2.如果HttpOnly的目的是阻止JavaScript访问Cookie，并且您仍然可以通过XmlHttpRequest对象通过JavaScript检索Cookie， HttpOnly 的要点是什么？

编辑3：以下是维基百科的报价：

浏览器接收这样的cookie，它应该像下面的HTTP交换一样使用它，但不是使其可见的客户端脚本。[32] HttpOnly 标志不是任何标准的一部分，并且不在所有浏览器中实现。注意，目前没有通过XMLHTTPRequest来防止读取或写入会话cookie。 [33]。

我明白， document.cookie 请使用HttpOnly。但是似乎你仍然可以读取XMLHttpRequest对象中的cookie值，允许XSS。 HttpOnly如何使你更安全？通过使饼干基本上只读？

在您的示例中，我无法写入您的 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>对我有用[0]丢个板砖[0]引用|举报|编辑删除管理回复次数： StackOverflow域，然后将getAllResponseHeaders（）的结果保存到字符串，regex输出cookie，然后发布到外部域。看起来维基百科和哈克斯在这一页上同意我的观点，但我会喜欢重新教育... 
 
 
 
 最后编辑： Ahh，显然这两个网站都错了，这实际上是一个 FireFox中的错误 。 IE6& 7实际上是目前完全支持HttpOnly的唯一浏览器。
 
 
 
重申我学到的一切：
 
 
 
 
 
 HttpOnly限制所有访问document.cookie在IE7&和FirefoxFox（不知道其他浏览器）
 
 
 HttpOnly从IE7中的XMLHttpObject.getAllResponseHeaders（）的响应标头中删除Cookie信息。
 
 
 XMLHttpObjects可能
 
 
 
 
 
 编辑：  
解决方案
是的，HTTP-只有Cookie才适用于此功能。他们仍然会向服务器提供XmlHttpRequest的请求。
 
 
 
在Stack Overflow的情况下，cookies会自动作为XmlHttpRequest请求的一部分提供。我不知道Stack Overflow身份验证提供程序的实现细节，但该cookie数据可能自动用于验证您的身份比投票控制器方法更低的水平。
 
 
 
更一般地说，AJAX需要不。 
 
 
 
但是，如果您想为启用AJAX的功能提供安全性，则必须使用相同的规则适用于传统网站。 
 
 
在您的示例中，我将使用一个方法来识别每个请求后面的用户，无法写入您的document.cookie，但我仍然可以使用XMLHttpRequest对象窃取您的Cookie并将其发布到我的域。
 
 
 XmlHttpRequest不会产生跨网域请求（正是您触及的各种原因）。
 
 
 
您通常可以使用脚本将Cookie发送到您的域iframe remoting or JSONP，but then HTTP-Only再次保护cookie，因为它不可访问。
 
 
 
除非你在服务器端损害了StackOverflow.com，你不会能够窃取我的cookie。
 
 
编辑2：问题2.如果Http-Only的目的是阻止JavaScript访问cookies，您仍然可以通过JavaScript通过XmlHttpRequest对象检索Cookie，Http-Only的点是什么？
 
 
请考虑这种情况： / p> 
 
 
 
 
我找到了将JavaScript代码插入页面的途径。
 
 
 Jeff加载页面
 
 
 
 
 
因为他使用我的Cookie资料提交，而不是
 
 
 
 
 
您的投票结果为我的 
 
 
 
 
对于仅使用HTTP的cookie，第二步是不可能的，从而打败了我的XSS尝试。
 
 
编辑4：对不起，我的意思是你可以发送XMLHttpRequest到StackOverflow域，然后将getAllResponseHeaders（）的结果保存到一个字符串，regex出cookie，然后发布到外部域。看起来维基百科和哈克斯在这一页上同意我的意见，但我会喜欢重新教育... 
 
 
正确。你仍然可以会话劫持这种方式。 
 
 
 
但是，如果你回到我的示例场景，你可以看到在哪里HTTP-Only  成功切断了依赖修改客户端Cookie的XSS攻击（非常见）。
 
 
 
 a）没有单一的改进将解决所有漏洞，并且b）没有系统能够完全安全。 
 
 
 
类似地，即使XmlHttpRequest的跨域限制不是100％，但是HTTP-only 是成功地阻止了所有的XSS攻击，你仍然不会想要删除限制。
 
JavaScript needs access to cookies if AJAX is used on a site with access restrictions based on cookies. Will HttpOnly cookies work on an AJAX site? 

Edit: Microsoft created a way to prevent XSS attacks by disallowing JavaScript access to cookies if HttpOnly is specified. FireFox later adopted this. So my question is: If you are using AJAX on a site, like StackOverflow, are Http-Only cookies an option?

Edit 2: Question 2. If the purpose of HttpOnly is to prevent JavaScript access to cookies, and you can still retrieve the cookies via JavaScript through the XmlHttpRequest Object, what is the point of HttpOnly?

Edit 3: Here is a quote from Wikipedia:

  
When the browser receives such a cookie, it is supposed to use it as usual in the following HTTP exchanges, but not to make it visible to client-side scripts.[32] The HttpOnly flag is not part of any standard, and is not implemented in all browsers. Note that there is currently no prevention of reading or writing the session cookie via a XMLHTTPRequest. [33].
I understand that document.cookie is blocked when you use HttpOnly. But it seems that you can still read cookie values in the XMLHttpRequest object, allowing for XSS. How does HttpOnly make you any safer than? By making cookies essentially read only? 

In your example, I cannot write to your document.cookie, but I can still steal your cookie and post it to my domain using the XMLHttpRequest object.
<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>
Edit 4: Sorry, I meant that you could send the XMLHttpRequest to the StackOverflow domain, and then save the result of getAllResponseHeaders() to a string, regex out the cookie, and then post that to an external domain. It appears that Wikipedia and ha.ckers concur with me on this one, but I would love be re-educated...

Final Edit: Ahh, apparently both sites are wrong, this is actually a bug in FireFox. IE6 & 7 are actually the only browsers that currently fully support HttpOnly.

To reiterate everything I've learned:


HttpOnly restricts all access to document.cookie in IE7 & and FireFox (not sure about other browsers)
HttpOnly removes cookie information from the response headers in XMLHttpObject.getAllResponseHeaders() in IE7.
XMLHttpObjects may only be submitted to the domain they originated from, so there is no cross-domain posting of the cookies.


edit: This information is likely no longer up to date.
解决方案
Yes, HTTP-Only cookies would be fine for this functionality.  They will still be provided with the XmlHttpRequest's request to the server.

In the case of Stack Overflow, the cookies are automatically provided as part of the XmlHttpRequest request.  I don't know the implementation details of the Stack Overflow authentication provider, but that cookie data is probably automatically used to verify your identity at a lower level than the "vote" controller method.

More generally, cookies are not required for AJAX.  XmlHttpRequest support (or even iframe remoting, on older browsers) is all that is technically required.

However, if you want to provide security for AJAX enabled functionality, then the same rules apply as with traditional sites.  You need some method for identifying the user behind each request, and cookies are almost always the means to that end.

  
In your example, I cannot write to your document.cookie, but I can still steal your cookie and post it to my domain using the XMLHttpRequest object.
XmlHttpRequest won't make cross-domain requests (for exactly the sorts of reasons you're touching on).

You could normally inject script to send the cookie to your domain using iframe remoting or JSONP, but then HTTP-Only protects the cookie again since it's inaccessible.

Unless you had compromised StackOverflow.com on the server side, you wouldn't be able to steal my cookie.

  
Edit 2: Question 2. If the purpose of Http-Only is to prevent JavaScript access to cookies, and you can still retrieve the cookies via JavaScript through the XmlHttpRequest Object, what is the point of Http-Only?
Consider this scenario:


I find an avenue to inject JavaScript code into the page.
Jeff loads the page and my malicious JavaScript modifies his cookie to match mine.
Jeff submits a stellar answer to your question.
Because he submits it with my cookie data instead of his, the answer will become mine.
You vote up "my" stellar answer.
My real account gets the point.


With HTTP-Only cookies, the second step would be impossible, thereby defeating my XSS attempt.

  
Edit 4: Sorry, I meant that you could send the XMLHttpRequest to the StackOverflow domain, and then save the result of getAllResponseHeaders() to a string, regex out the cookie, and then post that to an external domain. It appears that Wikipedia and ha.ckers concur with me on this one, but I would love be re-educated...
That's correct.  You can still session hijack that way.  It does significantly thin the herd of people who can successfully execute even that XSS hack against you though.

However, if you go back to my example scenario, you can see where HTTP-Only does successfully cut off the XSS attacks which rely on modifying the client's cookies (not uncommon).

It boils down to the fact that a) no single improvement will solve all vulnerabilities and b) no system will ever be completely secure.  HTTP-Only is a useful tool in shoring up against XSS.

Similarly, even though the cross domain restriction on XmlHttpRequest isn't 100% successful in preventing all XSS exploits, you'd still never dream of removing the restriction.

                        
这篇关于HttpOnly Cookie如何使用AJAX请求？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！