有什么理由不信任 ASP.NET AntiForgeryToken？答案

【问题标题】：Any reason not to trust ASP.NET AntiForgeryToken?有什么理由不信任 ASP.NET AntiForgeryToken？
【发布时间】：2012-04-11 08:47:44
【问题描述】：

我知道 Stack Exchange 站点不使用内置的 ASP.NET MVC @Html.AntiForgeryToken() 来防止 XSRF/CSRF 攻击。 Stack Exchange 方法不是根据 web.config 的 machineKey 部分创建一个名为 __RequestVerificationToken 且具有 really long 值的隐藏输入，而是使用 MUCH 创建一个名为 fkey 的输入 更简洁的值。这显然是一个 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 预防策略背后的指导原则。如果他们中的一个人可以写一篇文章，那将是非常好的，当然假设它可以在不产生漏洞的情况下笼统地完成。对于我们这些想要确保我们的网站安全但又不完全放心只是盲目地相信微软会为我们做这件事的人来说，这将是非常有价值的信息。

【问题讨论】：

选项 3：当我们在 2008-2009 年构建 SO 时，它并不存在。我无法评论内置方法的优缺点，因为我从未使用过它。
另一个考虑是我们放入 MVC 或 ASP.NET 的任何安全机制都必须是通用的。我们可以达到 95% 的情况，但总会有一些客户具有通用内置机制永远无法满足的特殊要求。例如，现有的反 XSRF 实现对大量使用 JSON 或基于声明的身份的网站不友好，在这些情况下，开发人员最终会在大部分时间推出自己的解决方案。

标签： asp.net-mvc asp.net-mvc-3 csrf antiforgerytoken

【解决方案1】：

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

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

几个（不请自来的，我知道！）指针：

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

【讨论】：