Fuzzing Parameters in CSRF Resistant Applications with Burp Proxy

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 https://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-bailey-mcree-csrf.pdf.
An important thing to be aware of is that CSRF attacks can be initiated from a variety of vectors. Common attack vectors include image tags, links in phishing emails and JavaScript code imbedded in legitimate websites using pre-existing XSS flaws. All of these attack vectors may seem different from each other on the surface, but in reality they all end up sending a simple HTTP POST or GET request that takes actions in the target web application. For some good generic examples I suggest visiting https://www.cgisecurity.com/csrf-faq.html. The site provides some nice CSRF code examples that use JavaScript, image tags, iframes, URL parameters, and AJAX POST requests. The article also makes the good point that CSRF attacks are not limited to browsers. All kinds of web based technologies are affected, such as MS Office software, Flash files, and web services. Another good thing to note is that each CSRF HTTP request used in an attack has to be custom made for the application (or group of applications) being targeted. Some common application targets include online banking applications and social networking websites, because they often have large user bases that are almost always signed in while doing other things on the internet.

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:

1. The user signs into the web application via their web browser.
2. A random non-predictable anti-CSRF token is generated on the server side and stored as a session variable.
3. 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.
4. The next time the user submits a request to the server the anti-CSRF token is sent with it.
5. On the server, the anti-CSRF token sent from the user’s browser is compared to the server side anti-CSRF token.
6. If the tokens match, a new token is generated and the process is repeated for each request.
7. 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:

1. https://shiflett.org/articles/foiling-cross-site-attacks
2. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

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

1. Download and install the Burp suit. Fuzzing using the commercial version is much faster than the free version, but either will do.
2. Run Burp, but configure it so the “intercept” proxy setting is set to off.
3. Configure Internet Explorer or Mozilla Firefox to use the local Burp proxy.

Target anti-CSRF tokens and other parameters

1. Log into the web application through the browser.
2. Navigate to any page in the application.
3. In the Burp proxy history send the last request to the intruder tab.
4. Navigate to the “Positions” sub tab.
5. Choose “cluster bomb” from the attack type drop down list.
6. Click “Clear” button, then identify the anti-CSRF parameter (It could be a cookie, GET parameter, or POST parameter/hidden input field value).
7. 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.
8. Click at the end of the anti-CSRF token value and click the “Add” button again. This will mark where to stop the fuzzing.
9. Target the additional parameters you wish to target for (fuzz) attacks by following the same process.

Setup recursive grep payload (to facilitate valid HTTP requests with anti-CSRF tokens)

1. Navigate to the “Options” sub tab of the “Intruder” tab and scroll down to the “grep” section.
2. 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.
3. Select “simple pattern match” radio button.
4. 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=”.
5. In the “stop capturing at” text field enter the value of the character that comes up after the anti-CSRF token.
6. 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.
7. 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.
8. Choose the “recursive grep” payload.
9. Select the anti-CSRF token from the list on the left by clicking it.
10. Paste the current token in the “first payload” text box from the clip board.

Setup additional fuzzing payloads

1. Choose the next payload set.
2. Choose the desired payload from the drop down.
3. Configure the appropriate options.
4. Start fuzzing by navigating to the “intruder” menu from the title bar and selecting “start”.
5. Ninja-fy.

Conclusion

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.

Reference Links

1. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
2. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
3. https://www.cgisecurity.com/csrf-faq.html
4. https://shiflett.org/articles/foiling-cross-site-attacks
5. https://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-bailey-mcree-csrf.pdf
6. https://portswigger.net/

Scott Sutherland