为什么CSRF从OWASP前10名中删除，如何防止ASP.NET mvc上的CSRF？

Question

Currently HP fortify scans our ASP.NET MVC code and show me some CSRF problems

I try to search some information on OWASP, and find CSRF is already removed from OWASP TOP 10 with the reason of "More frameworks offering secure-by-default settings and some form of protections"

So, what is the protection on CSRF on ASP.NET MVC ?

if we don't add [ValidateAntiForgeryToken] attribute on the Controller, Does that mean, the controller still vulnerable to CSRF attack ?

Answer 1

Using ASP.Net MVC as an example, CSRF protection on the platform has in the past needed two things: an anti-forgery token that must be included with every form (ie: @Html.AntiForgeryToken() ), and a [ValidateAntiForgeryToken] attribute decorating controller actions for those forms. These two items, in combination with a same-site cookie policy now active in all major browsers, generally mitigate against CSRF. However, these were postive actions the developer needed to take. Failing to do them generally resulted in vulnerable forms, and a new developer who hasn't yet encountered CSRF might not know to look for them.

I don't have the docs or announcement handy, but IIRC they changed the @Html.Form() method in a recent version of MVC so it will now automatically include the token. They also added a new [AutoValidateAntiForgeryToken] attribute which skips safe http actions (GET,HEAD,etc) but checks for the token on unsafe http actions (POST!). Then they updated the scaffolding Visual Studio generates for new projects to include a filter that adds the new attribute on your actions. If for some reason you have an action that should NOT check the token, there is also a new [IgnoreAntiforgeryToken] attribute you can use to override the behavior created by the filter.

Existing projects adding new actions still need to remember to use the old attributes, but new projects — even by developers who don't know any better — will already have all of the right things in all of the right places. If you really want to shoot yourself in the foot, you can write manual <form> elements, remove the filter after the scaffolding is generated, or add bad "ignore" attributes. But the typical new developer shouldn't even need to think about this anymore for new projects... assuming, of course, you're using a sufficiently recent MVC release.

Keeping in mind that other platforms have added or are adding similar or equivalent protections to out-of-the-box behavior, and it's clear why this is no longer in the "Top 10": the default behavior of the major platforms is already safe from this attack. It's still documented at OWASP, and the actual threat has not diminished... but now you're no longer vulnerable by default. You have to go out of your way for this to be a problem. It's not that this is no longer an issue, but that other items like external xml entities or insufficient logging are now perceived as larger threats, and so have replaced it in the top 10 list.

This also highlights one reason you really should use the @Html helpers... they make it possible for your html code to easily stay up to date with the latest best practices, as long as the app continues to receive even minimal maintenance.

Answer 2

ASP.NET contains the Antiforgery package that can be used to secure your application against CSRF attack. See MS Docs

Like OWASP says lots of frameworks offer the preventions besides ASP.NET, we just need to apply these security libraryies. For example, OAuth 2.0 provides the state parameter to prevent CSRF.

If a state parameter is included in the client's request, the same value should appear in the response. It's a good practice for the application to verify that the state values in the request and response are identical before using the response.

As developers, we just need to use these Authentication libraries and middlewares which implement OAuth 2.0 such as Azure Active Directory Authentication JS Library ( ADAL ) and .NET Middleware directly.