在HTTP GET中使用MVC3的AntiForgeryToken避免Javascript CSRF漏洞 [英] Using MVC3's AntiForgeryToken in HTTP GET to avoid Javascript CSRF vulnerability

查看：26
本文介绍了在HTTP GET中使用MVC3的AntiForgeryToken避免Javascript CSRF漏洞的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

关于这个被黑客入侵的博客，我很犹豫要不要实施提议自

以来的反 JSON GET 劫持解决方案

  1. 缓解 JSON 劫持的推荐解决方案涉及非 REST-full JSON POST 以获取数据

  2. 替代解决方案(对象包装)导致我无法访问源代码的第 3 方控件出现问题.

  3. 我找不到一个经过社区审查的实施方案，该实施方案实施了关于如何编写安全令牌或在网页内安全交付的替代解决方案(如下所列).我也不会声称自己是足够的专家来推出我自己的实施.

  4. 不能依赖引用标头

背景

本博客描述了一个关于 JSON Hijacking 的 CSRF 问题，并建议使用 JSON POSTs获取数据.由于使用 HTTP POST 来获取数据不是非常完整的 REST，我正在寻找一个更完整的解决方案，该解决方案支持每个会话或每个页面的 REST 操作.

另一种缓解技术是将 JSON 数据包装在一个对象中 作为此处描述.恐怕这可能只会拖延问题，直到找到另一种技术.

替代实现

对我来说，扩展使用 ASP.NET MVC 的 AntiForgeryToken 对我的 JSON 使用 jQuery HTTP GET.

例如，如果我获取了一些敏感数据，根据上面的 Haacked 链接，以下代码是易受攻击的:

