CSRF in asp.net mvc and ap.net core

XSRF/CSRF Prevention in ASP.NET MVC and Web Pages

Generating the tokens

To generate the anti-XSRF tokens, call the @Html.AntiForgeryToken method from an MVC view or @AntiForgery.GetHtml() from a Razor page. The runtime will then perform the following steps:

1. If the current HTTP request already contains an anti-XSRF session token (the anti-XSRF cookie __RequestVerificationToken), the security token is extracted from it. If the HTTP request does not contain an anti-XSRF session token or if extraction of the security token fails, a new random anti-XSRF token will be generated.
2. An anti-XSRF field token is generated using the security token from step (1) above and the identity of the current logged-in user. (For more information on determining user identity, see the Scenarios with special support section below.) Additionally, if an IAntiForgeryAdditionalDataProvider is configured, the runtime will call its GetAdditionalData method and include the returned string in the field token. (See the Configuration and extensibility section for more information.)
3. If a new anti-XSRF token was generated in step (1), a new session token will be created to contain it and will be added to the outbound HTTP cookies collection. The field token from step (2) will be wrapped in an <input type="hidden" /> element, and this HTML markup will be the return value of Html.AntiForgeryToken() or AntiForgery.GetHtml().

Validating the tokens

To validate the incoming anti-XSRF tokens, the developer includes a ValidateAntiForgeryToken attribute on her MVC action or controller, or she calls @AntiForgery.Validate() from her Razor page. The runtime will perform the following steps:

1. The incoming session token and field token are read and the anti-XSRF token extracted from each. The anti-XSRF tokens must be identical per step (2) in the generation routine.
2. If the current user is authenticated, her username is compared with the username stored in the field token. The usernames must match.
3. If an IAntiForgeryAdditionalDataProvider is configured, the runtime calls its ValidateAdditionalData method. The method must return the Boolean value true.

If validation succeeds, the request is allowed to proceed. If validation fails, the framework will throw an HttpAntiForgeryException.

Failure conditions

Starting with The ASP.NET Web Stack Runtime v2, any HttpAntiForgeryException that is thrown during validation will contain detailed information about what went wrong. The currently defined failure conditions are:

• The session token or form token is not present in the request.
• The session token or form token is unreadable. The most likely cause of this is a farm running mismatched versions of The ASP.NET Web Stack Runtime or a farm where the <machineKey> element in Web.config differs between machines. You can use a tool such as Fiddler to force this exception by tampering with either anti-XSRF token.
• The session token and field token were swapped.
• The session token and field token contain mismatched security tokens.
• The username embedded within the field token does not match the current logged-in user's username.
• The IAntiForgeryAdditionalDataProvider.ValidateAdditionalData method returned false.

The anti-XSRF facilities may also perform additional checking during token generation or validation, and failures during these checks may result in exceptions being thrown. See the WIF / ACS / claims-based authentication and Configuration and extensibility sections for more information.

Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core