Cross-site request forgery (CSRF) is often confused as a vulnerability that is similar to XSS. XSS exploits the trust a user has for a particular site, which makes the user execute any data supplied by the website. On the other hand, CSRF exploits the trust that a site has in a user's browser, which makes the website execute any request coming from an authenticated session without verifying if the user wanted to perform the action.
In a CSRF attack, the attacker makes use of the fact that the user is already authenticated to the application and anything the client sends will be regarded by the server as legitimate action.
CSRF can exploit every web application function that requires a single request within an authenticated session, if sufficient defense is not implemented. Here are some of the actions that attackers perform through a CSRF attack:
- Changing user details such as e-mail address and date of birth in a web application
- Making fraudulent banking transactions
- Fraudulent upvoting and downvoting on websites
- Adding items in the cart without the user's knowledge on an e-commerce website
Successfully exploiting the CSRF flaw depends on several variables:
- Since CSRF leverages an authenticated session, the victim must have an active authenticated session against the target web application. The application should also allow transactions within a session without asking for reauthentication.
- CSRF is a blind attack and the response from the target web application is not sent to the attacker but the victim. The attacker must have knowledge about the parameters on the website that would trigger the intended action. For example, if you want to change the registered e-mail address of the victim on the website, as an attacker you would have to identify the exact parameter that you need to manipulate to make the changes. Therefore, the attacker would require proper understanding of the web application, which can be done by interacting with the web application directly.
- The attacker needs to find a way to trick the user to click on a preconstructed URL or to visit an attacker controlled website if the target application is using the
POSTmethod. This can be achieved using a social engineering attack.
The third point in the attack dependencies discussed in the preceding section requires the victim browser to submit a request to the target application without his or her victim's knowledge. It can be achieved using several ways:
- Image tag is one the most common way to achieve it and is often used to demonstrate a CSRF vulnerability. The attack methodology would be the attacker tricking the victim to visit a website under his or her control. A small image is loaded on that website, which would be performing the fraudulent transaction on behalf of the victim. The following code is one such example:
<imgsrc=http://vulnerableapp.com/userinfo/[email protected] height="1" width="1"/>
The height and the width of the image is set to only 1 pixel; therefore, even when the image source is not a legitimate image, the victim won't be able to identify it. The e-mail address of the user in the application gets updated to
[email protected]. This technique only works for theGETrequests. - The same technique can be used using the script tag. The script executes when the evil website is loaded on the user's browser and it performs the transaction behind the scenes.
- For a website using the
POSTmethod, the steps are more difficult. The attacker would have to use a hidden Iframe and load a form in it, which would execute the desired function on the vulnerable web application. An example is shown here:<iframe style=visibility:"hidden" name="csrf-frame" ></iframe> <form name="csrf" action=""http://vulnerableapp/userinfo/edit.php" method="POST" target="csrf-frame" <input type="hidden" name="email" value="[email protected]"> <input type='submit' value='submit'> </form> <script>document.csrf.submit();</script>
Many people get confused when they read about the attacker's website submitting a form to another website not in its domain. Remember the same origin policy is discussed in the section, Overview of cross-site scripting of this chapter and how XSS gave birth to it. A very important point to keep in mind is that same origin policy does not prevent the browser from submitting a form across domain. It only prevents scripts from accessing data across domains.
The description of CSRF vulnerability clearly suggests that it is a business logic flaw. An experienced developer would create web applications that would always confirm with the user at the screen when performing critical tasks such as changing the password, updating personal details or at the time of making critical decisions in a financial application such as an online bank account. Testing for business logic flaws is not the job of automated web application scanners as their work on predefined rules. For example, most of the automated scanners test for the following things to confirm the existence of a CSRF flaw in the URL:
- Checks for common anti-CSRF token names in the request and response
- Tries to infer if the application is checking the referrer field by supplying a fake referrer
- Creates mutants to check whether the application is correctly verifying the token value
- Checks for tokens and editable parameters in the query string
All the preceding methods used by most automated application scanners are prone to false positives and false negatives. The application would be using an entirely different mitigation technique to defeat the CSRF attack and thus render these scanning tools useless.
The best way to analyze the application for CSRF flaw is to first gain complete understanding on the functionality of the web application. Fire up a proxy such as Burp or ZAP, and capture traffic to analyze the request and the response. You can then create a HTML page, replicating the vulnerable code identified from proxy. The best way to test for CSRF flaws is to do it manually.
The good people at OWASP have tried to make the manual testing easier through the OWASP CSRFTester project. Here are the steps to use the tool:
- Download the tool from https://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project. The instructions for the tool are provided on the same page.
- Record the transaction that you want to test for CSRF using the inbuilt proxy feature of the tool.
- Using the captured data, edit the parameters and their values that you suspect of been vulnerable to CSRF.
- The CSRFtester tool would then create a HTML file. Use this HTML file to build an attack using the methodology discussed earlier.
The pinata-csrf-tool hosted at https://code.google.com/p/pinata-csrf-tool/ is another tool that we often use to create POCs for CSRF flaws.
Here, we will discuss a few mitigation techniques for the CSRF attack:
- CSRF attack is easier to execute when the vulnerable parameter is passed through the
GETmethod. Therefore, avoid it in the first place and use thePOSTmethod wherever possible. It does not fully mitigate the attack but makes the attacker's task difficult. - In the attack methodology we discussed, the attacker creates a new web page and embeds a HTML form in it, sending requests to the vulnerable application. HTTP referrer is sent by the browser whenever a client is directed to a specific page. If the application is designed to check the HTTP Referrer field, it could prove to be a useful defence as it will drop the connection since it was not referred by a URL in the same domain.
- Before executing a critical task, make use of captcha because a user would have to manually pass the test to continue further.
- Implementing unique anti-CSRF tokens for each HTML form as the attacker would be unaware of the unique value of the token.
- Critical websites should be protected with short session timeout values. The shorter the session, the less chance the attack would be successful because the victim would not be logged in the application to execute the attack.