Website security is a burning issue these days. We read about hackers gaining illegal access to government websites and banking and other secure sites almost every day. With this in mind, this is the first of a series of articles where we  intend to explain various forms of website security threats.

This article takes a look at Cross Site Request Forgery (XSRF or CSRF), and what you, as a user or as an application owner, can do to avoid it.

CSRF is an attack from that enables an attacker to send HTTP requests from a victim’s computer without his/her knowledge. To elaborate: Assume that you checked the ‘Keep me signed in’ box when you logged in to your blog. This means that your security credentials are stored on your computer and sent by the browser to the site every time you make a request. You trust that the website will not impinge on your privacy and security, while the website trusts that any request coming with your credentials embedded in it actually comes from you. With this being the situation, it is very easy for an attacker to make unauthorized actions on the website while pretending to be you. Let’s see how.

Let’s assume that Jane generally uses the website examplestocks.com to trade in stocks. Since she uses the website quite frequently, she clicks on the ‘Keep me signed in’ box while logging in the first time to avoid having to key in her credentials every time she wants to look at the stock price. A malicious attacker wants to make use of this fact to sell some of Jane’s shares without Jane knowing about it. The attacker knows that the request to buy/sell is sent to the website in the form ‘http://examplestocks.com/sell.php?uid=Jane&symbol=XYZ&sharestosell=100’.

Before we proceed, some background of how a webpage is generated by a browser: When a browser makes a request, it receives a bunch of HTML code, which it then parses to render the page to the user. Attackers commonly use the tags that are used to include images on a webpage. The image tag is as follows: <img src=”http://examplestocks.com/stock.gif”> . When the browser comes across this tag, it sends a request to the server, and uses a standard ‘Get’ request to do so. It is impossible for the browser to differentiate between requests for different resources.

The attacker embeds the sell request within a blank image, i.e., the image tag will look like this: <img src=” http://examplestocks.com/sell.php?uid=Jane&symbol=XYZ&sharestosell=100″>, and makes the image part of, for example, an email. When Jane opens the email to read it, the html in it is parsed, and the request embedded in the email is sent to the website examplestocks.com, and the 100 stocks belonging to Jane in company XYZ are sold, all without Jane being aware of it.  Since the browser automatically supplies the required credentials (remember, Jane is logged in), the server has no way to validate whether the request has, in fact, come from Jane.

You, as a user, do not really have any control over this, since security is defined by the application; however, it may make sense to not keep yourself signed into important accounts like the one in the example above.

You, as an application owner, can take some precautions to ensure that your website is not prone to such attacks. One simple way of doing this is to append user session tokens, which expire after a set time, with each request. The malicious attacker will have no way to replicate this token, thus ensuring that there is no simple way for a non-user to access the site. For example, if you do your bank transaction over the Internet, you may see a ‘Session Expired, Please Login Again’ message if you take too long to input the wire transfer details after logging in. This does not offer complete protection, since an attacker could use complex Cross Site Scripting (XSS) or make use of browser vulnerabilities to perpetrate the attack. The only way to avoid such attacks on your application is by following rigorous coding and security processes to ensure that there are no loopholes in the code that can be exploited.

Source: http://shiflett.org/articles/cross-site-request-forgeries, http://www.cgisecurity.com/csrf-faq.html, http://www.owasp.org/index.php/Cross-Site_Request_Forgery, http://www.debian-administration.org/article/Improving_website_security