How to prevent CSRF attacks on your Web Apps
Jul 04, 2012
Table of contents:
Cross-Site Request Forgery (CSRF, pronounced “See Surf”) is a possible exploit in Web Applications that allows an attacker to send requests and perform actions on behalf of the victim without their knowledge. CSRF attacks aren’t the most serious threat to your Web App, but you should take precautions to protect your users. Here’s how to prevent CSRF on your Web Apps or Websites.
In case you missed it last week, I talked about how to prevent XSS attacks on your website. If you are looking to protect yourself from attack, you should also go and read that post.
What is a CSRF attack?
A CSRF attack is where an attacker performs an action on a Web Application through a victim’s browser, without the victims knowledge. The request to the Web Application seems genuine because it is coming from the victim. The attacker is able to perform the action by injecting it into a web page that the victim visits. Once the page loads, the action is performed without the victim knowing.
An example of a CSRF attack
The paragraph above might not make much sense, or you might not realise the consequences of this sort of attack without a clear example.
Imagine that a bank uses an online application to allow it’s customers to manage their money, pay bills and set up new accounts. The bank is pretty savvy and has ensured that they are not prone to XSS attacks of SQL Injection.
When a customer (Bob) logs in, the bank creates a session and a cookie on Bob’s computer, nothing strange or particularly wrong about that.
Bob pays a couple of bills and checks his current balance. Once he’s finished he doesn’t click log out, but instead browses over to his favourite new social network.
Unbeknown to Bob, an attacker has placed the following HTML into his profile.
<img src="https://mybank.com/transfer.php?amount=1000&accountId=123" />When Bob views the attacker’s profile page the request to transfer £1000 to the attacker’s account is completed without Bob knowing.
As you can see, the attacker is able to take an action on the victim’s behalf without them ever knowing it.
Now obviously, this kind of attack can only happen when a number of things happen at the same time. Firstly, the attack will only be successful if the victim currently has a stored session or cookie at the targeted website. Secondly, the attacker must be able to correctly send all the required detail to the form. Multi-action forms make this harder, but not impossible.
Nevertheless, as a professional developer, it is your responsibility to ensure that these kinds of security measures are in place to prevent your users falling victim.
How to prevent CSRF attacks
I hope the above example has outlined exactly how this kind of attack takes place. As a developer, you’ve probably already thought up a number of ways you can make these kind of attacks less likely.
Due to the wide variety of web applications, websites, programming languages, security combinations and authorisation methods, I won’t give you a one-size fits all measure that you can ensure you code is safe as that would be impossible.
It is down to your creativity to find ways to protect your website and your users depending on how you’ve built your site.
But, just to get you started, here are a couple of ways you could protect yourself. None of these are the ultimate solution to preventing CSRF attacks. Instead you will probably want to use either a couple of security measures, or make them a lot more bullet proof within the architecture of your system.
Require password confirmation
One obvious method to prevent CSRF attacks is to force the user to re-enter their password whenever they try to take an action. This is going to get very annoying, very quickly for your users, so you might want to only use this method for very sensitive actions.
Check for a security key
Another method for ensuring requests were submitted genuinely is to create a security key for each request and have it authorised before performing the action.
For example, say you had a form that allows a user to place an order. You would have this form produce a random key that gets sent along with the request. Now when dealing with the request, you can verify that the security key is correct in order to proceed.
There are thousands of ways this could be achieved and so I won’t go into giving you exact examples. Just remember, you need to ensure that these security keys can’t be faked, or the whole thing becomes pointless.
