我正在开发一个ASP.NET MVC应用程序，并且我正在计划使用AntiForegeryToken来保护每个非GET请求（POST，PUT，DELETE等...）。
我已经根据标头中发送的[__RequestVerificationToken]实现了经典AntiForgery验证的扩展。这是因为我的大多数调用都是异步的（$ .ajax（）），而且我更容易以这种方式发送隐藏字段值。
在_Layout.cshtml（所有页面的模板）中放置一个@ Html.AntiForgeryToken（）是否有意义，并且始终只引用那个？
我试图了解这个选项的不同之处，并将它放在每个表单中（因为我的请求几乎都是异步的，所以我不会使用太多），但我没有＆＃39;吨。
任何人都可以向我说清楚吗？
由于
洛伦佐
答案 0 :(得分：0)
您可以将它放在_Layout.cshtml中并在呈现页面时生成单个标记，这很好。
虽然为每个请求使用不同的令牌有一个非常小的安全优势，但如果您的令牌具有足够的熵（以及由@Html.AntiForgeryToken()生成的标准令牌），那么攻击者实际上是不可行的即使在用户会话期间猜测令牌也是如此。因此，在大多数情况下，每个用户会话的一个令牌仍然被认为是安全的。
实际上，尝试为每个请求使用新令牌会导致Javascript繁重的应用程序中的各种错误，因为浏览器需要一个不可忽视的时间来实际更改cookie值或发送请求等内容，以及频繁的ajax请求会导致竞争条件，你将难以调试令牌不匹配的错误。
ASP.NET MVC在这方面仍然专注于传统的基于表单的应用程序，虽然您可以使用它来防止现代Javascript繁重的应用程序中的CSRF进行一些调整（比如自定义属性来实际验证请求中发送的令牌）标题），你必须写一些自定义代码来做到这一点。希望Microsoft将在未来版本中添加内置支持。
<强>更新
在模板页面（_Layout.cshtml）中直接使用@ Html.AntiForgeryToken（）实现解决方案后，我发现了一个可能的问题，即使用自定义声明。在重新验证UserIdentity期间会发生此问题。作为参考，我将链接到我已经处理过的另一个帖子，并为那些选择相同实现的人添加了wotrkaround。 Custom Claims lost on Identity re validation
希望它有所帮助！