asp.net-mvc – 任何理由不信任ASP.NET AntiForgeryToken？

我知道Stack Exchange网站不使用ASP.NET MVC内置的@ Html.AntiForgeryToken()来防止XSRF / CSRF攻击. Stack Exchange方法基于web.config的machineKey部分创建一个名为__RequestVerificationToken的隐藏输入,而不是创建一个名为__RequestVerificationToken的隐藏输入,而Stack Exchange方法创建一个名为fkey的输入,其数量更为简洁.这显然是一个Guid,并且基于 Stack Exchange Data Explorer project on Google Code的证据,这个值与每个用户有关,在您登录或退出之前保持不变.

此外,堆栈Exchange值在页面上是不变的,并且可用于客户端脚本,以便Ajax发布投票和类似的东西也使用令牌.相比之下

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

有没有理由不信任AntiForgeryToken？
> AntiForgeryToken是否有一些局限性,Stack Exchange团队不愿意接受？如果是这样的话呢？
>或者,当Stack Overflow启动时,或者如果它们从头开始,它们将使用AntiForgeryToken,那么AntiForgeryToken不会在周围(它在MVC Futures项目中开始生活)

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

解决方法

我们遇到的一个缺陷是缺少对AJAX调用的即时支持.隐藏的方法适用于主要处理传统形式POST的网站;但是,不太适合像SO这样的AJAX重型网站.

我们实施了这个CodeThinked blog post概述的方法,我们不能快乐.根据他的oct 2011 blog post,Phil Haack看起来也支持这种做法

几个(不请自来,我知道！)指针：

>如果您正在运行一个网络场,那么您当然应该在Web.config中使用一个静态的machinekey
>确保安装了所有服务器have this KB.否则,您可能会遇到机密验证问题

原文地址：https://www.jb51.cc/aspnet/250733.html