15

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

4

1 回答 1

9

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

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

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

  1. 如果你正在运行一个网络农场，你当然应该在你的 Web.config 中使用静态机器密钥
  2. 确保您的所有服务器都安装了此 KB。否则，您可能会遇到机器密钥验证问题
于 2012-04-18T00:41:36.920 回答