CSRF Attacks – What they are, and why you should still be concerned

By: Steve Sant in Security

Posted on: June 11th 2015 at 13:14pm


Back around the turn of the millennium, few websites were “dynamic”. Most contained primarily static html files. Since then, the web has evolved into the exact opposite. Modern websites often employ both server and client side scripting that interact in a hidden symphony of ajax (Asynchronous Javascript and XML – an acronym within an acronym!).
This is simply the way the web works – particularly Web 2.0 (two point oh, or as some might say, two point oh my, look at all the opportunities for pwnage).

With complexity comes an almost exponential growth in the number of ways things can either go wrong or, importantly, become subverted. Step into my way-back machine for a moment, and I’ll tell you a little story about how I became interested in web application security…

Once upon a time, a decade or so ago, while editing one of my client’s websites, I noticed that a page I only edited the day before had become an explicit advert for a swingers website. My heart sank, followed by a feverish search to discover the extent of the carnage.

I got Spearphished

The website software was up to date, but the raw web hosting server logs revealed a suspicious IP addresses that had logged into the admin area with a username other than my own – Given that I was the only user with admin rights, how had this happened?

Well, it turned out the hack was carried out by exploiting a CSRF Cross Site Request Forgery (pronounced sea-surf) vulnerability in the content management system. Earlier in the day I had received an email, with a spoofed email address, purporting to be from my customer. It looked genuine, and contained a link to a website, which I clicked on. At the time, the website I had opened just showed a blank page, and I thought nothing of it, closing the browser window and continued with my work, making a note to ask my client about it later on.

It turned out I had been spear-phished – targeted by someone who knew who I was working for, and sent a poisoned email.

When I earlier clicked on the bogus webpage, my browser loaded the payload javascript causing my PC to send a request to my client’s website asking it to create a new admin user. I didn’t know this at the time as it happened without anything being displayed on screen.

If this email had been sent to anyone else, it wouldn’t have worked, but because I was currently logged into my customer’s website, my browser automatically sent my secret authentication token (cookie) along with the bogus request, making it appear genuine. Game over. The attacker had taken over the site.

Still delivering victims today
If you haven’t already guessed, CSRF occurs when you are tricked into sending a request to a website you are already logged into (a bank, social media etc.) to do something on behalf of the attacker. All the attacker has to do is trick you into making the bogus request. This is usually means getting you to visit a bogus website containing malicious code.
You must have seen click-bait “you won’t believe what comes out of this guy’s eyeball” posts on Facebook. Many attacks rely on gullible/curious folks who are only too willing to see something awful pop out of someone’s head – so beware next time you are tempted by these kinds of links.

Hacking is often a numbers game, and if you can get hundreds or thousands of people to fall for stuff like that, then you stand a good chance of finding a vulnerable target, eventually.

Facebook users have already fallen victim to CSRF attacks and although Facebook have tightened up their game considerably (although possibly not completely) there are plenty more fish (phish?) in the sea.

Only in the past few weeks, CSRF vulnerabilities have been reported in a popular wireless router, potentially exposing wireless networks to unauthorised access. The problem with CSRF vulnerabilities, is that there are new ones all of the time, awaiting discovery.

Stopping CSRF dead
From the website owner’s point of view, one solution is to produce a one-time security token for internal link to your website – this token is then received along with every request, so that your website software can determine that the request came from an authorised source. This is an approach Facebook have taken, but this is not always practical – however, securing the web application itself is not the focus of my article, but how to protect yourself from insecure ones.

To understand how to protect yourself from CSRF attacks, it’s important to understand a little about how web authentication works. When you log into your online banking, you generally send a username and password (or maybe another authentication factor from a keyfob, dongle etc) – in return the website sends back a cookie containing a (hopefully) cryptographically secure token, identifying your connection as one which has already authenticated.

HTTP, the language of the web, is stateless – so this cookie saves you from having to re-authenticate every time you visit a different page at your bank. Instead, each time you load a new secure page at the bank, your browser sends the cookie along in the background – the bank decodes the cookie and confirms which customer you are, and as far as you are concerned, the whole experience is seemless (or stateful!)

So, what we really want to prevent is any bogus requests being sent to the bank that would cause the secure cookie to also be sent.

There are only two ways to do this.

1.) Turn off cookies completely (good luck with that – you might as well, leave the internet forever)
2.) Don’t browse any other websites using the same web browsing session.

The second option is the only real answer, but how do we isolate our online banking session from anything else? Well, there are a couple of ways in fact.

1.) Use the private browsing functionality of your browser.
Internet Explorer calls it inPrivate, Chrome calls it Incognito, Firefox calls it Private Browsing, and Safari calls it Private Browsing. Private browsing effectively sandboxes the sessions cookies from the non-private windows and tabs in your browser. Therefore CSRF attacks cannot be mounted between websites on either side of the private/non-private fence within your browser.

2.) Use a completely different browser for your trusted secure websites.
Why fiddle about with one browser? Use a different web browser for your secure, trusted websites and ONLY those sites. e.g. Use Chrome for your everyday browsing, and Firefox for your trusted online accounts?

Do these techniques offer 100% protection? No, but if you stick to these rules, then you are significantly reducing your exposure.
The only way to be absolutely safe from CSRF is to only ever open a single website per web browser session (i.e. one private and one non-private*) in each web browser, and then MAKE SURE to delete ALL cookies upon finishing your business – thus removing any possibility of subsequent attacks the next time you open a different website using the same browser.

If that sounds paranoid, then you would be right – but then, if you want to be absolutely safe from CSRF attacks, then that is the only answer.

* multiple private sessions in any web browser share the same caching resource, so don’t make the mistake of thinking you can just keep opening new private windows to isolate your browsing session from all of the others!