$.getJSON('[url]', { [参数] }, function(json) {//回调函数代码});

我同意使用推荐的 POST 解决方法获取数据不是 RESTfull.我的想法是在 URL 中发送一个验证令牌.这样，CSRF 风格的攻击者就不会知道完整的 URL.缓存或未缓存，他们将无法获取数据.

以下是如何完成 JSON GET 查询的两个示例.我不确定哪种实现最有效，但可能会猜测第一个更安全，避免错误的代理缓存此数据，从而使其容易受到攻击者的攻击.<​​/p>

http://localhost:54607/Home/AdminBalances/ENCODEDTOKEN-TOKEN-HERE>

或

http://localhost:54607/Home/AdminBalances?ENCODEDTOKEN-TOKEN-HERE

... 这也可能是 MVC3 的 AntiForgeryToken 或变体 (参见 swt).对于上面选择的任何 URL 格式，此标记将设置为内联值.

阻止我推出自己的解决方案的示例问题

  1. 您将使用哪种 URL 格式(以上)来验证 JSON GET(斜杠、问号等) 代理会响应 http://localhost:54607/Home/AdminBalances 和 http://localhost:54607/Home/AdminBalances?ENCODEDTOKEN-TOKEN-HERE 数据?

  2. 您将如何将该编码令牌传送到网页?内联，还是作为页面变量?

  3. 您将如何编写令牌?内置 AntiforgeryToken 还是通过其他方式?

  4. AntiForgeryToken 使用 cookie.在这种情况下会使用/需要支持 cookie 吗?仅 HTTP?SSL 与 HTTP Only 结合如何?

  5. 您将如何设置缓存标头?Google Web Accelerator 的任何特殊内容(例如)

  6. 仅使 JSON 请求 SSL 有什么含义?

  7. 为了安全起见，返回的 JSON 数组是否仍应包含在一个对象中?

  8. 此解决方案将如何与 Microsoft 提议的 模板和数据绑定 功能

上述问题是我没有积极进取并自己做这件事的原因.更不用说可能还有更多我没有想到但仍然存在风险的问题.

解决方案

Asp.net MVC AntiForgeryToken 无法通过 HTTP GET 工作，因为它依赖于依赖于 HTTP POST 的 cookie(它使用双重提交 Cookies" 技术在 OWASP XSRF 预防备忘单).您还可以通过设置为 httponly 来额外保护发送给客户端的 cookie，因此它们无法通过脚本进行欺骗.

在本文档中，您可以找到各种可用于防止 XSRF 的技术.您描述的似乎属于方法 1.但是我们在使用 Ajax HTTP GET 请求时如何检索服务器上的会话存在问题，因为 cookie 不随请求一起发送.因此，您还必须将会话标识符添加到您的操作 URL(也就是无 cookie 会话，更容易劫持).因此，为了执行攻击，攻击者只需要知道执行 GET 请求的正确 URL.

也许一个好的解决方案是使用来自用户 SSL 证书的一些密钥(例如证书指纹)来存储会话数据.这样，只有 SSL 证书的所有者才能访问他的会话.这样您就不需要使用 cookie，也不需要通过查询字符串参数发送会话标识符.

无论如何，如果您不想在 Asp.net MVC 中使用 HTTP POST，您将需要推出自己的 XSRF 保护.

In regards to this Haacked blog, I'm hesitant to implement the proposed anti-JSON GET hijacking solutions since

  1. The recommended solutions to mitigating JSON hijacking involve non-REST-full JSON POSTs to GET data

  2. The alternate solution (object wrapping) causes problems with 3rd party controls I don't have source-code access to.

  3. I can't find a community-vetted implementation that implements the Alternative Solution (listed below) on how to compose the security token, or securely deliver it within the webpage. I also won't claim to be enough of an expert to roll my own implementation.

  4. Referrer headers can't be relied upon

Background

This blog describes a CSRF issue regarding JSON Hijacking and recommends using JSON POSTs to GET data. Since using a HTTP POST to GET data isn't very REST-full, I'd looking for a more RESTfull solution that enables REST actions per session, or per page.

Another mitigation technique is to wrap JSON data in an object as described here. I'm afraid this may just delay the issue, until another technique is found.

Alternative Implementation

To me, it seems natural to extend the use ASP.NET MVC's AntiForgeryToken with jQuery HTTP GETs for my JSON.

For example if I GET some sensitive data, according to the Haacked link above, the following code is vulnerable:

$.getJSON('[url]', { [parameters] }, function(json) {
    // callback function code
});

I agree that it isn't RESTfull to GET data using the recommended POST workaround. My thought is to send a validation token in the URL. That way the CSRF-style attacker won't know the complete URL. Cached, or not cached, they won't be able to get the data.

Below are two examples of how a JSON GET query could be done. I'm not sure what implementation is most effective, but may guess that the first one is safer from errant proxies caching this data, thus making it vulnerable to an attacker.

http://localhost:54607/Home/AdminBalances/ENCODEDTOKEN-TOKEN-HERE

or

http://localhost:54607/Home/AdminBalances?ENCODEDTOKEN-TOKEN-HERE

... which might as well be MVC3's AntiForgeryToken, or a variant (see swt) thereof. This token would be set as an inline value on whatever URL format is chosen above.

Sample questions that prevent me from rolling my own solution

  1. What URL format (above) would you use to validate the JSON GET (slash, questionmark, etc) Will a proxy respond to http://localhost:54607/Home/AdminBalances with http://localhost:54607/Home/AdminBalances?ENCODEDTOKEN-TOKEN-HERE data?

  2. How would you deliver that encoded token to the webpage? Inline, or as a page variable?

  3. How would you compose the token? Built in AntiforgeryToken, or by some other means?

  4. The AntiForgeryToken uses a cookie. Would a backing cookie be used/needed in this case? HTTP Only? What about SSL in conjunction with HTTP Only?

  5. How would you set your cache headers? Anything special for the Google Web Accelerator (for example)

  6. What are the implications of just making the JSON request SSL?

  7. Should the returned JSON array still be wrapped in an object just for safety's sake?

  8. How will this solution interop with Microsoft's proposed templating and databinding features

The questions above are the reasons I'm not forging ahead and doing this myself. Not to mention there likely more questions I haven't thought of, and yet are a risk.

解决方案

The Asp.net MVC AntiForgeryToken won't work through HTTP GET, because it relies on cookies which rely on HTTP POST (it uses the "Double Submit Cookies" technique described in the OWASP XSRF Prevention Cheat Sheet). You can also additionally protect the cookies sent to the client by setting the as httponly, so they cannot be spoofed via a script.

In this document you can find various techniques that can be used to prevent XSRF. It seems the you described would fall into the Approach 1. But we have a problem on how to retrieve the session on the server when using Ajax HTTP GET request since the cookies are not sent with the request. So you would also have to add a session identifier to you action's URL (aka. cookieless sessions, which are easier to hijack). So in order to perform an attack the attacker would only need to know the correct URL to perform the GET request.

Perhaps a good solution would be to store the session data using some key from the users SSL certificate (for example the certs thumb-print). This way only the owner of the SSL certificate could access his session. This way you don't need to use cookies and you don't need to send session identifiers via query string parameters.

Anyway, you will need to roll out your own XSRF protection if you don't want to use HTTP POST in Asp.net MVC.

这篇关于在HTTP GET中使用MVC3的AntiForgeryToken避免Javascript CSRF漏洞的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