Category Archives: Security

Cross site request forgery (CSRF) Protection Considerations in ASP.NET Webforms and ASP.NET MVC

Cross site request forgery (CSRF) attacks or one click attacks(term being used interchangeably) are one of the most common vulnerabilities present in websites, dashboards etc. In ASP.NET MVC and ASP.NET webforms have some built in security switches you can turn on to defend against CSRF risks but still there are less known facts and caveats in this area that those built in mechanisms will not rescue. ASP.NET MVC developers think they can mitigate the risk by using [ValidateAntiForgeryToken] action filter with MVC actions. To generate the anti-XSRF tokens, call the @Html.AntiForgeryToken() method from an MVC view or @AntiForgery.GetHtml() from a Razor page. This is mostly true but there are still some risks regarding CSRF for Http “GET” requests which is really important to understand which I will be discussing below. If needed you can jump into that.

What about ASP.NET webforms? Many developers think that built in view state would mitigate CSRF risk which is absolutely not. Even though View state will make CSRF attack very little harder, it will not make it impossible. MAC encoding present in ASP.NET webforms is also to prevent viewstate tampering not to defend against CSRF. If an attacker can log in to the page by his own account but still needs to hack into some other user’s account, he can easily grab the view state for the particular page and can be used to attack target user account page action via CSRF. In theory this clearly indicate that there must be some random token not guessable in advance to defend against CSRF risk.  So general recommendation is synchroniser token pattern which used to mitigate this risk.

Does ViewStateUserKey used in ASP.NET web forms really mitigate CSRF risk?

What you can do is set ViewStateUserKey property of the web page instance to set a unique key in Page_Init event handler to associate the page’s view state with a specific authenticated user.

void Page_Init(object sender, EventArgs e)
  if (User.Identity.IsAuthenticated)        
    ViewStateUserKey = Session.SessionID;

When you do this malicious user cannot guess this to include in payload of “one click attack” since this value is unique to specific user. Since requests are validated against this key and exception will be thrown hence CSRF attack will be mitigated. However there are very important security breaches that can possibly arise that must remembered with this approach.

  1. ViewStateUserKey property is an extra addition to the data used in ViewState MAC calculation. If that value changes between post-backs, the ViewState Machine Authentication Code (MAC) calculation will fail hence exception will be thrown. However important bit is view state MAC validation will only be checked against for post backs. What this means is get requests are still vulnerable to “one click attacks” consider this “” this will be happily bypass View State Mac validation.
  2. Sometimes developers disable viewstate


Mitigating HTTP Get CSRF vulnerability?

As stated above even if you apply CSRF protection measure there still you are vulnerable to Get request associated CSRF attacks. Surprisingly this is not mentioned in many CSRF related material. Better approach is to employ combination of below or at least one of the approaches mentioned below to mitigate GET CSRF risk.

  1. One easy approach what I do believe is actions like “” will only be allowed through POST requests. But do remember to include preventive measures as stated above. Allowing only POST requests will NOT mitigate CSRF risk.
  2. Including another random secret key regenerated based on session key can also be employed so in the legitimate website links will be generated in the UI for this. Key can also be included in the cookie and hence can be verified in combination with request url verification token(This approach is known as Double submission cookies). Malicious users can’t lure legitimate users to click on links since random key is generated based on session id and should match against the cookie values.{xxx}
  3. Only allowing requests with a referrer header from the same site is another approach. This has issues since referrer header can be legitimately altered in request propagation to the server from the user browser by firewalls, browsers proxy which can be leads to throwing off legitimate requests from server.
  4. Challenge-Response – When there is an important business transaction such as deleting products above to a get request as stated above, server can respond with another authentication response such as CAPTCHA, re-authentication with password. However using this is really impractical in most scenarios but really strong mechanism.


Leave a comment

Posted by on September 14, 2015 in ASP.NET, Security


Tags: ,