CSRF Attack Cross-Site Request Forgery

An overview of CSRF Attack

A counterpart of XSS, CSRF is one of the multiples concerning cyber vulnerabilities wherein the authorized users are compelled to perpetrate something unaccepted or unauthorized action on the website that has authenticated them. By using two-factor login, password, and other means, a website authenticates the end-user and permits them access to the services/facilities of the website/application. This way, trust is built between end-user and websites.

Threat actors use this trust factor to gain unauthorized access to the website by exploiting it via a CSRF attack. CSRF has many synonyms including Hostile Linking, Sea Surf, Session Riding, One-click attack, and so on.

The attention-worthy markers of CSRF attack areas cited below -

• It is easy to carry out on websites/web applications that skip validating if action is with or without the user's consent.
• While XSS concerns breach of user’s privacy by a website, CSRF relates to the circumstance where the user exploits the website. One must gather more information in XSS v/s CSRF for distinguishing between these vulnerabilities at a deeper level.
• It doesn’t interest using JavaScript or any other sort of code for successful execution.
• Single-page applications are likely to have a higher chance of being a CSRF victim as they store the CSRF token as cookies, which are favorite of the threat actors.

What is a CSRF token?

Crucial to keeping the occurrence possibility of CSRF attack as low as possible, CSRF token is a secure, and unique per-session token that is created at random. Challenge and synchronizer tokens are among the most common examples. 

CSRF token must be integrated inside the hidden/invisible components of HTML forms that are used for server-side functionalities and are shared with the end user’s browser. Its volume must be huge so that threat actors can’t make sense out of it.

The CSRF-enabled websites and web apps will generate exclusive CSRF tokens for individual HTTP requests or login sessions. 

Correct validation of CSRF tokens will discourage CSRF attacks. However, certain factors are impacting the CSRF token validation.

Validation is highly influenced by the type of request. For instance, some websites will completely validate HTTP post requests while rejecting the GET ones.

Availability of the tokens also affects the validations. For example, if no token at an instance of time, the request is ignored.

How does CSRF work?

Carrying out a CSRF attack requires fulfilling 3 conditions.

1. A privileged action happening on the website, such as, an action causing altering user-focused data.
2. The target site, during the user identity validation, must use at least 1 HTTP request while session cookies also are enabled.
3. No part of user request is hidden or non-readable for the attacker.
   

Once all these three conditions are fulfilled, one is ready to execute the CSRF attack.

CSRF is highly diverse when it comes to tricking the user to initiate a forgery request. Before understanding these ways, let’s know how to create the ill-intended request with the help of an example.

Example

Say John needs to transfer $500 to Jena via the money.com website. 

Now, the money.com website is not backed by robust CSRF protections and a threat attacker, Leo, uses this opportunity to receive the money that John is trying to transfer.

To make this happen, attacker, Leo, will move ahead as:

• Creating a manipulated script or URL
• Luring John to use the corrected URL/script via social engineering
  

Now, let’s understand the working of CSRF attack under different scenarios:

When website accepts GET requests 

In that case, the money transfer request, made by John, will look like: 

GET http ://money.com/transfer.do?acct=JENA&amount=500 HTTP/1.1

Leo, the threat actor, will exploit this via John. Firstly, he will create a manipulated URL to direct John-initiated money transfer to his bank account. 

He will access the transfer command of John and replace Jena’s name with his. He can also alter the transfer value. The exploited command will look like:

http ://money.com/transfer.do?acct=LEO&amount=5000

In the exploited URL, Leo replaced the original transfer value with $5,000. 

Here, social engineering gambits like email featuring HTML content or placing the abused URL in front of the verified page fools John to load the exploited URL. As the altered page/URL/script looks very similar to the original URL/script/page, it’s easy to get fooled. 

When websites accept POST requests 

If the website obtains only POST requests then the John’s command will look like this:

POST http://money.com/transfer.do HTTP/1.1 
acct=JENA&amount=500

Now, such request is delivered with FORM tags: 

<form action="http://money.com/transfer.do" method="POST">
<input type="hidden" name="acct" value="Leo"/>
<input type="hidden" name="amount" value="5000"/>
<input type="submit" value="Check my pictures"/</form>

Use of FORM tag enforces clicking on submit button for completing the request submission. Or, the request can be presented automatically with the usefulness of JavaScript. 

When a website is using other HTTP methods 

Other than GET and POST, other HTTP request modes like PUT and DELETE are also used frequently. PUT-based HTTP requests will feature JavaScript in the manipulated page/URL. As advance browsers that we all are using presently enforce the same-origin policy, CSRF attacks on PUT and DELETE requests are not usually witnessed. 

The Aftermath of a CSRF attack: What happens to the Victim?

The outcome can be trouble-causing for the targeted user. The success of an attacker will result in the completion of an action that the victim never intends to do. So, the severity of this action will depend upon what that action was. 

Also, if the person, who was targeted through this attack, is an organizational user with high-level rights in a business network, the loss due to CSRF’s success will be much bigger. It may result in monetary transactions, data compromise, functionality misuse, and much more.

A few examples could be:

• Editing the victim’s e-mail details for an account and thereby using their identity for financial transactions or on social media. 
• Performing an unsolicited transaction from a user account.
• Modifying the access-rights of various user roles in an organization after gaining access to the admin account.

‍

Constructing and Delivering a CSRF attack

1. The Construction/Design

Let’s begin with understanding how this sort of attack is designed or strategized in general.

