Blog

  1. Accurate XSS Detection with BurpSuite and PhantomJS


    Edit: You can see a video on how to leverage this tool (above) or visit the site -  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.


    John Poulin is an application security consultant for nVisium who specializes in web application security. He worked previously as a web developer and software engineer that focused on building multi-tier web applications. When he's not hacking on web apps, John spends his time building tools to help him hack on web apps! You can find him on twitter: @forced_request and on myspace: REDACTED.

    14 comments:

    1. This is a very interesting post but I have a question .
      I get this request from phantomjs and if I use intruder to find correct payload he show me only 1 request.
      In your tutorial I can see that the Burpsuite make more requests

      Can you tell me what I'm doing wrong ?

      Thank you very much

      Received request with method type: POST
      Processing Post Request
      Beginning to parse page
      SECURITY_ERR: DOM Exception 18: An attempt was made to break through the security policy of the user agent.

      about:blank:197 in comScore
      about:blank:198

      Received request with method type: POST
      Processing Post Request
      Beginning to parse page

      ReplyDelete
    2. Sorry about the delay in responding. I have created an bug report via our github tracker here: https://github.com/nVisium/xssValidator/issues/6

      I'm hoping to get some more information from you to help us better solve the problem.

      ReplyDelete
    3. Thanks for your post but I have a problem when loading xssValidator( which was build from source):
      java.lang.ClassNotFoundException: burp.BurpExtender
      at java.net.URLClassLoader$1.run(Unknown Source)
      at java.net.URLClassLoader$1.run(Unknown Source)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(Unknown Source)
      at java.lang.ClassLoader.loadClass(Unknown Source)
      at java.lang.ClassLoader.loadClass(Unknown Source)
      at java.lang.Class.forName0(Native Method)
      at java.lang.Class.forName(Unknown Source)
      at burp.kvc.a(Unknown Source)
      at burp.kvc.(Unknown Source)
      at burp.kyb.a(Unknown Source)
      at burp.xgb.run(Unknown Source)
      at java.lang.Thread.run(Unknown Source)
      My java version is:
      java version "1.7.0"
      Java(TM) SE Runtime Environment (build 1.7.0-b147)
      Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
      Could you help me with this?

      ReplyDelete
      Replies
      1. If you execute Jar tf xssValidator.jar do you see a list of the files? Is there a file called burp/BurpExtender.class? Looks like the class files weren't properly packaged into the .Jar file.

        Can you recompile using ant and provide the output? Want to see if there were any warnings or errors there.

        Delete
      2. The burp/BurpExtender.class is in my output from jar tf. Does this mean a recompile is needed or some other adjustment must be made?

        $ jar tf xssValidator.jar | grep -C 1 "burp/BurpExtender.class"
        burp/BurpExtender$IntruderPayloadGenerator.class
        burp/BurpExtender.class
        burp/IBurpExtender.class

        Delete
    4. 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.

      i didnt understand this??

      ReplyDelete
      Replies
      1. Inside your terminal, execute the following commands inside the project directory:

        $ cd xss-detector
        $ phantomjs xss.js

        This should start the phantomJS server.

        Delete
    5. xssValidator are now loaded to Burp. But after nunning the intruder, only the baseline request are shown and scanning is already finished. im using the pre compiled xssValidator from this blog.

      i think its working because i saw "On alert: notxs" in phantomjs terminal
      im also using the sample PHP files from your git. but other payloads are not running, only the baseline request.

      im running on windows 7. thank you

      ReplyDelete
    6. "cd xss-detector"

      but i do not see any xss-detector directory anywhere...

      ReplyDelete
    7. where do i get the xss.js file ??

      ReplyDelete
      Replies
      1. Ensure that you've downloaded the latest version of xssValidator here: https://github.com/nVisium/xssValidator

        After which, the xss.js file is located in the xss-detector directory.

        Delete
    8. Hi,

      Thanks for such a nice extension. I have my custom xss payloads. I wonder how and where to include such custom payload files to get executed/processed???

      ReplyDelete
      Replies
      1. no one knows, seriously :(

        Delete
      2. You would need to modify the source and rebuild the extension. Here are the payloads: https://github.com/nVisium/xssValidator/blob/master/burp-extender/src/burp/BurpExtender.java#L72

        This video will show you how to build the extension once modified: https://seccasts.com/mror/security_cast/1

        Delete