By Joel Margolis –
Cross-Site Request Forgery, more commonly referred to as CSRF or “sea-surf”, is ranked as the 8th most critical web application security risk per the 2013 OWASP Top 10 list. Regardless of this, CSRF vulnerabilities exist in many web applications which are accessed by thousands, if not millions, of people every day. This post will cover what CSRF is, how it works, what it looks like, and what can be done to prevent it.
What is CSRF?
CSRF attacks take advantage of the fact that browsers automatically send session cookies when making HTTP requests. This means that if a website fails to check things such as the origin and legitimacy of a request, then an attacker can force a victim’s browser to make requests to that website without the victim even having to do anything other than load a website.
How does CSRF work?
To understand how CSRF attacks work, let’s create a scenario in which it exists using a common example of a banking site. Let’s say that you are a loyal and dedicated customer of securebank.com. When logging into securebank.com, it sets a session cookie in your browser. By doing this, securebank.com can know who you are, that you have logged in already, and any other data that they choose to associate with it. Session cookies like this are what allow you to go to websites that you frequent without having to login every time. Now, let’s say that when you send $50 to your friend Bob using the simple interface on securebank.com, it makes a POST request that looks something like this:
POST /transfer HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X) Chrome/54.0.2840.98
In our example, Bob’s account number is 12345678, sent in the target parameter, and the $50 is the mount of money, sent in the amount parameter. Hopefully youÕre already able to see whatÕs wrong here. An attacker can now use a hidden form on a malicious website that will secretly make a POST request to securebank.com to transfer funds from the account of whomever loads
the page. Then, when a victim loads the malicious website, their browser will make the request and send their session information to securebank.com who will think that the victim made the transfer request on their own behalf.
What does CSRF look like?
From the perspective of the victim loading the malicious website, the source of the malicious page may look something like this:
type=”hidden” name=”target” value=”987654321″>
type=”hidden” name=”amount” value=”10000″>
This HTML code will not display anything in the browser window, but it will make a
request that looks something like this:
POST https://securebank.com/transfer HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X)
As you can see, the session cookie belonging to the victim is still sent in the request
and if securebank.com doesnÕt check the Origin and Referer headers, as well as adding additional protection, this request would pass through and send $10,000 to the attacker.
How to prevent CSRF attacks?
There are two easy methods to help prevent CSRF attacks on your website:
The Origin and Referer headers are standard in almost every request and at least one of these should be present. The Origin header should be the same as the destination of the request, and the Referer header should have the same domain as the destination of the request. If neither of the headers exist, this should throw up some pretty big warning flags, as this almost never happens. It is also very important to remember that these headers cannot be trusted by themselves as they are controlled by the client.
When a webpage is requested that has data to send back to the server, a random CSRF token value should be generated and included in the page HTML where the data is sent before it’s rendered to the client. This value should then be tracked by the server, be linked to the session, and be specific to that request. Now, if a request is made to the server and it is missing the token or the token value is incorrect, you will know that something is wrong. This will mitigate the hidden form code that was shown earlier since the attacker will not be able to get the CSRF token needed to spoof a valid request.
These two methods are by no means the only ways to stop CSRF attacks, but they are an excellent starting point. Once you have successfully verified that these are implemented correctly, research other methods to use in addition.
Cross-Site Request Forgery attacks have the potential to be catastrophic in their implementations and should never be ignored. Every website should have CSRF prevention methods implemented, even if the data being transmitted is not considered to be sensitive. When writing web applications, be sure to include CSRF tokens, and to verify the location and legitimacy of requests you are receiving. If you are looking for more information about CSRF and other web application security risks, I would recommend starting at the OWASP Top 10 List and any of the pages written by OWASP on web vulnerabilities. They have detailed information on both how they work and how they can be prevented. Remember: web applications are only as secure as you make them.