Fortinet Request Failed Csrf Validation Csrf Cookie Not Set Refresh Your Browser and Try Again

Anti-forgery token is used to forbid CSRF (Cross-Site Request Forgery) attacks. Here is how it works in loftier-level:

1. IIS server assembly this token with electric current user'southward identity before sending information technology to the client
2. In the next customer request, the server expects to see this token
3. If the token is missing or information technology is dissimilar, then the server rejects the request (Reference)

These are some of the anti-forgery token related error letters you lot may run across in Event Viewer:

The provided anti-forgery token was meant for a different claims-based user than the current user.

The provided anti-forgery token was meant for user "", but the current user is "X".

The anti-forgery cookie token and grade field token do non friction match.

The required anti-forgery cookie "__RequestVerificationToken" is not present.

A sample stack trace:

          at Organization.Web.Helpers.AntiXsrf.TokenValidator.ValidateTokens(HttpContextBase httpContext, IIdentity identity, AntiForgeryToken sessionToken, AntiForgeryToken fieldToken)at Organisation.Web.Helpers.AntiXsrf.AntiForgeryWorker.Validate(HttpContextBase httpContext)at Organisation.Web.Mvc.ControllerActionInvoker.InvokeAuthorizationFilters(ControllerContext controllerContext, IList`1 filters, ActionDescriptor actionDescriptor)        

Error messages clearly land the root causes simply the solution is non e'er straightforward. I will try to provide possible solutions in the postal service.

Long story short:For anti-forgery validation to pass, the security token of the session token must exist equal to the security token of the field token.

I saw dissimilar names for these cookies in different sources. They can be used interchangeably:

Session token = Cookie token
Field token = Form token
Security token = anti-XSRF Token

Longer story: For validation to pass, form token and session token arecorrelated(Of import: This is not comparison for equivalence. You tin't correlate them by but comparing them in Fiddler). There is anti-XSRF token inside each of those. The anti-XSRF token is the one that should match precisely. Reference

For the instance:

• Cookie/Session token:
  Aq81hoVCPIpq3Q6xjBi0EFKKwSFwnKROgS7tyXF393eAN8rdMNZwkVkEgjQokKviKLVST1iWdgDxBt-g3FIughAsczUO7tyWhtz3fs88xMM1
  Afterwards decoding:01-1A-CF-C9-ED-F1-3E-1E-7D-C9-9E-BE-90-2E-22-91-36-01

• Form token:
  i411mJIr0mZKrk17g4Hf-0_G6aXOJLkzzGfd5yn2mVsTqj-35j_n0YUUCzFRXoFet3BXUVpBicpL3p-AqPPA3XEXEtykt4X-_MbRIxLQH6M1
  Afterward decoding:01-1A-CF-C9-ED-F1-3E-1E-7D-C9-9E-Be-90-2E-22-91-36-00-00-00-00

As you lot see above, the raw tokens are different but extracted anti-XSRF tokens are the same so the validation passes. (At that place are additional bytes at the end. They are flags. The username was going to be encoded in that location if information technology was an authenticated user).

A possible solution to anti-forgery related errors depends on the way how the issue occurs. I would recommend trying to notice out the user behavior that causes these errors.

User beliefs

In my case, the clients were using the application in a fashion that is not supposed to be used. For instance:

1. User goes to the login page
2. User opens a 2nd tab in the same browser and goes to the login folio
3. User logins in the offset tab (or the  2nd, the order doesn't matter)
4. User attempts to login in the remaining login tab

Informing your users well-nigh the points below can significantly reduce the number of anti-forgery errors:

• Using the application merely in one tab
• Not using the Back button to get back to the login page
• Using "Log out" push button once they are done with the application
• There might be other related scenarios. I would recommend contacting your users and asking what action they took to generate the issue

Catch the Exception

Communicable the anti-forgery exceptions in your code and redirecting user to the homepage if they are already authenticated should prevent near of the errors. Here is a sample lawmaking cake:

          [HttpPost] [AllowAnonymous] [ValidateAntiForgeryToken] public ActionResult Login(LoginModel model, string returnUrl) { ... }   protected override void OnException(ExceptionContext filterContext) {     base.OnException(filterContext);       var activeness = filterContext.RequestContext.RouteData.Values["action"] equally string;     var controller = filterContext.RequestContext.RouteData.Values["controller"] as string;       if ((filterContext.Exception is HttpAntiForgeryException) &&         action == "Login" &&         controller == "MyController" &&         filterContext.RequestContext.HttpContext.User != null &&         filterContext.RequestContext.HttpContext.User.Identity.IsAuthenticated)     {         filterContext.ExceptionHandled = true;           // redirect/prove error/whatever?         filterContext.Result = new RedirectResult("/homepage");     } }                  

Information technology may take time to fine tune this code block. There is no one solution that fits all.

Remove the anti-forgery validation from the login page

I saw customers not using the anti-forgery validation in thepublic pages such equally login, about, annals pages. Anti-forgery token's principal purpose is to prevent attacker using hallmark cookie for doing things on behalf of the actual user. Since the user isn't authenticated yet in the login page, at that place are customers removing the validation.

Attempt quick fixes

The common "possible solutions" to anti-forgery token/cookie related issues are disabling output caching and enabling heuristic checks. I will include the lawmaking snippets hither.

Disable output caching:

          [OutputCache(NoStore = true, Location = Organization.Web.UI.OutputCacheLocation.None)]        

Add together "heuristic checks" to the Application_Start method of Global.asax file:

          AntiForgeryConfig.SuppressIdentityHeuristicChecks = true;        

joneshoon1968.blogspot.com

Source: https://techcommunity.microsoft.com/t5/iis-support-blog/anti-forgery-token-and-anti-forgery-cookie-related-issues/ba-p/984870

Share this post