我正在开发一个 ASP.NET MVC 应用程序，并计划使用 AntiForegeryToken 保护每个非 GET 请求（POST、PUT、DELETE 等）。
我已经基于在标头中发送的 [__RequestVerificationToken] 实现了经典 AntiForgery 验证的扩展。这是因为我的大多数调用都是异步的 ($.ajax())，结果我更容易以这种方式发送隐藏字段值。
在 _Layout.cshtml（所有页面的模板）中放置一个 @Html.AntiForgeryToken() 并始终只引用那个是否有意义？
我试图了解这个选项有什么不同并将它放在每种形式中（我没有使用太多，因为我的请求几乎都是异步的），但我没有。
谁能帮我解决这个问题？
谢谢
洛伦佐
【问题讨论】：
标签： ajax asp.net-mvc security csrf antiforgerytoken
你可以把它放在你的_Layout.cshtml中，在页面渲染的时候生成一个单一的token，没关系。
虽然对每个请求使用不同的令牌有非常小的安全优势，但如果您的令牌有足够的熵（@Html.AntiForgeryToken() 生成的标准令牌确实如此），那么攻击者几乎不可能猜到即使在用户会话期间也可以使用令牌。因此，在大多数情况下，每个用户会话一个令牌仍然被认为是安全的。
实际上，尝试为每个请求使用新令牌会导致 Javascript 繁重的应用程序中出现各种错误，因为浏览器需要一个不可忽视的时间来实际更改 cookie 值或发送请求等内容，并且频繁的 ajax 请求将导致竞争条件，并且您将很难调试令牌不匹配的错误。
在这方面，ASP.NET MVC 仍然专注于传统的基于表单的应用程序，虽然您可以通过一些调整使用它来防止现代 Javascript 应用程序中的 CSRF（例如用于实际验证请求中发送的令牌的自定义属性） headers），您必须编写一些自定义代码才能做到这一点。希望微软将在未来的版本中添加内置支持。
更新
在模板页面 (_Layout.cshtml) 中直接使用 @Html.AntiForgeryToken() 实施解决方案后，我发现了与使用自定义声明相关的可能问题。该问题发生在重新验证 UserIdentity 期间。作为参考，我将把链接留给我一直在处理的另一篇文章，并为那些选择相同实现的人添加了 wotrkaround。 Custom Claims lost on Identity re validation
希望对你有帮助！
【讨论】：