OWASP TOP 10 Cross-Site Request Forgery #8 – About CSRF Vulnerability and Fix

Overview

OWASP TOP 10 Cross-Site Request Forgery #8 is a vulnerability which is very commonly found in many web applications these days. And it is also included in the OWASP Top 10 List of Common Web application vulnerabilities.

Before I start with the technical explanation, let me give you a lay-man example of the CSRF attack, just to get the gist of it.

Let’s assume there is a party going on in a town where all the famous celebrities will be present. Alice has received an invitation for the party, but Bob, who is also from the same town, hasn’t. Bob wants to attend the party so that he can also meet the celebrities. Now, in this situation what Bob does is that he somehow tricks Alice and enters the party with her, hiding from the Security Guard’s and Alice’s Knowledge.

Considering this example, Here:

Alice is the victim and Bob is the hacker.

Party is the website which Alice has logged into (eg: a bank Application) and Celebrities is the money.

Invitation is the Session that the bank’s server gives to Alice to access the bank application.

Now that Bob is in the party, he meets all the celebrities and gets out from the party without the security guard’s knowledge.

The example that we just looked at sets the ground for the concept of CSRF attack. Let us now technically understand the concept of CSRF using this real time scenario of a bank transaction.

Technical Explanation

When Alice wants to carry out a transaction, she tries to login to her bank’s web application using her credentials. At this time, the bank assigns her with a session, just like in our example Alice got the invitation for her party. When Alice transfers an amount to her friend’s account, the get request might look something like this

www.examplebank.com?transferamount=100

Now, just like Bob somehow tricked Alice to enter the party, he somehow manages to get this request parameter and creates a web page saying www.examplesite.com.

Once Alice opens this link, the browser automatically accepts the request made by the malicious link sent by Bob. Consequently, the browser makes a payment request from Alice’s account to Bob’s account without her knowledge, just like Bob was able to meet the celebrities on Alice’s invitation without her knowing.

This attack can be achieved in the following way:

Bob could have created the malicious page with some piece of code looking something like this:

Now, what this code does is that it simply redirects the user to www.examplebank.com?transferamount=10000 parameter and forces the browser to submit a money transfer request without Alice’s knowledge.

This results in a successful CSRF attack.

As you can see using a CSRF attack an attacker can do various malicious tasks such as tranferring funds from your account, changing your login credentials, posting comments on your behalf without your knowledge.

Similarly an attacker can takeover an account just by using some piece of malicious script which can look like the code below:

Using this script an attacker can simply change the email address of the victim without the victim’s knowledge.

Once the attacker has changed the email address of the victim he can also change the password of the victim’s account which will result into victim never getting access to his account.

Mitigations

1. Avoid using GET methods for critical operations such as fund transfers.
   As GET methods have some disadvantages with prespective of security:
   a. The URL gets stored in browser history
   b. It will be in any reverse proxy within the hosting infrastructure.
   c. The URL will also be available in web server logs
   d. Users have habit of sharing the URL with their friends. So, sensitive information will be shared by simply sharing links
2. Secure Anti CSRF Tokens:
   Make use of Anti-CSRF Tokens, Randomize the generated tokens to make sure the tokens are unpredictable.
   Encrypt the tokens using a strong algorithm.
3. Anti -CSRF tokens should be present in every form but hidden, so that it wont be visible in the ui but behind the scenes the request will contain it.
   Example:
   You should also make sure that this token changes every time a new page is requested,it should be generated fromt he server everytime a new page is been requested from the client the validation of exact value should be made. Ensure that not only few functionalities but ALL sensitive functionalities should contain that token.
4. It is important to limit the time period to which a token is valid.
5. Use of challenge response mechanisms such as:
   1. Re-authentication: Re-authentication is also a way to protect. Because the attacker will never know the password, so this can also be used in place of CSRF tokens. Re-authentication should be implemented on critical activites such as accound deletion.
   2. Use of Captcha
   3. One-time Tokens: We can make use of One-Time Password(OTP) on cell or some OTP generator hardware devices.

References:

OWASP