HttpOnly cookie 如何处理 AJAX 请求?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/27972/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-06 10:44:06  来源:igfitidea点击:

How do HttpOnly cookies work with AJAX requests?

ajaxcookieshttponly

提问by Shawn

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?

如果在基于 cookie 的访问限制的站点上使用 AJAX,JavaScript 需要访问 cookie。HttpOnly cookie 可以在 AJAX 站点上工作吗?

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?

编辑:如果指定了 HttpOnly,Microsoft 通过禁止 JavaScript 访问 cookie 来创建一种防止 XSS 攻击的方法。FireFox 后来采用了这一点。所以我的问题是:如果您在 StackOverflow 等站点上使用 AJAX,是否可以选择 Http-Only cookie?

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?

编辑 2:问题 2。如果 HttpOnly 的目的是防止 JavaScript 访问 cookie,并且您仍然可以通过 XmlHttpRequest 对象通过 JavaScript 检索 cookie,那么 HttpOnly 有什么意义?

Edit 3:Here is a quote from Wikipedia:

编辑3:这是维基百科的引述:

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 HttpOnlyflag 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].

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

I understand that document.cookieis 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?

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

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.

在您的示例中,我无法写入您的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>

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...

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

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.

最终编辑:啊,显然两个站点都错了,这实际上是FireFox 中的一个错误。IE6 和 7 实际上是目前唯一完全支持 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.
  • HttpOnly 在 IE7 & 和 FireFox 中限制对 document.cookie 的所有访问(不确定其他浏览器)
  • HttpOnly 从 IE7 中 XMLHttpObject.getAllResponseHeaders() 的响应头中删除 cookie 信息。
  • XMLHttpObjects 可能只被提交到它们起源的域,所以没有 cookie 的跨域发布。

edit: This information is likely no longer up to date.

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

回答by Dave Ward

Yes, HTTP-Only cookies would be fine for this functionality. They will still be provided with the XmlHttpRequest's request to the server.

是的,仅 HTTP cookie 适合此功能。它们仍将与 XmlHttpRequest 的请求一起提供给服务器。

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.

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

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

更一般地,是饼干不是必需的AJAX。XmlHttpRequest 支持(或什至 iframe 远程处理,在旧浏览器上)是技术上需要的全部内容。

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.

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

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.

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

XmlHttpRequest won't make cross-domain requests (for exactly the sorts of reasons you're touching on).

XmlHttpRequest 不会发出跨域请求(正是出于您所涉及的各种原因)。

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.

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

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

除非您在服务器端破坏了 StackOverflow.com,否则您将无法窃取我的 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?

编辑2:问题2。如果Http-Only 的目的是防止JavaScript 访问cookie,而您仍然可以通过XmlHttpRequest 对象通过JavaScript 检索cookie,那么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.
  • 我找到了一种将 JavaScript 代码注入页面的方法。
  • Jeff 加载页面,我的恶意 JavaScript 修改了他的 cookie 以匹配我的 cookie。
  • 杰夫为您的问题提供了出色的答案。
  • 因为他是用我的 cookie 数据提交的,而不是他的,所以答案将成为我的。
  • 您投票赞成“我的”出色答案。
  • 我的真实账户明白了这一点。

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

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

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...

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

That's correct. You can still session hiHyman that way. It does significantly thin the herd of people who can successfully execute even that XSS hack against you though.

没错。您仍然可以通过这种方式进行会话劫持。尽管如此,它确实大大减少了能够成功执行甚至针对你的 XSS hack 的人的数量。

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

但是,如果你回到我的示例场景中,你可以看到仅HTTP成功地切断依赖于修改客户端的cookie(并不少见)的XSS攻击。

It boils down to the fact that a) no single improvement will solve allvulnerabilities and b) no system will everbe completely secure. HTTP-Only isa useful tool in shoring up against XSS.

它归结为一个事实)没有单一的改善将解决所有的漏洞和b)没有系统将永远是完全安全的。HTTP-Only支持 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.

同样,即使对 XmlHttpRequest 的跨域限制在阻止所有 XSS 攻击方面不是 100% 成功,您仍然永远不会梦想取消限制。

回答by thomasrutter

Yes, they are a viable option for an Ajax based site. Authentication cookies aren't for manipulation by scripts, but are simply included by the browser on all HTTP requests made to the server.

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

Scripts don't need to worry about what the session cookie says - as long as you are authenticated, then any requests to the server initiated by either a user or the script will include the appropriate cookies. The fact that the scripts cannot themselves know the content of the cookies doesn't matter.

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

For any cookies that are used for purposes other than authentication, these can be set without the HTTP only flag, if you want script to be able to modify or read these. You can pick and choose which cookies should be HTTP only, so for example anything non-sensitive like UI preferences (sort order, collapse left hand pane or not) can be shared in cookies with the scripts.

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

I really like the HTTP only cookies - it's one of those proprietary browser extensions that was a really neat idea.

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

回答by Glenn Slaven

