Snuck - Tool For Automatic XSS Filter Bypass

Snuck is an open source tool written in Java whose goal is to significantly test a given XSS filter by specializing the injections on the basis of the reflection context.

The approach, it adopts, is based on the inspection of the injection reflection context and relies on a set of specialized and obfuscated attack vectors for filter evasion. In addition, XSS testing is performed in-browser, a real web browser is driven in reproducing the attacker and possibly the victim's behavior.

Snuck is quite different from typical web security scanners, it basically tries to break a given XSS filter by specializing the injections in order to increase the success rate. The attack vectors are selected on the basis of the reflection context, that is the exact point where the injection falls in the reflection web page's DOM. Having access to the pages' DOM is possible through Selenium Web Driver, which is an automation framework, that allows to replicate operations in web browsers.

Since many steps could be involved before an XSS filter is "activated", an XML configuration file should be filled in order to make Snuck aware of the steps it needs to perform with respect to the tested web application. Practically speaking, the approach is similar to the iSTAR's one, but it focuses on one particular XSS filter.

HOW IT WORKS

Scenario I: Stored XSS

Let us assume to have an e-commerce website, 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 filter 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 above-mentioned case, Snuck needed 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.

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

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.

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 needed to fill some field and perform the attack, this is actually comparable to a fuzzy approach.

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 set hidden. As usual, we want to test whether injecting this parameter could result in a reflected XSS vulnerability.