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

Question

使用 AntiForgeryToken 要求每个请求都传递一个有效的 token ，因此带有简单脚本的恶意网页将数据发布到我的 Web 应用程序将不会成功。

但是，如果恶意脚本会首先发出一些简单的 GET 请求(通过 Ajax )以下载隐藏输入字段中包含防伪 token 的页面，提取它并使用它来生成有效的 POST ?

有可能吗，还是我错过了什么？

Answer 1

是的，这就是您需要做的所有事情。

只要您在每个 protected 页面上生成一个新 token ，使用 <%= Html.AntiForgeryToken() %>并始终确保在任何 protected 操作中检查它，使用 [ValidateAntiForgeryToken]
这实现了 CSRF Prevention Cheat Sheet 中讨论的同步器 token 模式。在 OWASP。

为了让脚本成功发出可接受的请求，它必须首先获取表单并读取 token ，然后发布 token 。 Same Origin Policy将阻止这在浏览器中被允许。一个站点不能向另一个站点发出 AJAX 样式的 http 请求；只对自己。如果由于某种原因可以违反同源策略，那么您将变得容易受到攻击。

注意，如果你有跨站脚本漏洞，那么攻击者可以滥用xss漏洞绕过同源策略提供的保护(因为脚本现在是从你自己的站点运行的，所以SOP成功了)。然后注入(inject)的脚本可以愉快地读取并重新提交 token 。这种通过 XSS 绕过 CSRF 保护的技术最近在一些蠕虫中很常见。基本上，如果你有 XSS，你的 CSRF 保护就是浪费时间，所以要确保你不会受到任何攻击。

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

阅读更多关于 CSRF at OWASP
另见:XSS Prevention Cheat Sheet