Validating CSRF vulnerabilities reported by automated scanners
How to manually validate CSRF vulnerability and avoid noise from the automated tools
Cross-site request forgery (CSRF) is a client-side attack that is also known as a one-click attack and is ranked at position 8 in the current 2013 OWASP Top 10 list of vulnerabilities. In this type of attack, an attacker can make users into unsuspecting victims by executing unwanted actions on a web application that they already have access to. This attack takes advantage of a victim's already-authenticated session in the browser and is specifically carried out on state-changing requests.
“This tutorial covers how to manually validate a CSRF vulnerability that is reported by an automated security scanner. This tutorial also provides guidance on how to use the open source tool "CSRF Tester" that provides a rich functionality to validate such vulnerabilities.”
What we'll cover
This tutorial covers how to manually validate CSRF vulnerability that is reported by an automated security scanner. For the purposes of this tutorial, I use IBM AppScan as an example. Most automated scanners, including IBM AppScan, do not actually accurately report CSRF vulnerabilities as they are built on predefined rules and cannot determine completely the legitimacy of certain types of vulnerabilities.
To validate such issues, you need to manually reproduce the vulnerability and decide whether it is indeed a true or false alarm.
This tutorial illustrates a step-by-step guide on reproducing and validating the reported CSRF vulnerabilities by using a custom-made flow chart. This tutorial also provides guidance on using the open source tool "CSRF Tester" that gives rich functionality to validate such vulnerabilities.
Who can benefit from this tutorial?
This tutorial is helpful for web developers and security testers. Read on to learn how CSRF attacks work, how you can exploit these attacks, and how to configure web servers/application to prevent this vulnerability. In short, this tutorial will enable all who are interested in protecting their applications from CSRF attacks.
What is CSRF?
CSRF is a client-side attack, also known as a one-click attack and is ranked at position 8 in the OWASP Top 10 list. In this attack, an attacker makes victims (an end user) execute unwanted actions on a web application that they already have access to. This attack takes advantage of a victim's already authenticated session in the browser and is specifically carried out on state-changing requests. They exist because developers are either not conscious of the cause and seriousness of CSRF attacks or they do not have the bandwidth to address this cause. A successful CSRF exploitation relies on these three conditions:
- The victim is convinced or tricked into executing the attacker's desired action through social engineering methods, such as a CSRF link in chat, email, comment, and more.
- The victim is authenticated against the target site.
- The victim is present on the same browser, while he/she performs the desired action.
How does AppScan report CSRF vulnerabilities?
AppScan changes the value of a referer header to "bogus.referer.ibm.com" and verifies response header. If the server accepts and responds with valid response code (in this case 200 OK). So, it assumes that application does not track the originated source of the request. Since it is easy to spoof the value of a referer header, it is possible to perform CSRF.
Most automated scanners do not accurately report CSRF vulnerabilities, as they are built on the rules that cannot completely determine the legitimacy of certain vulnerabilities like CSRF. Automated tools generally identify vulnerabilities on the few of the logics, such as:
- Whether the application solely relies on HTTP cookies to authenticate the user.
- Whether it relies on the referer value to check whether it is originating from trusted source.
- Whether the application accepts and responds to HTTP requests without CSRF tokens.
With this logic, scanners alert users about potential or uncertain CSRF vulnerabilities. Also, CSRF attacks are specifically carried out on state-changing requests. However, since scanners cannot understand if the submitted request is state-changing or not, they fail to report accurate results. To be completely accurate in identifying possible vulnerabilities, testers must manually examine the requests and perform a few more tests to be certain.
The following flow chart illustrates the steps to validate or identify any CSRF vulnerability in the application.
Validating CSRF vulnerabilities
False positive cases
Below are some examples of false positive cases that were reported by AppScan.
Test case 1: Nonstate-changing GET/POST request
The image above shows the GET request is fetching data from the server and is not performing any action.
Following the flow chart, check the first condition. Is the request state-changing? If it's not, it is a straightforward case of a false positive. Since there is no state-changing activity that's involved in the request, no CSRF can be performed at this time.
The above image shows the POST request and performs no action.
Test case 2: State-changing PUT request
The following image below is a screenshot for test case scenario 2, where we have a state-changing PUT request.
In the image above, we see a state-changing PUT request that seems to be enabling/disabling the state. Let's see whether this can be validated.
Let's refer back to the flow chart again.
If the HTTP method is GET> No
If HTTP method is POST> No >
For all other methods
Is CORS is enabled on the server> No
- (As there is no Access-Control-Allow-Origin header present in the response header, this turns out to be a false positive.)
Test case 1: State-changing PUT request
In this case, we see that the password changed, which means that this is a state-changing request. Let's refer back to the flow chart and see what we can figure out:
If HTTP Method is GET> No
If HTTP method is POST> Yes
- (Move to the next condition.)
Content-Type is xml/json> No
- (The Content-Type is application/x-www-form-urlencoded.)
CSRF token present?> No
- (Since CSRF token is not present, we can move forward and generate CSRF PoC.)
So far, everything looks good. This means that there is a probability of exploiting CSRF in this request. So as suggested in the flow chart, let's create a PoC (Proof of Concept) and validate the CSRF. There are different open source tools available for testing CSRF. For this tutorial, we will use the OWASP CSRF Tester. You can download this free tool here:
Once you download the tool, click the batch file "run." It should open a GUI, as shown in the following image below. It runs in a Java™ environment, so you will need to install Java.
From the above image, we can see that the tool started the proxy server on port 8008. So we also need to set the browser proxy to 8008. Now whatever we browse in a web browser will pass through the proxy server. We are now ready to test CSRF. Below are the steps to reproduce the vulnerability.
- Log in to the application and navigate to the affected URL page.
- Submit the form and observe the request with the form parameters in the CSRF tester. Click the “Generate HTML” button.
- This creates an HTML file with the POST request. Edit the HTML file with editor and change the value of the form parameters.
- Now open the edited HTML file in the same browser, where the session is authenticated. Observe the message on the page “Password changed.”
The above image shows that the CSRF attack was successful. Like this, you can use the flow chart to validate CSRF vulnerabilities that are reported by any automated scanner.
CSRF is widespread in today's data-rich web applications and should be addressed before it damages to the web-applications. The impact of a successful CSRF attack is subject to the functionaliities exposed by the vulnerable application. For example, successful CSRF attack could result in a transfer of funds, changing a password, Adding/Deleting a user or purchasing an item in the user's context.
There are various techniques available to defend against CSRF attack, depending on the programming language the application built in. The OWASP CRSRF cheat sheet in the Related Topics below provides some common guidelines to protect web applications against CSRF attacks.
- Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
- Other dW articles on OWASP
- Join the IBM Security AppScan on developerWorks community
- Download a free trial of AppScan