Cross-Site Request Forgery (CSRF) Vulnerability

What is CSRF?

CSRF which is a short form for "Cross-Site Request Forgery" is a cybersecurity vulnerability. Attackers use this vulnerability to trick the victim into executing malicious actions on the websites they are already authenticated with. The requests will be successful in execution as the browser considers this request as coming from the user rather than any other else as there is no way to differentiate between the two. These requests are generally targeted into changing login passwords of the authenticated websites or authorizing an illegal bank transaction or stealing sensitive data such as cookies and tokens.

These requests are generally sent to victims using methods such as fraud emails and links which under the premise of something else also execute these malicious requests which we will see more about further in the article. This is sometimes confused with XSS or cross-site scripting, which is a separate vulnerability and you may visit the following article for more details. XSS Article

History

In the early 2000s, a widespread worm known as the samy virus affected almost affected a million users in about 20 hours. The worm used a combination of cross-site scripting and cross-site request forgery. This worm made other web applications how prone they were to such attacks. After this attack, a lot of web applications fixed their vulnerabilities. Till 2017 this vulnerability maintained its position in the top 10 OWASP vulnerabilities. Many big companies had fallen victim to cross-site request forgery attacks. Some examples include Netflix, YouTube, and even McAfee.

How Does CSRF Work?

Cross-site request forgery works on the concept that the browser is unable to differentiate between real and malicious requests and the fact that sessions are being maintained by the websites to allow users to resume working. This would be better understood with an example, for example, an attacker puts a malicious request in a webpage and sends a link to you on the pretext that if you visit that website, you might win something and you clicked on the website. You may not see that a request has been sent in the background, which will now cause damage in the form of stolen credentials or approval of the unauthorized transaction. That request might or might not have been dependent upon the user’s interaction. We will see further in the article what are various types of requests and how to create them.

Three things are to be kept in mind before framing a CSRF attack. The first one is what is the target of the attacker, Is the attacker trying to get access to the victim's account through password reset or there is another action the attacker wants to perform? The second one is that the website the attacker is targeting requires only the session cookies or does it require something else like some special tokens, etc? And the third one is that session cookies are only present if the user is currently authenticated with the target website. With these things, we can successfully craft a CSRF attack.

How to Construct a CSRF Attack and CSRF Example?

As we saw above there are three things to keep in mind while framing a CSRF attack, there can be two types of CSRF attacks based on the type of request used to perform the attack.

For example, the GET request, POST request or PUT request, or DELETE request. Generally, GET request is used for CSRF attacks but other types of requests are also used for advanced attacks.

For a GET request we use an HTML element to hide the request such that when the page loads, the request is also sent. This can also be done with an action involving human interaction. For example, using a POST request on a submit button, or any other button such that as soon as the button is pressed, the request is sent.

A sample GET request :

http://example.com/resetpassword?username=victim&newpassword=victim@123

Explanation:
This sample request is generated by the user to reset their password. This request can be modified by the attacker and reset the password to his desire.

The GET malicious request :

http://example.com/resetpassword?username=victim&newpassword=attacker@123

Explanation:
The request modifies the password of the user and the attacker can now access the account and find out other sensitive information.

Now as our request is complete then it is hidden in the HTML, here also most commonly it is hidden under the pretext of the image tag, the visibility of the tag could be set to hide or height and width are set to 0px.

<img src=" http://example.com/resetpassword?username=victim&newpassword=attacker@123" width="0" height="0" border="0">

Explanation:
This image would not be visible on the webpage but when the HTML page is loaded, the request is sent from the browser to the target website. If the victim is authenticated on the website that would result in the attacker gaining access to the target website via password reset.

The real-life application of this GET Request to deploy a CSRF attack was seen in the uTorrent exploit in 2008, where this GET Request was used to access the web console at localhost : 8080 and that was used to inject a backdoor torrent.

Sometimes these GET Requests are blocked by the browser from accessing the required target, hence we use other requests such as POST requests to wrap the malicious request.

To use the POST request, we use HTML forms to submit the malicious request.

Explanation:
In this example the attacker resets the password using a POST request send through a form that is not visible to the victim, they only see the submit button, and when pressed will result in the submission of this form. Usually, this submits button is masked under the cancel button on popup advertisements or the download button on some piracy sites, etc.

In the next example, we will see how to submit a post request without user interaction.

Explanation:
In this example the submit button is called using the JavaScript function that will automatically submit the button while the page is being loaded. This is generally avoided as suspicious JavaScript is sometimes blocked by the browser.

What are CSRF Tokens?

