Let’s go with Cross Site Request Forgery?

Introduction

Users can construct the internet browsing practice by using just a single profile on their favorite web browser. Each profile has innumerous information about their users, for example: session cookies, saved credentials, bookmarks for their favorite web pages, installed extensions and personalized configurations, etc. Through this same profile is possible to open browser tabs or new windows, and this way, keep the connection with your social media accounts, access pages from your history, or just continue your session of music streaming. In general, when you use a single profile all of your internet data is combined and easier to access.

The use of the same profile allows the rise of the user’s attack surface, that’s because this way it can be authenticated – at the same time – in your bank, your corporate email, your personal e-mail and e-commerce web sites; thus, all of those information are centralized in the same profile. Therefore, the chances of compromising your data are magnified. Through a malicious extension, an additional tab for an unknown website or a doubtful e-mail, an attacker can exploit a security issue on the websites that the victim is accessing, resulting in, for example, data theft, since the use of a single browsing profile allows the centralization of the user’s data.

All of this change of profile information is extremely easy nowadays. Let’s analyze the Google Chrome Web Browser as an example, it allows the association of the profile data with an e-mail address. Thus, by using Google Chrome, the authenticated way, in any computer, your browsing data (credentials, preferences, etc.) can be easily restored. Do you think that the users – once they restore those data in a new computer – evaluate if the equipment is already compromised or if it is in a network with high-risk vulnerabilities?

With the expansion in the “work from home” department ( it’s worth mentioning Carlos Cabral’s article: “Cibersegurança no home office em tempos de coronavírus” – Translated: Cybersecurity when working from home during coronavirus) is everyday becoming more ordinary the use of the same computer for managing personal life information and corporate data, thus focusing, in most cases, all this amount of data in a single browsing profile, which ends up putting the user’s sensitive information even more at risk. There are several ways in which an attacker can go through to steal a user’s browsing profile data. Here we’re going to deal with an old vulnerability, commonly called CSRF – Cross Site Request Forgery – whose attack is stealthy, simple to exploit and it can still have a high impact. The CSRF represents the use of counterfeit functionality on a website, since the attacker will deceive and induce the user into making a legit action, however without their consent. This type of vulnerability explores the website’s confidence in the user’s session, which is present in his browsing profile.

According to a survey carried out by OWASP in 2013, CSRF was on the list of the 10 most common vulnerabilities founded in Web applications. This ranking highlights the awareness of information security on websites, the most recent version is from 2017.

From my experience in the field, I can assure that this vulnerability is easily found in a huge number of applications, with the aggravating issue that in some cases, the companies apply incorrect or inefficient solutions to avoid this kind of security issue.

Let’s take a look at this Netflix case, when in October, 2006, it was published the news that the company had sorted out the vulnerability which allowed attackers to modify the users’ address and even steal their accounts through CSRF. At the time, Netflix had 5 million subscribers operating through its DVD rental website. Not many people know that, but Netflix’s history is dated way before it became hugely famous as a streaming platform. In 1997, in California, the company emerged as a physical movie rental business, and revolutionized the market, at first with the rental service on the website – with couriers who both delivered and collected the movies at the registered addresses. Two years later, the company surprised again by charging a fixed monthly fee for their customers, allowing them to order and receive as many movies at home as they wanted. And this is how Netflix transformed their customers into subscribers, increasing not only the number of registrations on their website, but above it all, the amount of access, attracting as well attackers who were searching for user’s data on a large scale. For all of that, the company showed concern with the flaws on their website safety, and quickly delivered a solution for the security issues reported by the researcher Dave Ferguson, which could lead to the theft of the information of their millions of users.

Goal

The goal of this blogpost is to bring information about CSRF in a direct approach, thus, presenting a general vision about the possible impacts, and the attack scenarios. I will discuss the implemented solutions that I came across, and unfortunately, don’t protect against this kind of issue. Finally, I’ll present the recommendations ideas for the web applications surrounding the CSRF, also known as sea surf, XRSF, session riding or one-click attack.

Impact

The exploitation of this security problem can be summed up in an attacker inducing the user to perform an action without his consent. The degree of the attack’s impact will depend on the level of privilege that the user has on the target website, and also, on the functionality chosen to perform it.

So, let’s assume the following scenario:

