Understanding & Mitigating Cross-Site Request Forgery (CSRF)

CSRF. Easy, enormously effective, frequently misunderstood. This attack can be called a sleeping lion because it is not taken as seriously as it should be. But what and just how bad is it?
Cross-Site Request Forgery

Cross-Site Request Forgery (Sometimes shortened to CSRF or XSRF, also known as “Sea Surf” or “Session Riding“) is a type of attack that forces a user to execute unauthorized actions when they’re logged in to a web application.

Such an attack occurs when a malicious website causes a user to perform an unauthorized action on another website.
I simply clicked on a link.. What just happened?

It is enough to simply click on a malicious link to have your password changed or to lose all your money. That’s CSRF for you.

The impacts of such an attack can vary depending on the privileges a user has.

If the user has no administrative privileges, CSRF could change his password. However, if the user does have administrative privileges, the impacts of CSRF could be more severe – a potential attacker could compromise the entire web application.
CSRF,XSS and Social Engineering

CSRF does have a good old friend – his name is Cross-Site Scripting (XSS).

Both of these attacks have a few things in common: they are both client-side attacks and need some form of user interaction in order to cause harm – here’s where social engineering comes into play..
Social engineering? What’s that?

Social engineering relies on human interaction as it refers to psychological manipulation of people into performing actions.

Combine that with CSRF and you get an extremely powerful attack vector:

An attacker (User B) finds two flaws in your website that just happens to be CSRF & XSS and knows that a legitimate user (User A) uses your website.
User B communicates with user A and tells him to click on a link that looks exactly* like the website user A wants to visit but is actually an attackers website which redirects to an XSS payload on your website triggering it.
Since the malicious link looks exactly the same as the one of a legitimate website, user A clicks the link.
After the XSS payload is triggered, next thing user A knows is that he has no money – a CSRF attack has taken place.

• The two domain names can look identical if the attacker utilizes an IDN Homograph attack. An IDN (Internationalized Domain Name) attack is such an attack that allows a nefarious party to deceive users about what remote system they’re communicating with by replacing each character of a legitimate system by a similar one of a foreign language.
  How a CSRF attack is exploited

A Cross-Site Request Forgery attack is only effective if a victim is authenticated and logged in to a web application. Here’s an example:

Bob logs into his online banking account. After he’s done, he closes the tab – he does not log out.
Bob checks his email – he has received an invitation that requires him to visit a website. He visits the website.
The nefarious website makes a request to Bob’s banking website to transfer money to an attackers account.
Bob’s banking website receives the request from the malicious website and processes the transfer – Bob’s money is gone.

Even more dangerous example could involve online forums:

You browse around and see a new post, you decide to check it out. The post contains a link to a malicious website:

[img=maliciouswebsite.com/csrf][/img]

If your browser renders this image, a request to maliciouswebsite.com will be made. Here’s where you’ve got a bit of a problem – this could potentially initiate a CSRF attack.
Preventing CSRF

Cross-Site Request Forgery can be mitigated in a number of ways, but perhaps the most popular one is by using tokens: properly generated tokens prevent CSRF from being exploited. How?

Imagine you’ve got a banking website which does not have any sort of CSRF protection:

You visit a website not knowing that is a malicious site.
The attacker who created the malicious website knows that you’re logged in to your banking account and knows the parameter names that are used to transfer money, for example mybank.com/?transferto=account_id&amount=1000.
The attacker sends you a link to his page which contains a request to transfer money from your bank.
You clicked on the link so your browser will process the request. Your money is gone.

Now here’s the same scenario with a CSRF token in place..

The first and second steps are the same, but the ensuing steps and the outcome are a bit different:

The attacker who created the malicious website knows that you’re logged in to your banking account, knows the parameter names that are used to transfer money, but does not know what the CSRF token is – since the token is a long, randomly generated string that is included on each page that is served to you and is different on each request, a potential attacker has no options to guess it.
The attacker sends you a link to his page which contains a request to transfer money from your bank.
You clicked on the link, but the CSRF token is wrong or missing – the attack has been halted.

Takeaways

Cross-Site Request Forgery is an attack that forces a victim into submitting a request he is not aware of. Although the impacts of such an attack can be severe (a potential victim could have his password changed, money stolen, etc.), it can be mitigated in a number of ways. The most popular way to prevent such an attack is by generating CSRF tokens.