Cross site request forgery attacks in one of their simplest forms are a hidden iframe in which an html form is hidden and who’s submit action is triggered on-load. CSRF attacks have been becoming increasingly common – they have the distinct advantage over other attacks (such as SQL injection – it is possible to combine both types of attack for devastating consequences) as they leave virtually no trace of the real attacker.
A CSRF attack works by secretly tricking your browser into posting data to another site via HTML/JavaScript. The user is often unaware of this and the the content of the post and its actions can vary. Some CSRF attacks simply abuse affiliate schemes in the hope that you will eventually visit the website you unknowingly posted to and purchase one of their products. Others can be far more malicious stealing personal information, posting entries in a blog or granting users additional access rights to your CMS.
Even if your website is password protected it could still be vulnerable to a CSRF attack. Since session data is shared amongst all windows a hidden iframe that posts data would be no exception. This would give an attacker the potential to POST to the password protected section of your website (such as a CMS or Control Panel). You might be totally unaware of this until someone mentioned a strange post that you had made. That’s right – the CSRF attack would appear to come from your account. Below is some HTML and JavaScript demonstrating how easy it is to craft a CSRF attack.
exploit.html
<iframe src=”postme.html” style=”display: none;” border=”0″ height=”0″ width=”0″></iframe>
postme.html
<form id=”send_me” name=”send_me” method=”post” action=”http://www.example.com/post_form.php”>
<input name=”title” value=”Teehee” type=”hidden”>
<input name=”content” value=”Woot” type=”hidden”>
<script>
document.send_me.submit();
</script>
</form>
In the above example the code in exploit.html would be pasted into a page, it would then post to example.com/post-form.php when you visited the page. If the website used GET instead of POST it would be possible to craft an even simpler attack
<img src=”http://www.example.com/post_form.php?title=Teehee&content=Woot>
CSRF + DDOS
If the script that you post to is vulnerable to SQL injection you could further compound the CSRF attack and create a Distributed Denial of Service attack on your given domain – every time someone visited your website with the embedded CSRF code in you could cause them to inject an additional SQL statement into an SQL query. If this was a command like BENCHMARK it could very well cripple the target server. Once again it would be very hard to trace the initial perpetrator of this type of attack.
Defending against CSRF
Tokens tend to be the most common way to defend against such attacks. Here the server sets a variable which is stored in a HTTP session. It then inserts a hidden item in the form which contains this value. When the form is posted to the server it checks the HTTP session value against the value sent by the form. If they don’t match, you reject the post.
A potential attacker would be unable to guess this token and as a result it would be very hard if not impossible to craft a CSRF attack.
As you can probably see CSRF attacks are certainly something you need to defend against – in case you don’t believe me here are some examples of CSRF in the news, the latter by David Airey makes very good reading.
http://www.webappsec.org/
http://www.davidairey.co.uk/
