31 Jan, 2014

Accurate XSS Detection with BurpSuite and PhantomJS

by John Poulin

Edit: You can see a video on how to leverage this tool (above) or visit our YouTube page -   here.

Cross Site Scripting (XSS) attacks occur when output from an application is not properly encoded, allowing a malicious user to inject and execute JavaScript code within the target application.

With the new regime of server-side JavaScript frameworks such as Node.js, and advanced client-side JavaScript frameworks such as Backbone.js, XSS attacks are more dangerous than ever.

As application security consultants, the nVisium team spends a significant amount of time within each test searching for XSS vulnerabilities. Many of the applications we test are large, with over 1,000 input parameters, each of which is a potential XSS vulnerability. Testing these parameters manually isn’t feasible. We use a handful of tools to help automate this testing, but encounter a significant number of false positives and false negatives.

What’d we do?

We decided to build some tools to automate detection of XSS vulnerabilities, while minimizing the amount of false positives. There are quite a few options available already, but we have noticed that these contain a decent amount of false positives.

Last year Trustwave Spiderlabs released a blogpost entitled “Server-Side XSS Attack Detection with ModSecurity and PhantomJS” [1] that described the process of using PhantomJS, a headless WebKit, to determine whether potential XSS attacks caught by the ModSecurity firewall were being rendered, and executing properly.

We decided to build our own PhantomJS application that would run as a server, listening for requests. The purpose of this server was to process and build a DOM from HTTP response bodies. This DOM would be used to determine which JavaScript functions were executing within the given page.

In accompaniment with the PhantomJS application, we decided to build a Burp extender we could use to pass data to the PhantomJS server. We decided to build an Intruder extender (as opposed to a scanner extender) so that we could have more control over the attack procedure. In essence, the extender has a list of approximately 100 common XSS payloads [2], each of which contains a trigger value of f7sdgfjFpoG. These payloads are sent to the target, and when Burp receives the HTTP response associated with the request, it is passed along to the PhantomJS server for processing.

The PhantomJS server hooks into common XSS related functions, such as Alert, Confirm, Document.write, etc. These hooks will grab the function arguments, and see if they include the XSS trigger. If there is a match we know that the PhantomJS server executed one of the XSS payloads sent via the Burp extender. As such, we have confirmed an XSS finding.

How can you use it?

Both the phantomJS server and Burp extender are in very early stages of development, and haven’t been fully tested. We’ve built these tools for the community, so please feel free to use them! If you have any suggestions, we’re all ears!

Requirements

Before moving forward, I recommend making sure the following requirements are met:

    • Java 7.0 or higher
    • PhantomJS: This can be installed locally, or on a remote server. http://phantomjs.org/
    • Burp Suite To get started you can download a precompiled .jar file here. Note, the .jar file is built with the assumption that the PhantomJS server is listening on 127.0.0.1:8093. If you need to adjust these details you will need to compile from source.

If you’re going to be building the .jar from source I recommend following the instructions on our git repository.

Installing the extender

If you have experience installing extenders, you can skip this section.

Open Burp Suite if it’s not already open. Navigate to the extender tab and click the Add button, as seen below:

Ensure that the extension type is Java, then click the Select file button and browse to the location of the xssValidator.jar file.

Click add then a window should appear. Ensure that there are no errors by clicking on the errors tab. If errors occurred it is likely that the .jar file isn’t compatible with your version of Java. Ensure that you’re running Java 7. If the error persists reach out to us and let us help you!

After adding the extender, you should see it appear on the Burp extender panel, as seen below.

Preparing the attack

Create a new Intruder attack for the target request. Define the targets as you normally would, and navigate to the Payloads tab. Select the payload type of extension-generated, as seen below.

Click the Select Generator, and then select the XSS Validator Payloads payload generator.

Click the add button under Payload Processing, and select Invoke Burp Extension from the dropdown menu. Select the XSS Validator processor, and click ok.

Define the Payload positions, if you haven’t already. In the example we’re using, the xsstest.php file has a XSS vulnerable GET parameter, test. We define that as our target parameter, as seen below:

Under the options tab, browse down to the Grep – Match section, and enter the string “ fy7sdufsuidfhuisdf ”. This string is returned by the Burp Extender if the payload successfully triggers an XSS.

Start the PhantomJS server, prior to launching the attack, by changing into the xss-detector directory and executing “phantomjs xss.js”. After executing the command, the server will be listening.

Switch back over to the Burp Intruder Attack, and launch. Payloads that successfully trigger an XSS attack will be noted by the presence of the “ fy7sdufsuidfhuisdf ” flag, as seen below.

If you want to verify the XSS finding, simply right click the specific payload, and select navigate to request in browser -> original session.

What’s next?

At this point, you’re probably wondering, what’s next? Well, there’s a whole bunch of stuff that’s on the roadmap:

  • Testing for false positives – we need to test a bit more extensively to ensure that the phantomJS server isn’t reporting false positives. As of this post, we have yet to see one.

  • Automatically adding detection column – we know that it’s a bit annoying to add such an odd string (fy7sdufsuidfhuisdf) to the Intruder grep option. This was just a hack until we could figure out a better way of reporting. We want automate this by automatically adding a new tab to the attack window that will mark positive findings, without using this string.

  • More payloads – this tool will really only be effective with a comprehensive, and growing list of payloads. The current payloads were inspired by RSnake’s XSS Filter Evasion Cheat Sheet.

How to get in touch?

If you’re looking to get involved, please check out our git repository: https://github.com/nVisium/xssValidator.