The conventional method to carry out a CSRF exploit is to create a custom HTML request comprising a high parameter count. However, due to the complexity of this method and the time it takes, very few high-end attacks use it.

Most of the attackers use a CSRF PoC generator - the simplest trick to succeed at a CSRF exploit. This tool comes as a part of Burp Suite Professional and can be used by following the below-enlisted steps: 

• To test/exploit a request, find it in the tool.
• Right-click on this request and then on Engagement tools.
• Pick your option as ‘Generate CSRF PoC’ and the tool will create the HTML content in order to initiate the action. This won’t involve cookies, as your browser may or may not have different settings than the victim’s browser. 
• Now, you can either modify this HTML content by changing the selections for different options in the tool to customize your attack or copy the same content into a webpage.
• View this page with this HTML content in a browser and test if it is working as you want it to.

2. The Delivery

Now that you have the HTML content for carrying out the attack ready, the next step is to deliver it to the victim and hope for your success. 

The method for CSRF delivery is very similar to reflected XSS exploits. So, you – as a threat-actor or tester – will embed this malicious content in a web page or email, or an SM text in order to deliver it to the victim. You may even add it to a popular site or forum as a comment if you want the exploit to be untargeted.

Typically, the simplest of CSRF attacks utilize 1 GET request. So, this HTML content can be just 1 URL. For example, this type of self-contained exploit may appear like this:

<img src="https: //example.com/email/change?email=example@test-csrf.user">

To succeed, you just have to make the victim click on this image.

‍

How to detect cross site request forgery?

Regardless of the type of vulnerability, early detection is the key to keeping the damage under control. 

The most practicable makers that help in the timely detection of CSRF are:

• Websites allowing session management through GET requests. Third-parties can get easy access to such sites. So, they are more prone to CSRF attacks. Make sure your site is not among them.
• Web Proxies are very helpful in CSRF detection. As it keeps track of HTTP requests’ journey from beginning to end, you can replay requests without initiating an interaction with the client-side interface of the app.

How to Prevent CSRF Attack?

When not dealt first-handedly, CSRF attacks can lead to data threats, money stealing, change of login details, and even losing control over crucial applications. Hence, along with the early detection, doable CSRF prevention strategies should also be deployed. 

CSRF-token-based prevention

The primary approach to defend a CSRF attack is to figure out whether or not the HTTP request is created legitimately i.e. using the user interface of the app only. CSRF tokens can be utilized by website owners or administrators for it.

The app security team should figure out the attack-prone part of server-side functions and introduce the CSRF token in the HTML form of that vulnerable operational part.

Make sure that the intended HTML form is not a component of session cookies. Also, utilize a cryptographically secured random number generator for token-creation.

Utilizing the SameSite Cookie Attribute

It is generally used for supporting CSRF attack prevention methodology greatly. Sharing a lot in common with Secure Flag and HTTPOnly, it equips the browser adequately for handling the cookies as well as cross-site requests at once.

Its acceptable values are as enlisted:

1. A ‘Strict’ value will stop cookies transfer by browsing.
2. ‍‘Lax’ is the default value that maintains security for web solutions when they wish to allow user-access requests composed of external links. Presently, most browsers have this feature as an added line of defense against CSRF attacks while using the CSRF token alongside. 
3. The value ‘none’ is used you want to use cookies for accessing cross-site URLs.

Utilizing user interaction for CSRF protection 

It is the easiest way to implement a CSRF prevention strategy. It involves the use of re-authentication, one-time token creation, and CAPTCHA deployment. All these techniques increase user interaction and leave less scope for threat attacks to barge in. Also, it enhances the user experience.  

Controlling Login CSRF 

Many developers fail to understand the fact that CSRF can exist in the login forms and cause damage. This is why it’s mostly ignored. One can prevent CSRF from impacting the login forms by generating pre-sessions for each user and introducing CSRF tokens in those sessions. It makes the early authentication safe. But, ensure that this pre-session should be destroyed once the real session is initiated. Ignoring this will give invitation to the session-fixation attack. 

Double submit cookies 

This method is commonly used as a CSRF defense strategy. It involves storing the similar token values in a cookie rather than a server session. Doing so encourages the cookie-like CSRF token forwarding while associating a hidden field/value with it. Upon receiving a request, the server needs to figure out whether the CSRF value, stored in hidden fields and cookies, matches. 

How to prevent CSRF attack in Javascript?

Security experts willing to prevent JavaScript from CSRF attack can use custom request header as it banks upon the SOP or Same Origin Policy approach in order to safeguard the JavaScript part of the app. This header can only be implied on the origin of JavaScript. However, JavaScript is not allowed to create custom headers by default by the browser.

This approach brings dual benefits like there is no need to do any changes in the UI and don’t ask for presenting the server-side state.  

Is it necessary to protect API from CSRF attacks?

CRSF attacks are on an all-time rise and there are no exceptions. 

As API usage has increased and is crucial for web and mobile application development, it has become a prominent target for CSRF attacks. When an API is a victim of a CSRF attack, the whole digital solution or app is put on the stack. 

For robust API security, it’s crucial to protect API against CSRF attacks. CSRF attacks targeting the APIs can be prevented easily. 

API requests made to the content-type application or JSON should be restricted. With this, the possibilities of CSRF attacks are less. API requests, done via content type, are more secure.

API access token should be presented on the request header. Also, APIs should neglect the cookies-based CSRF tokens. 

JavaScript-based single-page applications should be constructed only to use cookies for storage. Such applications should also complete the authentication token transfer to API as header and shouldn’t accept the requests missing the header.