Understanding the CSRF(Cross-site request forgery) Vulnerability

The basic principle of CSRF vulnerability

Whenever we are accessing an application, the browser is sending a request to the server and the server responds to the request by sending some data to the browser called response. This two-way communication continues as we continue using the application. When we login to the application, the login page takes the login credentials as a request to the server. The server analyzes the request, matches the credentials of the user and accordingly sends a response which is one of the following:

1. Successful login to the application
2. Access denied due to incorrect credentials

Let us understand the CSRF attack taking reference of a CMS application. We have a CMS console which has different accounts such as admin, author, user etc. And these different users can perform different actions such as posting a blog, changing account details: username, profile picture, password etc. The admin account can create another account as well. An attacker can craft a request to create a user. The form will contain a username, password and other details of the user to be created. The attacker will send the link to the admin(victim) using some social engineering trick and will make him open the link.  Once the page gets loaded, This action will successfully trigger the malicious form and will create a user with all the desired input from the attacker.

An active session of the user should be present on the browser on which the victim is clicking the button. It is required to make this attack successful. The native behavior of the browser is that it attaches the cookie of the domain (application) to which the requests are being made.

Source: www.opensourceforu.efytimes.com

The above figure demonstrates a CSRF attack in which the attacker lures the victim to transfer funds to attacker’s account. It is achieved by crafting a request that contains the parameters: ‘from’ (account from which funds will be debited) and ‘to’ (account to which funds will be credited). The fact that the victim has a valid session results in a successful execution of the transfer action proving that the banking application is vulnerable to CSRF.

The need to guard against CSRF

It arises due to the fact that CSRF is used to trick a victim into clicking a URL which triggers a request without the victim’s consent. I am using the word ‘malicious’ because this attack will use the identity of the victim and impersonate the victim to perform any actions desired by the attacker, such as changing the account email, and ordering products on eCommerce portals or making payments to a third-party account.

The same can be used to launch any requests on the website, without the website being able to distinguish between legitimate requests and illegitimate requests.

How to implement it?

Firstly, I would like to mention few of the measures that do not work:

• Use of Secret cookie
• Use of POST method

Talking about the effective implementation of CSRF prevention mechanism, there should be a secure random token required for every action (state changing operation). The secure random token should have the following properties:

• Random value
• Unique per user & per user session
• Synchronizer Token Pattern

It is a process in which generation of random “challenge” tokens that are associated with the user’s current session takes place. These tokens are inserted in the HTML forms and links which have critical functionality such as deactivating an account. When the user clicks on these sensitive actions, the HTTP request should contain this token. The server should verify the correctness of the token. By including token with each request, the server has a better control to verify that the user actually wanted to submit the requests, thus differentiating between a legitimate request and illegitimate request. The essential requirement of a token in the request to perform critical actions refrains the attacker from executing CSRF attack as he/she cannot predict the random token. This is as unlikely as the attacker predicting the victim’s session identifier.

Do login and logout actions need CSRF protection?

Login CSRF can lead to a phishing attack. It can be used to execute an attack scenario mentioned in following steps:

• The attacker creates an account on the trusted domain say example.com
• The attacker forges a login request in the victim’s browser with attacker account’s credentials (created in the previous step)
• The attacker tempts the victim into using example.com, where the victim may not notice that he/she is logged in via the attacker’s account
• The attacker will have access to any data or metadata the victim creates (intentionally or unintentionally) while their browser was logged in with the attacker’s account
  Let us consider that example.com is a free video sharing website and it’s login form is vulnerable to CSRF! Example.com allows users to see the log of “their own” viewing history. An attacker could set up an account with a password of his/her desire, log the victim into example.com using that account — stalking what videos the victim was watching.

We should protect logout mechanism against CSRF. Although it seems that an attacker can only lure the victim to logout from the application, which would be annoying at worst. But, if the same is combined with a phishing attack, the attacker can tempt the victim to re-login in using attacker’s own form and capture the victim’s credentials. Although this attack looks very improbable but protection against it requires little effort and hence should be implemented.

Valid Implementations

1. Generate an anti-CSRF token when the user session is created.
2. Break this token into two parts.
3. Now with each request to the server, send one part of the token in  a custom headers field such as Anti-XSS and another part as a hidden body parameter.
4. At the server end, concatenate both these parts and compare it with the generated value.
   If they match, you are good to go.

Challenge-response system

The Challenge-response system is another prevention mechanism that strongly defends against CSRF attacks. An example of such system is CAPTCHA. For detailed understanding of such system, you can refer to the following link. The demerit of using Challenge-response system is that it affects the user experience.

The users should also be made aware of such vulnerabilities. The following measures that should be taken by the user to prevent CSRF attacks:

• Log out from web applications as soon as you are done using it.
• Use the web browser with safety – make sure you don’t save login credentials on the  browser and use only trusted browser extensions.
• The User should not click on random links present as ads on different websites, and other sources.

Talk to our experts using the form on the left if you are looking for application security testing services