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

Question

我知道Stack Exchange站点不使用内置的ASP.NET MVC @Html.AntiForgeryToken()来防止XSRF/CSRF攻击.而不是创建一个名为隐藏输入的__RequestVerificationToken一个很长的基础上,web.config中的部分的machineKey值,堆栈交换方法创建一个名为输入fkey与MUCH更简洁的价值.这显然是一个Guid,根据Google Code上Stack Exchange Data Explorer项目的证据,这个值与每个用户相关联,在您登录或注销之前保持相当稳定.

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

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

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

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

Answer 1

我们在默认实现中遇到的一个限制是缺乏对AJAX调用的开箱即用支持.隐藏字段方法适用于主要处理传统表单POST的站点; 但是,不像AJ这样的AJAX重型网站.

我们实施了此CodeThinked博客文章中概述的方法,我们感到非常高兴.根据他2011年10月的博客文章,看起来Phil Haack也支持这种方法

几个(未经请求,我知道!)指针:

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