Automatically Bypass XSS Filter With Snuck

Snuck is a Selenium based automated tool programmed, which is different from typical web security scanners, to help discovered XSS vulnerabilities in web applications. It's approach is related to the inspection of the injection's reflection context, specialising them in order to increase the success rate of breaking a given XSS filter. The attack vectors are chosen on the basis of the reflection context (the pinpointed location where the injection falls in the reflection web page's DOM). This is possible through Selenium web driver that allows to duplicate operations in web browsers. It requires an XML configuration file to be filled in order to make snuck a wiz at what it needs to do with respect to the test web application. It supports Mozilla Firefox, Google Chrome and Internet Explorer and the XSS testing in performed on a real web browser to mirror the attacker's and (possibly) the victim's behaviour.


Snuck is a Java-based open-source software and is released under the Apache 2.0 license. To download you can use the following source using snv:

svn checkout http://snuck.googlecode.com/svn/trunk/ snuck-read-only

Once done, you can use the build.xml for Ant to compile the source files and generate the jar file

cd snuck-read-only
ant jar

Then you will be able to generate an executable jar file which is ready to run.

You can also download it via a ready-to-run executable jar by click here.

We would like to mention here that you just need a working JVM and Firefox to run this software. To run a test with Google Chrome/Chromium, you must download and use the appropriate server which is a bridge between the web browser and the driver.

To run the software on Internet Explorer and its appropriate server please refer to the following link.

You will also need to familiarise yourself with the command line options. Below you can find the available arguments and the correspondent description:

>java -jar snuck.jarUsage: snuck [-start xmlconfigfile ] -config xmlconfigfile -report htmlreportfile [-d # ms_delay] 
[-proxy IP:port] [-chrome chromedriver ] [-ie iedriver] [-remotevectors URL] [-stop-first]
[-reflected targetURL -p parameter_toTest] [-no-multi]
Options :

  -start         path to login use case (XML file)
  -config        path to injection use case (XML file)
  -report        report file name (html extension is required)
  -d             delay (ms) between each injection
  -proxy         proxy server (IP: port)
  -chrome        perform a test with Google Chrome, instead of Firefox. It needs the path to the chromedriver
  -ie            perform a test with Internet Explorer, instead of Firefox.
                 Disable the built in XSS filter in advance
  -remotevectors use an up-to-date online attack vectors source instead of the local one
  -stop-first    stop the test upon a successful vector is detected
  -no-multi      deactivate multithreading for the reverse engineering process - a sequential approach will be adopted
  -reflected     perform a reflected XSS test (without writing the XML config file)
  -p             HTTP GET parameter to inject (useful if -reflected is setted)
  -help          show this help menu 

Sample Scenarios and How-Tos According to Google:

• Scenario I: Stored XSS

 Let us assume to have an e-commerce web site, which allows sellers to modify the description of their items. Items' descriptions are publicly accessible, thus leading to stored XSS in the case of XSS filter bugs. Testing the XSS filter needs three steps to be performed before landing in the reflection page. Since the injection is reflected within a P html element, the tool will reverse the fi lter and report the allowed tags and attributes in the final report. Obviously detected XSS are reported as well. See the following image for better understanding the context.

In the aforementioned case snuck need to know which operations are required to connect the injection page, that is the web page in which the malicious payload is supplied, to the reflection one, that is the web page in which the payload is reflected. This task can be done by passing an XML configuration file, such as the following. In particular every  reports a tuple in the form of Selenium commands, refer to Selenium selectors for further information. 

xml version="1.0" encoding="UTF-8"?>

  
        
            
                open
                http://wtfbay.com/modify.php?id=90
                
            
            
                type
                name=name
                ${RANDOM}
                                                                               
          
                type
                id=description
                ${INJECTION}
           
           
                click
                name=submit
                
           
          
                select
                id=cat
                Bike
            
            
                click
                name=submit
                
            
        
    

In addition, since it is obvious that a login operation is required for managing our items, then another XML configuration file is needed.

xml version="1.0" encoding="UTF-8"?>

    
        
            
                open
                http://wtfbay.com/login.php
                
            
            
                type
                name=user
                admin
                                                                                                             
           
                type
                name=pwd
                admin
           
           
                click
                name=submit
                
           
        
    

So far so good, now, how can we start the tool? By assuming that we want an HTML report named report.html and the aforepresented XML files are named usecase.xml and login.xml, then:

> java -jar snuck.jar -config usecase.xml -report report.html -start login.xml

What will the tool do? Basically the tool will firstly reverse engineer the HTML filter used against the user-supplied description, then it will start injecting multiple attack vectors and check whether an XSS is triggered - the important point here is that alert dialog windows are grabbed in order to decide whether an injection is successful; this means that false positive rate is equal to 0 as a vulnerability is reported just in case an alert dialog window is grabbed by the used web browser (note that this is automatically performed).

• Scenario II: Stored XSS
 Let us assume to have a blog, which allows visitors to leave comments. As in the previous case, our goal is to bypass the filter the web application is using against user generated content. Since the tool just need to fill some field and perform the attack, this is actually comparable to a fuzzy approach. See the following image for better understanding the context:.

The XML configuration file (use case) and the necessary parameters for starting snuck are reported below.

xml version="1.0" encoding="UTF-8"?>
               
                                                                                                          
         
            
                username
                hal9001
            
        
        
            
                open
                http://examplecom/post.php?id=90
                
            
            
                type
                name=name
                ${USERNAME}
                                                                                                 
            
                type
                id=comment
                ${INJECTION}
           
           
                click
                name=submit
                
           
        
    

java -jar snuck.jar -config usecase.xml -report report.html

 The remarkable points here are that variables can be defined through the  tags and referenced by using strings in the form of ${variable_name}. In addition you can use ${RANDOM} or ${RANDOM_EMAIL} within  tags for asking the tool to supply a random alphanumeric string or a random email.

• Scenario III: Reflected XSS
 Here we present a basic scenario in which the value of an HTTP GET parameter is reflected in a web page, in particular in the attribute value of an input element, whose type is setted to hidden. As usual, we want to test whether injecting this parameter could result in a reflected XSS vulnerability - see below for the XML configuration file and how it is possible to start snuck - in this case we have two different opportunities.

xml version="1.0" encoding="UTF-8"?>

    
        
            http://example.com/xss.php
            
            param
            foo=bar
        
    

> java -jar snuck.jar -config config.xml -report report.html 

# faster mode (no XML file required)
> java -jar snuck.jar -report report.html -reflected "http://example.com/xss.php?foo=bar" -p param

 Note that the  can be used for asking the tool to make the injections at  and to look for reflections at the URL defined with .

Further information Sometimes it might be useful to discover the first successful injection without realizing a complete test. This task could be achieved through the argument -stop-first, which makes the tool stop at the first positive, it will find. In addition, you could obviously stop the test through CTRL+C, if so, then the tool will print in stdout the successful injections that it found so far.

Click on this link to download Snuck.

Cheers!

About The Author

This article is written by Sindhia Javed Junejo. She is one of the core members of RHA team.