Not Knowing About CSRF Will Get You Hacked

CSRF attacks are dangerous.

If you are not careful you could be a victim of a CSRF attack, which could lead to your accounts being deleted, loss of data, and much more.

Today I will inform you about CSRF, why it's still a major threat in todays web ecosystem, and how to weaponize your applications against it.

So without further ado… Let’s dive right in!

What is CSRF?

Put simply, CSRF is a cyber attack method that can force users that are authenticated to a certain website to perform unwanted actions due to a bad actor.

To understand it better, let's take a look at the OWASP definition of CSRF and break it down:

“Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.

With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing.

If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth.

If the victim is an administrative account, CSRF can compromise the entire web application.”

You (the end user) will be authenticated to a website, i.e. you have logged in.
The bad actor will often use Social Engineering, i.e. by sending you a malicious email or a malicious hyperlink placed on websites.
This "forged link" you click will make a web request to the website which you are authenticated to. This is often disguised as something more trustworthy, so you are not even aware of the request you are making.
The request you make will perform authenticated-only actions on your behalf. Common examples are account deletion, unauthorized financial transactions. This works because the browser uses your authentication cookies automatically with each request you make.

CSRF Attack Example

So we understand how CSRF works generally, but how would a technical CSRF attack look like?

Scenario

You are logged in to a bank website called bank.com.

You are authenticated, and can perform various actions, the most critical one being the ability to send money to other bank accounts.

Let's say you submit a form to send $1,000 to an acccount with account number CSRFME. This is how the URL will look like once you click "Send".

bank.com/send?acc=CSRFME&amount=1000

Note: Real life bank forms are more secure than this; this for demonstrational purposes.

The hacker will be aware of this URL structure, maybe by sending money in the past and inspecting the URL.

The hacker will exploit this by sending you a "forged" link to bank.com which will perform an unauthorized action, in this case sending money to the hackers' bank account.

Assuming the hacker has account number CSRFEASY, this is how the malicious URL will look like:

bank.com/send?acc=CSRFEASY&amount=1000

Now when you (the user) press on this link, which could be present in an email or on a sketchy website, you effectively perform the action of sending the hacker $1,000 without you even being aware of it!

Here is a diagram to illustrate the process we have just been through:

How to Protect Against CSRF Attacks?

You should now have a solid understanding of CSRF attacks, so how do we prevent them?

There are many suggested methods to prevent CSRF, like secret cookies, only using POST requests, but these do not prevent CSRF effectively.

The most foolproof way to prevent CSRF, is to introduce nonces (numbers only used once), also known as CSRF tokens.

Now if you are from Britain, nonce has a completely different meaning so using the word CSRF token is preferred.

As stated above, CSRF tokens are identifiers that are unique for each web request.

The server generates a CSRF token, returns it to the client, and usually embeds this token in a hidden form field to send along with the existing form data.

Now when the user submits the bank form from earlier, the server will perform an additional check to see if the CSRF token from the client matches the one on the server.

Simple, right?

Using this method, it's impossible for the attacker to guess or get their hands on your CSRF token.

Here is a code example to illustrate what happens on the client side and server side:

Client side:

Server side:

Conclusion

Thank you for making it to the end of this article!

You should now fully understand CSRF attacks, why they are a problem, and how to implement your own protections against it.

CSRF is not patched. Your site could be vulnerable, so it's important to understand the risks you are taking when developing your websites, and what measures you can take to eliminate the threat of CSRF.