Understanding, Avoiding & Protecting Against Cross Site Request Forgery Attacks

This article explains what a web browser cookie is and examines how Cross Site Request Forgery work by allowing hackers to intercept and access web browser cookies from unaware users trying to logon to a website to continue their online shopping or access personal online files e.g Dropbox etc. We also explain how we can avoid Cross Site Request Forgery attacks and best security practices to keep our web applications and users safer.

What is a Cookie?

When visiting a website, a cookie (small file) from the website is usually stored on your computer containing information such as login details, items you had in your shopping basket etc. Each cookie is unique to your web browser and website visited, so that the website can retrieve or read the contents of its cookie when revisiting it. What most people are unaware of is that any malicious attacker with access to your computer can use the cookies stored therein to exploit access to websites you have visited earlier.

A malicious attacker may take advantage of this situation by latching on to the authentication cookie the user is sending to the website for initiating an action and then using the credentials to impersonate the user. The attacker uses Cross Site Request Forgery (CSRF) for initiating the attack.

Mechanism of a CSRF Attack

The Open Web Application Security Project (OWASP) Top 10 lists Cross Site Request Forgery which is an attack whereby an attacker uses his or her website to send malicious code to a vulnerable web application in which a user is already authenticated.

Figure 1. Illustration of how CSRF attacks work

When the user visits the attacker’s website, the malicious code inadvertently forces the user’s browser to generate an unwanted request to the intended web application, thereby also making it send an authentication cookie. That allows the attacker to gain access to the functionality of the target web application just as the user would. Targets include web interface for network devices, in-browser email clients, and web applications such as social media sites.

Examples of CSRF attacks include the attacker transferring unauthorized money from victims’ bank accounts, sending out offensive postings on social media sites by impersonating you, and snooping on all your Internet traffic by redirecting your router (analyzed below). The attacker does all this from a site different from the vulnerable site, hence the name Cross Site.

Executing A CSRF Attack

Assume you have recently purchased a home wireless router and are trying to configure it via its web interface. As with the most routers, it has a commonly used internal IP address of 192.168.1.1. Since it is difficult to configure, you seek help from a website that has published a guide that shows the necessary buttons to click on the router interface to get everything set up securely.

The website guide actually belongs to attackers and they have a CSRF attack set up in the tutorial. They know that when clicking through their guide, you are also logged in to your router, following their instructions. The CSRF attack reconfigures your router without your knowledge so that all internet traffic would be routed to a proxy server they have set up on the internet, allowing them to monitor your internet activity.

Preventing CSRF Vulnerabilities

To prevent CSRF vulnerabilities, it must be clear the vulnerability actually lies in the affected web application and not in the victim’s browser or the site hosting the CSRF. Therefore, web applications need countermeasures to raise the bar for making CSRF more difficult to perform.

1. As CSRF relies on HTTP requests that produce side effects such as deletions or data modifications with the use of HTTP POST. However a HTTP POST alone may not suffice, as even after the page is loaded, an attacker can create a phantom POST request by using JavaScript. Additional safeguards are necessary to avoid CSRF for POST requests:
2. Check the HTTP Referrer header to verify that the request originated from the web browser the user is using and not from a malicious user agent. Of course, it is also possible for someone to inject HTML/JavaScript code into your page to originate the request. An alternative is to add an original header to the HTTP packet and send it only after the POST request with only a hostname, to ensure privacy.
3. Use one-time tokens. This is a popular method used by banks. The token is generated from a small electronic device for a single session of the user and included in each transmission. Forms contain a field that is populated by the token similar to the one shown below:

   

   Figure 2. Security tokens used for e-banking

4. Use a double-submitted cookie. This is an advanced variation of the one-time token, where the token coming with the form is matched with a cookie, instead of the session value.
5. Use a web application security scanner: you can also use an automated web application security scanner to automatically detect CSRF vulnerabilities in web applications. If you use Netsparker Desktop you do not need to disable the one-time token anti-CSRF technology to automatically scan your website.

Although the above suggestions will reduce the risk dramatically, they are no match for advanced CSRF attacks. Using unique tokens and eliminating all XSS vulnerabilities in web applications are still the strongest techniques against such CSRF attacks.