We are dealing with a digital wallet application, which means, a financial application with cash transactions and credit card management. Let’s call it “DigitalLeatherWallet”. This application has at least three already known vulnerabilities, namely: a user enumeration (which makes it possible to collect users’ emails) on the authentication page, the possibility of changing critical data without providing an authentication factor, and the CSRF.

The first step of the attacker is to identify a valid user on the website through the users’ enumeration. Then, the attacker shoots an email to the victim previously chosen. This email will contain a link to an application of his possession, showing an ordinary sale. When the victim accesses this page, a request to the DigitalLeatherWallet functionality will be triggered (where the legitimate user is properly authenticated in a browser tab on the same profile of the website being accessed). The request in question has the ability to change the victim’s email address (in this case from [email protected] to [email protected]). Since the application has no request for an authentication factor to do the exchange of registration data (the access password, for example), it is easy for the attacker to make this forgery on behalf of the legitimate user. The following image shows the issue described previously:

Image 1 – Diagram for the exemplification of a CSRF.

In short, a legitimate user finds himself authenticated in his financial application on an ordinary tab on his browser. Which also, has another browser tab for a news website and one more for the malicious website. This way, as noted in step 3 of Image 1, by accessing the malicious website, the request for the e-mail alteration functionality is made. The digital wallet allows the change of the authentication password and transactional operations through a “forgot the password” functionality. This functionality sends the password reset link to the newly changed email, which belongs to the attacker. Then, the attacker steals the credential of the target platform, and becomes able to do financial damage with improper access.

The security problem

Let’s take in consideration another scenario:

A web application called OfficialSite manages financial information for a large institution. A user with administrative permission is properly authenticated and uses the functionality of adding a new user for a new member of the team. The Image 2 represents this scenario and some information about such flow:

Image 2 – Representation of the application and the request and response flow of the server.

When the functionality mentioned above is used, an HTTP request is fired up to the application server, where the order is successfully processed and executed. The previously referred request can be seen on Image 3 in more detail. It’s worth mentioning that such a scenario also has a communication through a secure channel using HTTPS (the famous green lock beside the website address in the browser). In this situation, the user’s station and the network to which he is connected are not compromised by malicious agents.

The parameters utilized for the addition of a new user in the referred system are: Name data, user, type of user, password and password confirmation.

Image 3 – HTTP request for “adding a new user” functionality.

The intention of the attacker is to perform a forged request shown previously through another website, inducing the victim’s browser to execute the action without the user’s consent. Image 4 shows the code snippet that the attacker built on his malicious webpage, where he defines the parameters values:

Image 4 – Code snippet for a malicious webpage. It’s only one of the examples that can be built by attackers.

Once the malicious page is accessed in the same browser profile in which the victim is authenticated in the OfficialSite application, the page will automatically submit the form illustrated in Image 4 to the target application. Thus, the function to add a new user will be performed without the victim noticing. That’s because the victim’s browser will automatically insert the session cookie, “SesseionId” (shown in Images 2 and 3), for the vulnerable application, OfficialSite.

Now that the attacker has an account with administrative privileges, he can expand the impact of his attack from the functionalities provided by the application.

Using a functionality called Generate CSRF PoC from Burp Suite, which is a very usual tool in the arsenal of information security analysts, you can easily generate a malicious page containing the form to be submitted to an application. Image 5 demonstrates how this tool can create the mentioned page:

Image 5 – Burp Suite proxy – creation of a CSRF PoC

The referred function generates a code snippet, as previously illustrated in Image 4, and with two clicks it’s possible to perform the described vulnerability test.

“Failed” Solutions

The companies take some actions that are not, at all, effective to correct the problem, such as new cookies called “Anti-CSRF”, which doesn’t make sense, once the attack uses precisely the victim’s cookies to perform a certain action. They also attempt to resolve the vulnerability by inserting multiple steps into their application to finalize an operation, but this also doesn’t work as a protection against CSRF.

So, to prevent the attacker from creating a forged request in order to obtain success by inducing other users’ actions, a secret token must be added on the requests made by the application. Thus, an attacker, at first, won’t be successful when submitting a form such as the one in Image 4 without this token, since he won’t have access to its value. This way, the application will start to send this token when requesting for alteration, creation or removal of something relatively critical.

However, some problems on this correction model can be found on sites that use aforementioned tokens. Here’s a list with a couple of them:

