Understanding web vulnerabilities in 5 min – Episode #8 – CSRF Cross Site Request Forgery

We will review today the CSRF vulnerabilities, ranked #8 on the OWASP Top 10 2013.
The biggest problem with Cross Site Request Forgery vulnerabilities, is that a lot of web developers do not understand it, for some reason. The way these attacks work is however quite easy to understand, and also easy to remediate.
The impact of such attacks can be quite severe, as it allows attackers to have victims performing various actions on target websites, without noticing it.

In the real world, a CSRF attack would be like someone adding a product in your cart when shopping in a supermarket, and the supermarket cashier treating it as something you really want to buy. If not noticed, you will pay for the additional product.

Let’s go through the different steps of a CSRF attack.
We assume that the attacker has identified a target website that is vulnerable to Cross Site Request Forgery.

CSRF steps illustration

Etapes Cross Site Request Forgery (CSRF)

CSRF step 1

The victim browses a web page managed by the attacker, and hosted on a malicious website. This malicious webpage has been specially crafted to include some piece of code that will automatically trigger a request to the target website. (or manually but without the victim noticing it).
As an example, the piece of code can be a simple html image tag that will send a request to the target website, instead of actually loading an image:
<img src=“http://mytarget.com/change_password.php?new_password=letmein” height=0 width=0>

CRSF step 2

When browsing the malicious website, the victim’s browser will go through the code of the page written by the attacker, and will read the malicious piece of code (the image tag describe above).
This will automatically lead to step 3.

CSRF step 3

The victim sends the request to the target website, executing whatever action the attacker wanted the victim to perform, if the victim is authenticated on the target website.
In our example, the victim will change their password on the target website, without realizing it.
From the target website point of view, the change password request is like any other web request made by the victim in a normal context, since the victim’s browser is making the request, in an authenticated state.

Note that the action that can be performed on the target website through this attack can be any action that is not properly protected against CSRF attacks.
Also note that we took the example of a malicious website hosting the malicious piece of code, but this kind of attack can be performed through other ways, like exploiting an XSS attack.
As a memo, an XSS attack would allow the attacker to include the malicious piece of code (the image) on a third party website, like a forum, a blog, or any other kind of website that he does not own.

How to prevent Cross Site Request Forgery attacks?

Avoiding these vulnerabilities, as a developer

Detecting the vulnerability on your website can be done with either a code analysis, or a penetration test.
CSRF vulnerabilities can be fixed by adding anti-CSRF tokens in all requests, to make them unpredictable (both GET and POST requests).
Requiring a re-authentication is also a way of ensuring that the user we believe is performing the action is really who we think it is and wanted to perform the action. Multi-factor authentication is also efficient, on very sensitive actions.

Avoiding attacks, as a user

As a website user, you can stay out of the way of these attacks by:

  • Logging off after using a website.
  • Not allowing your browser to remember your credentials, and not allowing the website to remember you.
  • Accessing sensitive websites with a different machine, or a different browser.

Other articles in this series: