asp.net-mvc - 有什么理由不信任 ASP.NET AntiForgeryToken？

Question

我知道 Stack Exchange 站点不使用 ASP.NET MVC 内置 @Html.AntiForgeryToken() 来防止 XSRF/CSRF 攻击。 Stack Exchange 方法不是根据 web.config 的 machineKey 部分创建一个名为 __RequestVerificationToken 且具有非常长值的隐藏输入，而是创建一个名为 fkey 的输入 具有MUCH 更简洁的值。这显然是一个指南，并且基于 Stack Exchange Data Explorer project on Google Code 的证据。 ，该值与每个单独的用户相关，在您登录或退出之前保持相当恒定。

此外，Stack Exchange 值在页面上是恒定的，并且可供客户端脚本使用，因此 Ajax 发布投票之类的内容也可以使用 token 。相比之下

那么为什么 Stack Exchange 会向自己的鼓手进军呢？

• 有理由不信任 AntiForgeryToken 吗？
• AntiForgeryToken 是否存在 Stack Exchange 团队不愿意接受的一些限制？如果是的话，它们是什么？
• 或者也许当 Stack Overflow 启动时 AntiForgeryToken 还没有出现(它在 MVC Futures 项目中诞生)，如果他们今天要从头开始，他们会使用 AntiForgeryToken？

我无法找到 Jeff 或 Stack Exchange 团队其他人的任何博客文章来解释 SE 网络上的 XSRF 预防策略背后的指导原则。如果他们中的一个人能够写一篇文章，那就太好了，当然假设它可以在不产生漏洞的情况下以一般性的方式完成。对于我们这些想要确保我们的网站安全，但又不愿意盲目相信 Microsoft 为我们做到这一点的人来说，这将是非常有值(value)的信息。

Answer 1

我们在默认实现中遇到的一个限制是缺乏对 AJAX 调用的开箱即用支持。隐藏字段方法适用于主要处理传统表单 POST 的网站；但是，对于像 SO 这样的 AJAX 密集型网站来说就不完全是这样了。

我们实现了此 CodeThinked blog post 中概述的方法我们高兴极了。看起来 Phil Haack 也支持这种方法，基于他的 oct 2011 blog post

一些(主动提供的，我知道!)指针:

1. 如果您正在运行网络场，您当然应该在 Web.config 中使用静态机器 key
2. 确保您的所有服务器 have this KB安装。否则，您可能会遇到机器 key 验证问题