What is CSRF and how does it work? CSRF, also known as XSRF, is short for Cross Site Request Forgery. OWASP’s definition for CSRF is this:
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.”
So, what we need to perform a CSRF attack is this:
A vulnerable website or application
A victim which is logged in at this website
Let’s assume the vulnerable website www.example.com allows users to buy goods from their web shop. For the sake of simplicity, I’m using GET parameters to demonstrate the problem, however POST is affected likewise. The URL which a logged-in user has to visit to buy a product is the following:
By calling this URL, we submit the parameters productID and amount with the values xand y to the script. The script uses those parameters to process the order. A malicious attacker can now make a victim’s browser send a request to this website. This could be done by simply putting an image tag on a website that he controls:
The victim’s browser doesn’t know that the referenced URL is not an image at all; it just sends a HTTP request to the given URL to retrieve whatever data there is. And here’s the trick: Because the victim is logged in at example.com, the browser sends all of the victim’s session and authorization data with the request. The victim has unknowingly sent a request to buy 1000 pieces of the product to example.com, and the website has no idea that the request is illegitimate – the order would be executed.
Principles of CSRF protection
So, how do we protect a website against CSRF attacks? The underlying principle is easy. A CSRF attack is based on the fact that the attacked website has no way of knowing if the data it receives actually came from a form on this website. What we need is a way to connect the two necessary HTTP requests – form request and form submission – so that we get this piece of information. We can then make sure that data we receive was really entered by a user on our website.
There are several ways to do this. The most common one, includes a hidden field in each form on the website. This hidden field is called CSRF token. The CSRF token is a random value that changes with each HTTP request sent. As soon as it is inserted in the website forms, it gets saved in the user’s session as well. When the form is submitted, the website checks if the submitted CSRF token equals the one saved in the session. If so, the request is legitimate. The token changes each time a page is requested, which means an attacker would have to guess the current token to successfully perform a CSRF attack.
Fortunately the common Frameworks have included methods for protecting your sites but you have to enable these features. We've been developing sites recently with the need for higher security and have been trawling the web to find some best practice guides. Here's what we found:-
Vulnerability Testing
When costing a development project, always allow more time than you think for the damned IE versions AND if security is important incorporate some days for vulnerability testing. One thing is for sure, a fool and his money will soon be partying. Make sure that isn't your money and developers time trying to patch up insecure code that should have been done properly in the first place. You know who you are people. Budgets are always tight but site downtime and the loss of reputation can cost you more than the extra couple of days that should have been spent.
If you want to test your site take a look here, this article provides some useful info: http://blog.csdn.net/zhonggonglou/article/details/7538702.
Free Vulnerability Scanners
There are a range of free tools out there which can give insights into possible exploits on your site, they will mostly want you to upgrade to the Pro versions. Some of the decent scanners give a trial period, do use them, whilst the cost will be prohibitive for small developers, you know how to make the most out of your many email addresses. 😉 This section deserves another post in its own right but for now check out:-
Hope that provides some decent information and food for thought for small developers. Credit to Bastian Heist for the informative introduction to this article.