So, we talked about how to attack a website using CSRF, to prevent this vulnerability we have CSRF tokens which are used to protect the websites from cross-site request forgery. This token is a unique, and randomly generated secret value which is generated by a server-side application and sent to the client. It is sometimes referred to as a synchronizer token or an anti-CSRF token. The token is used in every subsequent request the client sends to the server, if the client does not include the CSRF token in the request the server rejects the request. These tokens, therefore, help in preventing CSRF attacks.

This is only one method of implementing an anti-CSRF token, various strategies might be more appropriate for specific use cases.

There are various methods available for implementing an anti-CSRF token that may vary depending on the various strategies that might be more appropriate for specific use cases.

The following example shows one of the following implementations of these tokens on the client side :

There are two patterns of token used that is synchronizer token pattern and encrypted token pattern. The server directly sends the session id to the client and is included in the forms, custom headers, or any other URL parameter sent by the client to the server. The other type is an encrypted token pattern in which the server encrypts the token and timestamp and uses a server-only key, which is decrypted to verify that there has been no CSRF attack.

But nowadays these tokens are not of much use because when implemented incorrectly these tokens are also available to the attacker via XSS attacks. The methods for extracting these CSRF tokens will be covered in the next part. Apart from CSRF tokens we also use the referrer and origin policy verification. Furthermore, user-unfriendly techniques like CAPTCHA and reauthentication are also used to prevent CSRF attacks.

Impact of CSRF Attack

The impact of a CSRF attack is determined by the privileges of the targeted user within the application. The impact of a CSRF attack can be increased by a large magnitude if it is paired with a successful social engineering attack to ensure the success of the attack.

A successful CSRF attack will often bring state-changing requests for the ordinary user, such as changing their password or email address, transferring their money to another account, or making transactions using their credentials.

A CSRF may lead to a complete system compromise if a user with greater rights, like an administrative account, is successfully targeted. This is so that requests for a different order can be submitted using such an account. This demonstrates the scope of a potential attack and the importance of CSRF protection in any web application.

How to Bypass CSRF Protection?

There have been several implementations to prevent cross-site request forgery but these prevention measures are flawed and hence should not be used, now we will see how to Bypass this CSRF Protection.

The first one is using only the POST request for handling sensitive data so that it can not be affected by a CSRF attack. But as we have seen above POST requests can also be generated by an attacker through various ways either through or even without the involvement of the victim by using JavaScript. So if the server is validating the POST request with a session token we can try to change it GET request without the token. And if the server is expecting a GET request, we can try to change it POST request without the token until one of them is accepted.

The second one is using a secret cookie to secure requests sent by the user. But the CSRF vulnerability is based on the logic that all the cookies are sent with a request because the browser is unable to differentiate between a malicious request and an original request.

The third one is instead of passing the token in the cookies or metadata which is vulnerable to attack, the URL is modified to contain the token. But this method also fails because passing the token into the URL makes it vulnerable to a lot of other vulnerabilities.

The fourth one is checking the randomness of the session token, that is most of the time the token is not random and it might be decodable making it easier for the attacker to replicate.

The fifth one would be checking if the server verifies the presence of the token accurately or not, suppose you can change the request and remove the parameter of the session token or modify it to some other value or try sending a blank token or using a session token of some other is the server verifying it or not and based on that CSRF protection can be bypassed.

How to Prevent CSRF Attack?

Employing a CSRF token is the most popular mitigation strategy for cross-site request forgery attacks (also known as a synchronizer token or anti-CSRF token). These session tokens are randomly generated, one-of-a-kind values that the application sends to the client. They are then sent back to the server together with the request made by the client once the request has been verified.

This provides a mysterious component that can successfully neutralize the CSRF attack. Any request that does not come from the original form will not have the right CSRF token value and may simply be ignored.

If utilizing a valid token on the server side is not feasible, a double-submit cookie token technique may be used. In this cookie-based session management method, a website creates a value that, in addition to the cookie that acts as a session identifier, is stored as a cookie on the user's device each time a user visits the website.

The value included in the cookie must match the value in any valid requests sent to the website. The server then confirms this, and if the values match, the request parameter is approved.

The origin from which a cookie may be transmitted is limited by the same-site cookie strategy. Therefore, CSRF takes use of the potential for a cross-origin request (and hence same-site cookies). It is impossible to submit requests to an application from an external origin if the origin to which a cookie is associated restricts requests such that they may only be sent from that origin.

This technique should not be used in place of a CSRF token scheme, but rather in addition to one. Using custom request headers is a method that works especially well for AJAX or API endpoints. This method adds a unique header using JavaScript. Unfortunately, the SOP security limitations prevent JavaScript from making cross-origin requests with a custom header.

Preventing the transmission of a cross-domain request with customized headers renders CSRF attacks impossible.