With malicious attacks on users forever on the rise we must always ensure that we build our web applications in a secure manner. This is easier said than done when there are many common exploits that can be taken advantage of and when developers are rarely security experts themselves.
Cross-Site Request Forgery is just one of these attacks and features on the OWASP top 10. The threat is applied by a user visiting an infected webpage whilst logged into a separate website in the same browser session. The user will not be aware that this act has performed an action on the website they are logged into. For example, it could change your username and password allowing someone else to access your account and the information within.
You might think that big expensive websites deal with these threats and only your smaller companies fail to protect themselves. You would be wrong, there are cases all the time where these exploits are revealed. Earlier this year supermarket giant Asda was revealed as one of them, read the BBC article.
With regards to .NET applications most developers (hopefully all!) will be very familiar with the Anti Forgery Token that is used in MVC, even if they do not know what it does. By simply adding the following to an MVC view this type of attack is prevented.
@Html.Raw("@Html.AntiForgeryToken()")
and decorate your action as follows:
[ValidateAntiForgeryToken]
The code above simply generates a one time unique code which can be used when the user posts the form. In a CSRF attack this would either be missing or would not match and the server would reject the request.
However, many .NET web applications are still built using Web Forms where this snippet of code will not help you. Whereas the MVC Anti Forgery Token is shown in almost every example of how to create a form, you will not see its Web Forms counterpart mentioned very often at all. In fact, a quick poll of developers showed me that most had either never heard of the property that helps prevent CSRF attacks in Web Forms projects or had never used it, and I have to admit that until recently I would have been one of them.
So how do you prevent CSRF attacks in Web Forms? Well, it’s actually very simple. The concept is the same, we create a unique token to validate requests. It is done using the ViewStateUserKey property:
void Page_Init (object sender, EventArgs e) {
ViewStateUserKey = Session.SessionID;
...
}
In this instance we are setting it to the user’s Session Id as it is unique to the user and should not be known by an attacker. If you are inheriting from a base class you could set application wide by doing the following in the base class:
protected override OnInit(EventArgs e) {
base.OnInit(e);
ViewStateUserKey = Session.SessionID;
}
Whilst it is simple to guard against CSRF it is important to note that other forms of attach such as Cross Site Scripting (XSS) can compromise anti CSRF measures if not protected against as well. For more information on the major threats, visit the OWASP website.
Ben Richardson 