Cross Site Request Forgery Attack: How to prevent it?

Scripting attacks are a major security issue faced by thousands of businesses and websites around the world. Moreover, Cross site scripting contributes to a majority of all the scripting attacks out there.

With so much damage and high financial drawbacks, every developer and website manager looks to prevent cross scripting attacks. But in the pursuit of preventing one evil, we have completely downplayed the presence of another evil - cross-site request forgery attack.

In this blog post, we’ll take a look at what is a cross-site request forgery (CSRF) attack and understand how it’s carried out. We will also look into the ways to prevent these attacks.

Table of Contents

1. What is a cross-site forgery attack?
2. How do attackers usually perform a cross-site request forgery attack?
3. How to prevent a cross-site request forgery attack?
4. Verdict.

What is a cross-site forgery attack?

Attackers using cross site request forgery try to trick users to send malicious requests to a website that trusts the user. This is possible because these websites trust the browser of a user thanks to cookies. The goal of the attack is to use your identity cookie to execute requests.

For example, you log in to your Facebook account. Facebook then sets a cookie in your browser to identify you. An attacker could now trick you into sending a request to Facebook. This request could simply be - sending messages to thousands of users promoting a malicious website. Cross-site request forgery attack uses the user’s browser to send malicious requests to all websites that trust the user.

Consider another example now.

Let’s assume that you’re casually browsing through Instagram. You see a post about cats and click on it. You love the post and click on the profile. Once on the profile, you see a link in the bio. It reads “click here for more pictures of cats” and you obviously click on it.

After you click on the link, there’s no picture of a cat, but just a dog. You say to yourself that “it’s pretty weird”. You naturally click on the ‘back’ button and realize that your Instagram profile has been deleted!

Here is what possibly happened: The link in the bio forged a “delete request” and sent it to your Instagram account. This request was processed using the same cookies that were downloaded in your web browser. Now your Instagram account has been deleted and wiped off existence.

You have just become a part of a cross-site request forgery attack.

How do Attackers usually perform a Cross Site Request Forgery Attack?

Attackers use a phishing email or message to lure users into their website. The most common method of these phishing attacks is by using a web link that activates the cross-site request forgery attack.

But how do they get these users to click on this link?

That’s where the phishing email and messages that we’ve mentioned in the previous section come into play. These messages lure the user with a ‘free gift’ or a ‘discount’ to something they like. Once the user clicks on this link, the cross site request is achieved.

The request will be forwarded to the target website and the target action will be completed. For example, some attacks may promote something from your own account. Or it could be used to send links and requests to other visitors and users. The possibilities of performing a successful cross-site request forgery attack are just endless.

How to prevent a cross-site request forgery attack?

We’ll start with one of the easier solutions to this problem - check if incoming requests have a referrer header. This will prevent requests being sent from third-party domains and malicious websites. However this method is not preferable for two reasons.

1. Some users might disable their referer header in their browser.
2. Some attackers can create a fake version of a referrer header on some versions of Adobe Flash.

There’s a second way to prevent CSRF attacks - using an Anti-CSRF token. This is not only a more commonly used solution but also quite an effective one. It is a random token (a string of values) shared between the user and a particular web application. The Anti-CSRF token is always hidden inside a session variable and can only be verified by the application.

Let’s consider the same Instagram example. With an Anti-CSRF token in place, your account wouldn’t have been deleted. When you login to an application, this token is shared along with your cookies. Whenever you are trying to get a request from this application. It will check the value of the token against the session variable shared with your web browser. If they match, the request is fulfilled. If they do not match, the request is not fulfilled.

An attacker launching a CSRF attack would stand no chance if he cannot find the value of the token. And in most cases it is impossible to find this code, so the attack never ends up happening. Due to the same origin policy within the system, the attacker cannot even read the response that contains the token, produced by the application.

Verdict

Now that you have seen what CSRF attacks are all about along with the ways to prevent them, it is time to get into action. Employ it in your application to avoid CSRF attacks and offer an additional layer of security to your users.