CSRFDtool: Automated Detection and Prevention of a Reflected Cross-Site Request Forgery

Published Online October 2014 in MECS

During the last five years, many efforts have been made by researchers to confront at this attack. Many researches have been published and many solutions have been proposed and developed. However, being one of the top ten threats in OWASP is a strong indicator that these solutions have limitations because the attackers are still capable of enforcing CSRF. Although these solutions seem to be efficient in stopping this attack, but clients and developers do not use them in their browsers and websites respectively [9]. This is probably because of the overhead introduced by the proposed solutions in terms of time and space.

This paper proposes a Google Chrome Extension that is able to eliminate a specific type of this attack which is Reflected CSRF. Google Chrome Extension gets the required information of web browser (tab ID, browser window ID and IP address) that is used by the user to login to a website, and then it concatenates this information with an active session to prevent any attack from different sources such as different taps in the same window.

This paper sections arranged as follows: section 2 is an overview of CSRF attack. Then section 3 discusses different solutions were proposed for detecting and preventing this attack. Section 4 states the problem and the hypotheses. The solution methodology and their test are discussed in section 5 and 6 respectively. Authors’ simulator is presented in section 7. Then section 8

discusses the results. Finally, section 9 concludes this paper and suggests future work.

• II.    Overview of cross site request forgery

  CSRF also may be abbreviated as XSRF. This attack also known as one-click attack or session riding. In the beginning of 2001 the first CSRF attack was registered. CSRF is an attack that forces the user’s browser to perform unwanted request or action without user awareness by exploiting the valid session between the browser and the server [5]. Fig. 1 illustrates this attack.

Fig 1. CSRF attack mechanism.

Consider the following scenario: a user login to a bank website using an individual username and password. Bank web server verifies user authorization for requested service and initiates a valid session with client. Attacker uses illegal strategies to deceive the novice user or even the experts to send unintended money transfer request by attract them to a trap (fake link) which is hosted on untrusted third party server. When the user clicks that link, the CSRF attack started [10].

Here is an example of an attack that aims to transfer an amount of money without the user's consent:

• •    Let us say that the next link is the link for transferring money from account to another: http://hackedbank.com/transfer.php?account=sender &amount=amount&for=reciever

• •    The harmful link will be hidden behind image tag as: http://hackedbank.com/transfer.php?accout =sender&amount=amount&for=reciever">

Despite this attack appears easy, it requires a hacker to know many things to be able to implement the attack successfully. For example:

• •    Attacker must find a bank website that does not validate the referrer header.

• •    Then Attacker must be aware of the form submission that used for money transaction and the attacker should be able to write the values correctly.

• •    Finally, the attacker must find a smart and perfect way to attract the user to the harmful link, then to lure her/him to click the element that start the attack and trigger the malicious code of CSRF attack [5].

The actual steps followed by attacker are:

• •    First: Attacker has to study the target website in order to understand its functionality. For example, it is so helpful to know the structure of the form used for money transaction on bank website.

• •    Second: Understanding the functionality is still not enough where attacker has to identify the weakness and vulnerabilities of the target website. He can expose the old cookies or exploits the weak protection.

• •    Finally: Attacker has to test the malicious code to ensure it works as desired.

There are two types of CSRF attack (reflected and stored) [11].

• A.    Reflected Cross-Site Request Forgery

This type of CSRF attack is the main subject of this paper. In reflected CSRF, the malicious code could be injected in a fake website by the attacker which emulates the target one. Then, it can expose the valid session between the user and the genuine website [8]. Attacker has to trick user to click the malicious link that will trigger the malicious code. Reflected CSRF is well illustrated by using data flow diagrams in [2, 5]. Fig. 2 depicts this attack.

Fig 2. DFD model of reflected CSRF attacks

• B.    Stored Cross-Site Request Forgery

In stored CSRF attack, the malicious code already exists in the genuine webpage. It can be downloaded from a trusted web server. Stored CSRF can be found in blogs and forums [8].

For both types of CSRF, the malicious code may be hidden under several HTML tags (e.g. IMG, SCRIPT, IFRAME or Image Object) [5].

The difference between both is very clear, it is in the way by which the malicious code is being delivered. First type is triggered from third party domain (untrusted domain), while the second is executed in the same domain (targeted domain). The common factor between them is “both require knowing the target website’s functionality” [12].

• III.    Literature review

In the last five years, there have been a lot of proposed and developed solutions in order to protect users against CSRF attack. These solutions adopt different techniques. This section discusses three different solutions, that are seems similar to the proposed solution in this paper and similarities and differences between them are explained.

Regarding to the overhead issue, there is a performance overhead as a result of implementing three exponentiations and two hashes. In addition to this, the proposed solution was not implemented; therefore, there are no evaluation results about the effects of this solution. When the trusted session started, the browser does not except any manual changing of the address in that tab until the session end. Masaru's solution based on using secret keys for both browser and server and each server should register in a common deposit agent that holds all secret keys for all servers which is relatively hard to implement. Moreover, the browser should retrieve the secret key for server for each request. The connection with the deposit agent infrequent will impose more performance overhead.

Our research proposed a solution relies on useful information that can be provided by the browser directly without intervention of any third party. This information helps to differentiate each session with its startup tab and other information.