Not necessarily, it depends what you want to do. Could you elaborate a bit? AJAX doesn't need access to cookies to work, it can make requests on its own to extract information, the page request that the AJAX call makes could access the cookie data & pass that back to the calling script without Javascript having to directly access the cookies

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

回答by davenpcj

There's a bit more to this.

这还有一点。

Ajax doesn't strictly require cookies, but they can be useful as other posters have mentioned. Marking a cookie HTTPOnly to hide it from scripts only partially works, because not all browsers support it, but also because there are common workarounds.

Ajax 并不严格要求 cookie,但正如其他海报提到的那样,它们可能很有用。将 cookie 标记为 HTTPOnly 以将其从脚本中隐藏仅部分有效,因为并非所有浏览器都支持它,还因为存在常见的解决方法。

It's odd that the XMLHTTPresponse headers are giving the cookie, technically the server doesn't have to return the cookie with the response. Once it's set on the client, it stays set until it expires. Though there are schemes in which the cookie is changed with every request to prevent re-use. So you may be able to avoid that workaround by changing the server to not provide the cookie on the XMLHTTP responses.

奇怪的是,XMLHTTPresponse 标头提供了 cookie,从技术上讲,服务器不必将 cookie 与响应一起返回。一旦它在客户端上设置,它就会保持设置直到它过期。尽管有一些方案在每次请求时都会更改 cookie 以防止重复使用。因此,您可以通过将服务器更改为不在 XMLHTTP 响应中提供 cookie 来避免这种变通方法。

In general though, I think HTTPOnly should be used with some caution. There are cross site scripting attacks where an attacker arranges for a user to submit an ajax-like request originating from another site, using simple post forms, without the use of XMLHTTP, and your browser's still-active cookie would authenticate the request.

但总的来说,我认为 HTTPOnly 应该谨慎使用。存在跨站点脚本攻击,其中攻击者安排用户使用简单的 post 表单提交来自另一个站点的类似 ajax 的请求,而不使用 XMLHTTP,并且您的浏览器仍然处于活动状态的 cookie 将对请求进行身份验证。

If you want to be sure that an AJAX request is authenticated, the request itself AND the HTTP headers need to contain the cookie. Eg through the use of scripts or unique hidden inputs. HTTPOnly would hinder that.

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

Usually the interesting reason to want HTTPOnly is to prevent third-party content included on your webpage from stealing cookies. But there are many interesting reasons to be very cautious about including third-party content, and filter it aggressively.

通常需要 HTTPOnly 的有趣原因是防止您网页上包含的第三方内容窃取 cookie。但是有很多有趣的原因需要对包含第三方内容非常谨慎,并积极过滤它。

回答by pkchukiss

Cookies are automatically handled by the browser when you make an AJAX call, so there's no need for your Javascript to mess around with cookies.

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

回答by Polsonby

Therefore I am assuming JavaScript needs access to your cookies.

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

All HTTP requests from your browser transmit your cookie information for the site in question. JavaScript can both set and read cookies. Cookies are not by definition required for Ajax applications, but they are required for most web applications to maintain user state.

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

The formal answer to your question as phrased - "Does JavaScript need access to cookies if AJAX is used?" - is therefore "no". Think of enhanced search fields that use Ajax requests to provide auto-suggest options, for example. There is no need of cookie information in that case.

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

回答by Glenn Slaven

As clarification - from the server's perspective, the page that is requested by an AJAX request is essentially no different to a standard HTTP get request done by the user clicking on a link. All the normal request properties: user-agent, ip, session, cookies, etc. are passed to the server.

作为澄清 - 从服务器的角度来看,AJAX 请求所请求的页面本质上与用户单击链接完成的标准 HTTP 获取请求没有什么不同。所有正常的请求属性:user-agent、ip、session、cookies 等都传递给服务器。

回答by Glenn Slaven

No, the page that the AJAX call requests has access to cookies too & that's what checks whether you're logged in.

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

You can do other authentication with the Javascript, but I wouldn't trust it, I always prefer putting any sort of authentication checking in the back-end.

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

回答by Jay

Yes, cookies are very useful for Ajax.

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

Putting the authentication in the request URL is bad practice. There was a news item last week about getting the authentication tokens in the URL's from the google cache.

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

No, there is no way to prevent attacks. Older browsers still allow trivial access to cookies via javascript. You can bypass http only, etc. Whatever you come up with can be gotten around given enough effort. The trick is to make it too much effort to be worthwhile.

不,没有办法防止攻击。较旧的浏览器仍然允许通过 javascript 轻松访问 cookie。你可以只绕过 http 等等。只要付出足够的努力,你想出的任何东西都可以解决。诀窍是付出太多努力不值得。

If you want to make your site more secure (there is no perfect security) you could use an authentication cookie that expires. Then, if the cookie is stolen, the attacker must use it before it expires. If they don't then you have a good indication there's suspicious activity on that account. The shorter the time window the better for security but the more load it puts on your server generating and maintaining keys.

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