The ultimate guide for CSRF – Security Issue

What is CSRF?

Cross-Site Request Forgery (CSRF) is an attack that tricks an end-user to perform undesired actions on a web application in which they are currently authenticated. CSRF attacks target state-changing requests. It is not intended for theft of data because the attacker has no access to the response of the forged request.

A detailed description of CSRF

Cross-Site Request Forgery (CSRF) is an attack that forces the victim into executing a malicious request. It acquires the identity and the access of the victim to perform an unwanted function on the victim’s behalf.

For most of the sites, browser requests automatically incorporate any credentials associated with the site, such as the user’s session cookie, IP address. So, if the user is currently authenticated to the site, it has no other way to distinguish between the forged request and a valid request.

With a slight help of social engineering (like sending a link through email), an attacker may deceive the users of a web application into performing actions of the attacker’s choice.

If the victim is a typical user, a successful CSRF attack can force the user to do state-changing requests like changing their email, address, and so on. If the victim has administration access, CSRF can endanger the entire web application.

How does it work?

I will explain this with an example. Consider A and B are the 2 users in a web application

A – Attacker

B – Victim

Since the attacker is also a user in our web application, the attacker is aware of all the request inputs, their formats and the URLs. They don’t need to worry about the response. Because the intention is not about stealing the data from the response. The intention here is to play with the victim request to make some changes in the victim’s account

Assume, there is a POST request in that web application to allow the user to change their account details. The user A (attacker) is aware of this request

Request URL: https://goaspro.com/update-account-number

Request body: {
“accountNumber”: <account-number>,
“ifscCode”: <ifsc-code>,
“bankName”: <bank-name>
}

For this request, assume that the user id will be taken from the session and update these account details for that particular user.

Assume the user B (victim) is logged in and using the web application. The user A (attacker) has sent a mail to user B (victim). The mail contains a car image which says click here for some discount price. User B has decided to click that image. Now comes the twist. The mail actually contains the form with hidden values for changing the account number.

Consider this is how the mail looks like. It looks like just an image. We didn’t know that this could contain a hidden form

The above image can actually hold a hidden form. The code snippet can be something like this:

<form method="post" action="https://goaspro.com/update-account-number">
    <input type="hidden" name="accountNumber" value="12345678">
    <input type="hidden" name="ifscCode" value="ABCD012">
    <input type="hidden" name="bankName" value="Some bank name">
    <input type="image" name="submit" src="https://goaspro.com/wp-content/uploads/2020/05/Discount-on-Car-1024x683.png" width="1000px;" />
</form>

Copy the above snippet

Paste it into a text file and save it as <filename>.html

Execute the file by just double-clicking on it

You can see only the above image in the output. But on click of that image, it will do a submit for a POST request with the input parameters from the form

Feel free to point the action URL to your localhost and play with the request body. You will get a clear picture of how this is happening

Safety measures which do not prevent CSRF attack

Here are some of the safety measures of a web application. But unfortunately, these safety measures won’t prevent your site from CSRF attack. Let’s have a look at these and see why it doesn’t work

1. Encrypting cookies

Whether your cookies are encrypted or decrypted, it will be sent along with your malicious request. Since the victim is an authorized user, the server will actually decrypts the cookie and proceeds with the request. Here, we cannot differentiate the legitimate request from the malicious request.

2. Changing GET request to POST request

Unfortunately, developers having a misconception that the attacker cannot form a malicious link and hence a CSRF attack cannot be performed. There are various ways for an attacker to force a victim into submitting a forged POST request.

Example: A form with hidden values and submit button text is changed to some link will trick the victim thinking that it is just a link and forces the victim to click based on the link text.

3. Validating user session before performing the request

Since the victim is an authorised user, the malicious request will also be associated with a validated session. So, Validating session of the user will not prevent the application from CSRF attack

Actual preventive measure for CSRF attack

The only prevention strategy is to introduce a CSRF token in all the POST requests of a web application

What is CSRF token?

CSRF token is just a random string associated with your session identifier and also stored in your browser. It will be unique for each and every user and for each and every session

How it prevents CSRF attack?

Each request body will contain the CSRF token (just a random unique string). When the request hits the server, it will compare the CSRF token which is in request body with the CSRF token in the session. If both the values match, then that means that it is a legitimate request.

Since the form data is framed by the attacker, the attacker cannot insert the CSRF token of the victim in that form. Hence the request will fail

This is how CSRF issue needs to be handled. I hope I gave a detailed explanation of this major security issue.

If you have any doubts or need some further clarification, feel free to post it in comments.

Stay happy!! Stay awesome!!