目前HP强化扫描我们的ASP.NET MVC代码并向我展示一些CSRF问题
我尝试在OWASP上搜索一些信息，并且发现CSRF已经从OWASP TOP 10中删除，原因是"More frameworks offering secure-by-default settings and some form of protections"
那么，ASP.NET MVC对CSRF的保护是什么？
如果我们不在Controller上添加[ValidateAntiForgeryToken]属性，这是否意味着，控制器仍然容易受到CSRF攻击？
以ASP.Net MVC为例，平台上的CSRF保护过去需要两件事：一个必须包含在每个表单中的防伪标记（即：@Html.AntiForgeryToken()），以及为这些表单装饰控制器动作的a[ValidateAntiForgeryToken]属性。这两项与现在在所有主流浏览器中都处于活动状态的同站点cookie策略相结合，通常可以缓解CSRF。但是，这些是开发人员需要采取的积极行动。如果不这样做，通常会导致易受攻击的形式，而尚未遇到CSRF的新开发人员可能不知道要查找它们。
我没有方便的文档或公告，但IIRC他们在最新版本的MVC中更改了@Html.Form()方法，因此它现在将自动包含令牌。他们还添加了一个新的[AutoValidateAntiForgeryToken]属性，该属性跳过安全的http动作（GET，HEAD等）但在不安全的http动作（POST！）上检查令牌。然后，他们更新了Visual Studio为新项目生成的脚手架，以包含一个过滤器，用于为您的操作添加新属性。如果由于某种原因你有一个不应该检查令牌的动作，你还可以用一个新的[IgnoreAntiforgeryToken]属性来覆盖过滤器创建的行为。
添加新操作的现有项目仍然需要记住使用旧属性，但是新项目 - 即使是那些不了解更好的开发人员 - 也将在所有正确的位置拥有所有正确的东西。如果你真的想用脚射击自己，可以编写手动<form>元素，在生成脚手架后删除过滤器，或者添加不好的“忽略”属性。但是，典型的新开发人员甚至不需要再考虑这个新项目......当然，假设您使用的是最新的MVC版本。
请记住，其他平台已添加或正在为开箱即用的行为添加类似或等效的保护，并且很清楚为什么这不再是“前10名”：主要平台的默认行为已经安全从这次袭击。它仍然记录在OWASP中，实际的威胁并没有减少......但是现在你不再容易受到攻击。你必须尽力避免这个问题。并不是这不再是一个问题，而是外部xml实体或日志记录不足等其他项目现在被视为更大的威胁，因此已将其替换为前10名列表。
这也突出了你真正应该使用@Html助手的一个原因......它们使你的html代码可以轻松地与最新的最佳实践保持同步，只要应用程序继续获得最小的维护。
ASP.NET包含Antiforgery包，可用于保护您的应用程序免受CSRF攻击。 See MS Docs
与OWASP一样，除了ASP.NET之外，许多框架都提供了预防，我们只需要应用这些安全库。例如，qazxsw poi提供状态参数以防止CSRF。
如果客户端请求中包含状态参数，则响应中应显示相同的值。对于应用程序来说，在使用响应之前验证请求和响应中的状态值是否相同是一种很好的做法。
作为开发人员，我们只需要使用这些身份验证库和中间件来实现OAuth 2.0，例如Azure Active Directory身份验证JS库（OAuth 2.0）和ADAL。