Since its formal recognition by the security community in 2007 on the OWASP Top Ten list, Cross Site Request Forgery (CSRF) has stepped out of the shadows and joined the ranks of vulnerability all-stars like Cross Site Scripting (XSS) and SQL injection. As a result, there has been a big push to better understand how CSRF works, how to prevent it, and how to perform traditional attacks against web applications that attempt to protect against it. Below I’ll provided a high level overview of the first two topics and a step-by-step walk through for the third using Burp Proxy.
What is CSRF and how does it work?
In short, CSRF attacks allow the execution of existing web application functionality without the user’s knowledge if the user has already signed into the web application when the attack is initiated. The end result can vary greatly depending on the nature of the application. However, common examples include changing the user’s password, obtaining access to sensitive data, and transferring money out of the user’s bank account. For some real world examples, there is nice Defcon17 presentation available at http://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-bailey-mcree-csrf.pdf.
How can we “fix” CSRF Issues?
The blog title included the word “resistant” instead of “protected” for a reason. There is no 100% perfect fix for CSRF (similar to session hijacking). However, submitting non-predictable challenge tokens with each HTTP request can help to prevent most CSRF attacks as long as the token is associated with the user’s session (and no XSS or other serious issues exist within the application). These tokens are also commonly referred to as “anti-CSRF” and “page” tokens. The basic process works as follows:
The user signs into the web application via their web browser.
A random non-predictable anti-CSRF token is generated on the server side and stored as a session variable.
The anti-CSRF token is then sent to the user’s browser in the server’s response as a hidden form field, HTTP GET parameter or cookie.
The next time the user submits a request to the server the anti-CSRF token is sent with it.
On the server, the anti-CSRF token sent from the user’s browser is compared to the server side anti-CSRF token.
If the tokens match, a new token is generated and the process is repeated for each request.
If the tokens don’t match, then the request fails. In many applications if there is a page token failure the user’s session is automatically terminated and the user is forced to sign back in.
Other methods that are considered less user friendly for thwarting CSRF attacks include re-authenticating with every request or using a captcha before providing access to sensitive data or functionality. For a more detailed overview on how to implement ant-CSRF tokens visit either of the following sites:
How can fuzzing be conducted against sites that use anti-CSRF tokens?
It’s usually considered a good thing when applications use anti-CSRF tokens. However, sometimes the tokens can make performing security assessments a little more time consuming. Not all commercial web application security scanners support the functionality, and the ones that do can get expensive. I know not every security enthusiast has an unlimited budget so for those who don’t want to spend a ton of money I suggest using Burp. Burp has a lot of native fuzzing payloads, and supports custom payloads that can be used to check for things like SQL injection, XSS and weak passwords. More importantly, Burp supports recursive grepping and fuzzing with more than one parameter at once, which makes it an ideal candidate for testing sites with anti-CSRF tokens. Below I’ve outlined a basic process for doing that. Setup a Burp local HTTP proxy
Download and install the Burp suit. Fuzzing using the commercial version is much faster than the free version, but either will do.
Run Burp, but configure it so the “intercept” proxy setting is set to off.
Configure Internet Explorer or Mozilla Firefox to use the local Burp proxy.
Target anti-CSRF tokens and other parameters
Log into the web application through the browser.
Navigate to any page in the application.
In the Burp proxy history send the last request to the intruder tab.
Navigate to the “Positions” sub tab.
Choose “cluster bomb” from the attack type drop down list.
Click “Clear” button, then identify the anti-CSRF parameter (It could be a cookie, GET parameter, or POST parameter/hidden input field value).
Once the anti-CSRF token has been identified, click at the beginning of the anti-CSRF token value and click the “Add” button. This will mark where to start the fuzzing.
Click at the end of the anti-CSRF token value and click the “Add” button again. This will mark where to stop the fuzzing.
Target the additional parameters you wish to target for (fuzz) attacks by following the same process.
Navigate to the “Options” sub tab of the “Intruder” tab and scroll down to the “grep” section.
In the “grep” section, select the “extract” tab and clear all other values from the list by pressing the “delete” button as many times as needed.
Select “simple pattern match” radio button.
Enter the anti-CSRF parameter into the text box and click the “add” button, but make sure to include the”=” character if it’s used in the request. For example: “mytoken=”.
In the “stop capturing at” text field enter the value of the character that comes up after the anti-CSRF token.
Next, manually copy the value of the anti-CSRF token from the last server response to the clip board. It can be found in the “history” sub tab of the “proxy” tab.
Navigate to the “Payloads” sub tab of the “intruderIntruder” tab and choose the payload set for the anti-CSRF token. The Payloads payloads will be numbered sequentially in the order they are displayed in the “Positions” tab.
Choose the “recursive grep” payload.
Select the anti-CSRF token from the list on the left by clicking it.
Paste the current token in the “first payload” text box from the clip board.
Setup additional fuzzing payloads
Choose the next payload set.
Choose the desired payload from the drop down.
Configure the appropriate options.
Start fuzzing by navigating to the “intruder” menu from the title bar and selecting “start”.
As time goes on the IT community is getting a better understanding of what CSRF is, how the attacks can be delivered, and how to protect against them. However, with these new protections, come new challenges for application security assessors that require a more advanced skill set. Eventually all of the tools will catch up, but in the mean time make sure that your application testers to have a strong understanding of how to assess sites that protect against CSRF attacks.
PTaaS is NetSPI’s delivery model for penetration testing. It enables customers to simplify the scoping of new engagements, view their testing results in real time, orchestrate faster remediation, perform always-on continuous testing, and more - all through the Resolve™ vulnerability management and orchestration platform.
We help organizations defend against adversaries by being the best at simulating real-world, sophisticated adversaries with the products, services, and training we provide. We know how attackers think and operate, allowing us to help our customers better defend against the threats they face daily.
At NetSPI, we believe that there is simply no replacement for human-led manual deep dive testing. Our Resolve platform delivers automation to ensure our people spend time looking for the critical vulnerabilities that tools miss. We provide automated and manual testing of all aspects of an organization’s entire attack surface, including external and internal network, application, cloud, and physical security.
Our proven methodology ensures that the client experience and our findings aren’t only as good as the latest tester assigned to your project. That consistency gives our customers assurance that if vulnerabilities exist, we will find them.