Download and first run

snuck is an open-source software written in Java, released under the Apache 2.0 license, you can download the sources by using svn.

svn checkout https://github.com/mauro-g/snuck snuck

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

cd snuck
ant jar

This will generate an executable jar file that is ready to run!
You can also directly download a ready-to-run executable jar from here (released on October 2012, thus it may not work with recent browsers; this applies also in case of manual source code building, since the project is no longer under active development).
Note: No particular prerequisites are required, in particular you just need a working JVM and Firefox installed. Furthermore, if you want to run a test with Google Chrome/Chromium, you should download the appropriate server, which is a bridge between the web browser and the driver - refer to http://code.google.com/p/chromedriver/downloads/list. A similar procedure is required for Internet Explorer too, refer to http://code.google.com/p/selenium/downloads/list. The tool has been tested with IE9 and has proven to work successfully; some issues could possibly appear with older versions of IE, but we are working to make snuck compatible with these too. Obviously since the tool is written in Java, you can run it in any platform.
Once you downloaded/generated the jar file, you will need to become familiar with the command line options, here follow the available arguments and the correspondent description.

> java -jar snuck.jar
Usage: 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 set)
  -help          show this help menu 

XSS Attack Vectors

The tool keeps a set of XSS vectors, that you can find in the directory named payloads; this latter contains four files:

• html_payloads. it stores HTML tags whose purpose is to generate an alert dialog window. Placeholders could be used within this set of vectors; for instance, if we have <script src=data:,%alert%></script>, then the tool will pick a javascript alert from the following attack vector set at random to be the substitute of %alert%. Something like <svg onload=%uri%> will be treated similarly, obviously the drawing will happen among the URIs vectors (see below).
• js_alert payloads it stores many javascript approaches to trigger an alert dialog window, such as alert(1) or eval(alert(2)).
• uri_payloads it stores malicious URIs, such as javascript:alert(1).
• expression_alert_payloads it stores malicious expression payloads, such as expression(URL=0); in this case it is mandatory to produce a redirect to a new URL ending with "0" in order to catch whether a vulnerability exists. Unfortunately expression(alert(1)) would flood the web browser (IE), while expression(write(1)) makes the browser freeze, finally expression(alert(URL=1)) produces multiple alert dialogs and this is annoying from the web driver's perspective.

Obviously the tester is allowed to add vectors in these sets by just adding a new line. Furthermore, it is possible to employ a remote attack vectors repository instead of the local one, this can be done by starting the tool with the -remotevectors argument. The remote repository should be a URL whose content is the directory called payloads - for instance if the repository is reachable at http://www.example.com/repository/, then the tool will look for the four payload files in http://www.example.com/repository/payloads/.



Via: www.kitploit.com