ASP.NET MVC中的AntiForgeryToken是否可以防止所有CSRF攻击？

Question

使用AntiForgeryToken要求每个请求都传递有效令牌，因此使用简单脚本向我的Web应用程序发布数据的恶意网页将无法成功。

但是，如果恶意脚本首先发出一些简单的GET请求（Ajax），以便在隐藏的输入字段中下载包含防伪令牌的页面，将其解压缩并使用它来生成有效内容，该怎么办？ POST？

是否可能，或者我遗失了什么？

Answer 1

是的，这就是你需要做的一切。

只要您在每个受保护的网页上生成新令牌，<%= Html.AntiForgeryToken() %> 并始终使用[ValidateAntiForgeryToken]

确保在任何受保护的操作中检查它

这实现了OWASP CSRF Prevention Cheat Sheet所讨论的同步器令牌模式。

为了使脚本成功地发出可接受的请求，它必须首先获取表单并读取令牌然后发布令牌。 Same Origin Policy将阻止此操作在浏览器中被允许。站点canot向另一个站点发出AJAX样式的http请求;只对自己。如果出于某种原因可以违反相同的原产地政策，那么你将变得脆弱。

请注意，如果您有跨站点脚本漏洞，则攻击者可以滥用xss漏洞来规避同一源策略提供的保护（因为脚本现在从您自己的站点运行，因此SOP成功）。然后，注入的脚本可以愉快地读取并重新提交令牌。这种通过XSS获得CSRF保护的技术最近在一些蠕虫中很常见。基本上，如果你有XSS，你的CSRF保护是浪费时间，所以要确保你不容易受到影响。

需要注意的另一件事是Flash和Silverlight。这两种技术都不订阅相同的源策略，而是使用跨域策略文件来限制对远程资源的访问。如果您在自己的站点上发布跨域策略xml文件，则Flash / Silverlight脚本只能访问站点上的资源。如果您确实发布了此文件，则只允许使用受信任的第三方服务器的白名单，并且永远不允许*。

详细了解CSRF at OWASP 另见：XSS Prevention Cheat Sheet

Answer 2

但是，如果恶意脚本会首先发出一些简单的GET请求（通过AJAX），以便在隐藏的输入字段中下载包含防伪令牌的页面，将其解压缩并使用它来进行有效的POST？

是的，这是事实，但是，如果它没有在浏览器中结束，那么这不是CSRF攻击。

如果它确实以浏览器结束（例如通过服务器端代码中的HTTP请求进行抓取）那么scrape代码会获得CSRF令牌。但是，您的合法，经过身份验证的用户将在其计算机上获得不同的令牌。由于刮刀抬起的令牌与发给用户的令牌不同，因此POST将失败。

如果你想阻止非浏览器脚本制作帖子，你需要采取另一种方法来验证它是一个人。