Skip to main content


ASP.NET MVC anti-forgery token demystified – part 1: what is it?

Securing your web application is now more important than ever because various security attacks are growing in numbers and becoming more sophisticated and frequent. One of the most common types of attacks is Cross Site Request Forgery (CSRF) attack. In this kind of attack malicious web sites are hijacking a previously authenticated user sessions to exploit your web site.csrf
Consider the following example: you web site is using ASP.NET Forms Authentication. User is authenticated on login page and user authenticated session is maintained using standard  .ASPXAUTH cookie. Without closing the browser window or logging off your site user is visiting a malicious site which  can (using social engineering, like displaying some sort of a false message to the user) now cross-post to your site (using a standard HTTP form post) and that post will be bearing a valid .ASPXAUTH cookie issued by your site. So, unless your web site employs some special measures, your web site server code will not be able to distinguish a valid post from your web site from a post from malicious site.  Note, that implementing HTTPS on every page your your site will not solve this issue as malicious site can post over HTTPS too. HTTPS can only prevent the traffic between your web site and web client to be hijacked and analyzed, but in case of CSRF attack the attacker doesn’t need to analyze your traffic, it just reuses the authenticated user session.
csrf - explained
In order to combat this kind of attacks ASP.NET MVC contains a set of easy to use components that, if used correctly, can eliminate the possibility of CSRF attacks on your site. The technique is called request verification token and it works like this:
– when your web server is rendering a page which contains a form, it issues two randomly generated tokens. One token is send as a cookie and another is placed inside the form as a hidden field.
– when browser is submitting the page from your web site both tokens are passed to the web server. The cookie token is submitted because it has the same origin as your web site and the form token is submitted because it’s a part of the web form.
– finally, your server side code is receiving the request and checking the validity of the tokens. Both tokens should be present and they should be valid.
Now, let’s consider our example with malicious web site again. Attacker’s web site may contain a form which can post to your web site, but it’s not possible to embed a valid verification token into that form, because token is generated randomly and it’s not possible to predict the generation algorithm. And it’s not possible for the malicious site to automatically read your tokens because of the same origin policy. So, malicious web form post will contain a cookie token, but not the form token. Request verification will fail.
ASP.NET MVC contains the following components that can generate and verify CSRF tokens:
–  @Html.AntiForgeryToken() html helper which needs to be placed inside your html form as following:

@using (Html.BeginForm("Manage", "Account")) {

- [ValidateAntiForgeryToken] controller attribute which is validating tokens in the request and raising a security exception when tokens are not valid.
In the follow up posts I’m going to talk more about how ASP.NET MVC CSRF tokens are generated and validated, how to make them play nicely with AJAX and how avoid enable cross-application token verification.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Stan Tarnovskiy

Solutions Architect at Perficient

More from this Author

Follow Us