ajax - 将 antiforgerytoken 放在 _Layout.cshtml 中是否有意义？

Question

我正在开发一个 ASP.NET MVC 应用程序，我计划使用 AntiForegeryToken 保护每个非 GET 请求(POST、PUT、DELETE 等)。

我已经根据 header 中发送的 [__RequestVerificationToken] 实现了经典防伪验证的扩展。这是因为我的大部分调用都是异步的 ($.ajax())，事实证明我更容易以这种方式发送隐藏字段值。

在 _Layout.cshtml(所有页面的模板)中放置一个 @Html.AntiForgeryToken() 并始终只引用那个是否有意义？

我试图理解这个选项和将其放入每种形式之间会有什么不同(我用得不多，因为我的请求几乎都是异步的)，但我没有。

谁能帮我解决这个问题？

谢谢

洛伦佐

Answer 1

您可以将它放在您的 _Layout.cshtml 中，并在呈现页面时生成单个 token ，这很好。

虽然对每个请求使用不同的 token 有非常小的安全优势，但如果您的 token 有足够的熵(@Html.AntiForgeryToken() 生成的标准 token 有)，那么即使在用户 session 期间，攻击者也几乎不可能猜测 token 。因此在大多数情况下，每个用户 session 一个 token 仍然被认为是安全的。

实际上，尝试为每个请求使用新 token 会导致 Javascript 繁重的应用程序出现各种错误，因为浏览器需要一段不可忽视的时间来实际更改 cookie 值或发送请求等内容，并且频繁的 ajax 请求将导致竞争条件，并且您将很难调试围绕 token 不匹配的错误。

ASP.NET MVC 在这方面仍然专注于传统的基于表单的应用程序，虽然您可以使用它来防止现代 Javascript 密集型应用程序中的 CSRF，但需要进行一些调整(例如自定义属性来实际验证请求中发送的 token header )，您必须编写一些自定义代码来执行此操作。希望 Microsoft 将在未来的版本中添加内置支持。

更新

直接在模板页面 (_Layout.cshtml) 中使用 @Html.AntiForgeryToken() 实现解决方案后，我发现了一个可能与使用自定义声明相关的问题。问题发生在重新验证 UserIdentity 期间。作为引用，我将保留指向另一篇文章的链接，我在其中处理了该问题，并在其中为选择相同实现的人添加了 wotrkaround。 Custom Claims lost on Identity re validation

希望对您有所帮助!