在HTTP GET中使用MVC3的AntiForgeryToken避免Javascript CSRF漏洞

Question

关于这个Haacked博客，我不愿实施建议的反JSON GET劫持解决方案，因为

1. 缓解JSON劫持的推荐解决方案涉及到非REST完整的JSON POST来获取数据

2. 替代解决方案（对象包装）导致我没有源代码访问权限的第三方控件出现问题。

3. 我找不到社区审核的实现，该实现实现了有关如何构成安全令牌或在网页内安全交付该令牌的替代解决方案（下面列出）。我也不会声称自己足够专家来实施自己的实现。

4. 无法依赖引荐来源标头

背景

该博客描述了有关JSON劫持的CSRF问题，并建议使用JSON POST来获取数据。由于使用HTTP
POST来获取数据并不是完全符合REST的，因此我正在寻找一种更RESTful的解决方案，该解决方案可以为每个会话或每个页面启用REST操作。

另一种缓解技术是将JSON数据包装在一个对象中，如此处所述。恐怕这可能会延迟问题，直到找到另一种技术为止。

替代实施

对我而言，将JSON的jQuery HTTP GET与ASP.NET
MVC的AntiForgeryToken
结合使用似乎很自然。

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

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

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

以下是两个如何完成JSON GET查询的示例。我不确定哪种实现最有效，但是我可能猜测第一个方法更容易避免错误的代理将数据缓存，从而使它容易受到攻击者的攻击。

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：//本地主机：54607 /首页/ AdminBalances与HTTP：//本地主机：54607 /首页/ 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提议的模板和数据绑定功能互操作

上面的问题是我自己不努力前进的原因。更不用说还有更多我尚未想到的问题，但仍然存在风险。

Answer 1

Asp.net MVC AntiForgeryToken不能通过HTTP GET起作用，因为它依赖于依赖于HTTP POST的cookie（它使用OWASP
XSRF 预防备忘单中介绍的“ Double Submit
Cookies
”技术）。您还可以通过将as设置为httponly来另外保护发送给客户端的cookie，以使它们无法通过脚本进行欺骗。

在本文档中，您可以找到可用于防止XSRF的各种技术。您所描述的似乎属于方法1。但是，由于cookie没有随请求一起发送，因此在使用Ajax
HTTP
GET请求时如何在服务器上检索会话存在问题。因此，您还必须在操作的URL中添加会话标识符（也称为无cookie会话，更易于劫持）。因此，为了进行攻击，攻击者只需要知道正确的URL即可执行GEThtml" target="_blank">请求。

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

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