The secret Anti-CSRF token is only validated on requests using the POST method, leaving requests that uses the GET method vulnerable;
When the server doesn’t verify the token, it can be deleted from the request;
The token is not tied up to the victim’s session and is simply distributed from an application’s global pool, making it possible for the attacker to use his secret token to perform an action on another account;
The possibility of reusing this token, leaving a fixed value on all requests;
The use of a predictable token.

These are just a few examples of problems in this correction model, since the intruder will always try to subvert the imposed validations. That’s why, security assessments (both automated and human driven) on the applications security are extremely important, not only for the identification of weaknesses, by alerting for inefficient corrections, but also, for analyzes aimed at presenting safer solutions for each case.

Recommendations

It is recommended to shield the application server from receiving requests that have not been originated by the legitimate user in the website’s environment. Among the possible solutions to this problem, unpredictable and for ‘single use’ tokens must be implemented, inserted in hidden fields in HTML forms, which need to be validated on the application server as a way to impose a challenge. So, each request, besides validating the sessions cookies, must as well verify if the challenge token was correctly received when submitting the form. It is important that for every request made, a new token is provided by the server. This mechanism is called the “Per-Page Token”. This token is for single use and must always be verified in all operations of the application. Image 6 shows an example of a Token in a HTML form.

Image 6 – HTML token in an application operation.

It’s worth mentioning that we’re talking about a “blind” attack, where the attacker won’t be able to obtain confirmation of the success of the action (immediately), for example, an answer of the operation, since the access to documents from another domain is restricted by “same-origin policy”. Then, due to this policy, the attacker won’t be able to obtain the values of the secret tokens that are associated to the user and his session.

Another layer of defense is the use of the sameSite attribute of cookies. This configuration is responsible for making the browser decide whether the session cookie information will be sent for requests that are coming from other applications outside its domain. The possible values for this attribute are: Lax, Strict or None.

The use of the Strict value in this attribute prevents the browser from sending the cookie if a counterfeit request tries to be performed (Image 7).

Image 7 – Server sending the cookie with the necessary attributes to protect CSRF.

However, it is worth mentioning that this “sameSite” implementation in the cookie, despite being present in the most used browsers, may not be present in all browsers, in the same way as presented in this resource. Therefore, in some cases, the mechanism will be useless if the victim is using a browser incompatible with the attribute.

Another alternative is the implementation of a custom field in the HTTP request header, such as an “X-CSRF-Header-field” (Image 8).

Image 8 – Custom field in the HTTP request header.

This type of defense is supported by the ‘same-origin’ policy, to restrict other sites from including the custom header field in the counterfeit request, working perfectly for AJAX or API requests (seen in most applications nowadays). For the protection of HTML form documents, as it was demonstrated in the “OfficialSite” scenario, you can use the tokens mentioned in the first paragraph of this Recommendations section.

These are some examples of recommendations ideas for dealing with the security issue against CSRF and it will depend on how the application is being built. That is why it’s so important to perform security in layers, so that they can adapt to the development scenario. Other protections can be found in this “list“.

Conclusion

Finally, besides everything that was already mentioned throughout this article, we reassure that the implementation of several security layers is always important. A motivated attacker who has the time, will always search for means of subversion in the applied protections.

We always recommend following good security practices, assessing the risks and reducing the attack surface to the maximum. Going back to the observations reported at the beginning of this blogpost, as an initial security measure, and quite simple if I say so, in order to avoid a greater impact due to a CSRF failure, we emphasize to users the importance of separating the navigation profiles. It is important, at least, to separate the professional profile from the personal profile. You can also create other profiles: one just for research, another for online shopping, etc. In addition, of course, you should always be aware of what is installed and accessed on your device.

I would like to emphasize that in this article we are dealing with a very old web application security problem, but one that still causes negative impacts on its victims today. There are several other techniques related to the CSRF, however the purpose of this blogpost is limited to providing an overview of only this kind of vulnerability.

With the evolution of software development and the appearance of several frameworks, which aim to optimize the construction of web applications, it is quite common for such resources to promise to solve numerous security problems, whether they are new or old. However, we need to remember that these resources are built through the human factor, which can end up presenting new problems or even suggesting improper corrections for such problems, since anyone is feasible to error.

Given the fast pace with which our generation develops new digital products, it is becoming increasingly essential to build websites without these known vulnerabilities, such as CSRF.

For those who are building: remember to always have the security requirements added to the operational requirements of an application.

And for those who are accessing: evaluate the use of different browsing profiles, be careful when entering unknown sites, always being cautious before inserting your credit card in any application.