有什么理由不相信ASP.NET AntiForgeryToken？

Question

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

此外，Stack Exchange值在页面上是常量，并且可供客户端脚本使用，因此用于投票的Ajax帖子以及类似的内容也使用该令牌。相比之下

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

• 有理由不信任AntiForgeryToken吗？
• AntiForgeryToken是否有一些Stack Exchange团队不愿意接受的限制？如果是这样他们是什么？
• 或者当Stack Overflow启动时，AntiForgeryToken可能不在（它开始在MVC Futures项目中生活），如果他们今天从头开始做它们会使用AntiForgeryToken吗？

我无法在Stack Exchange团队中找到Jeff或其他人的任何博客文章，以解释SE网络上XSRF预防政策背后的指导原则。如果其中一个人可以写一篇文章，那将是非常好的，当然假设它可以在不产生漏洞的情况下以一般术语完成。对于我们这些想要使我们的网站安全的人来说，这将是非常有价值的信息，但是只是盲目地信任微软为我们做这件事并不完全舒服。

Answer 1

我们遇到的默认实现的一个限制是缺乏对AJAX调用的开箱即用支持。隐藏字段方法适用于主要处理传统形式POST的网站;但是，对于像SO这样的AJAX重型网站来说并不完全。

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

一些（未经请求，我知道！）指针：

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