Sunday, November 3, 2013

Zed Attack Proxy development tips

Following the previous post about the ZAP plugin, I will now present few tips I came across while extending the tool.

Documentation


Your best resources are existing plugins (see plugins/ directory in your ZAP installation). The core developers have also build a set of four simple examples. When in doubt about the api, you can always look at the source code.

Maven support


Strangely, the api or any components of ZAP is not yet publish on Maven. A manual installation of the zap.jar can mitigate this problem.

    mvn install:install-file -Dfile=%ZAP_DIR%/zap.jar -DgroupId=org.zaproxy -DartifactId=zaproxy -Dversion=2.2.2 -Dpackaging=jar

You can now add the ZAP dependency. Additional dependency might be needed depending on what your plugin need to access.

[...]
    
        
        
            org.zaproxy
            zaproxy
            2.2.2
        

        
        
            net.htmlparser.jericho
            jericho-html
            3.1
            provided
        

    


Debuging your plugin


Java supports remote debuging of application with the specification of few arguments to the java command.

From zap.sh or zap.bat
[...]
java 
  -Xmx512m 
  -XX:PermSize=256M 
  -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
  -jar zap.jar org.zaproxy.zap.ZAP %*
[...]

This method avoid the needed to integrate the complete ZAP application to your development stack in order to debug your small addition.

Logging


Log4J is use by ZAP itself. Your plugin should use the same API to have a proper log aggregation.
If you execute the start script (zap.bat/zap.sh) from the command line, the log will be display to stdout. It is also possible to tail the main log in "$HOME/OWASP ZAP/zap.log".

Troubleshooting plugin installation/removal


Once installed, the plugin is copied in "$HOME/OWASP ZAP/plugin". If ZAP is unable to remove a plugin, you can manually remove the associate file.

Useful references


ZAP extensions : Google projects focusing on documenting the extensions available and providing developer documentation.
ZAP developer mailing-list : Probably the best place to ask questions related to ZAP plugin development.
Plugin examples : Simple examples for the four types of plugins.

Saturday, November 2, 2013

JavaScript static analysis meets your HTTP proxy

I recently use Zed Attack Proxy (ZAP) for the first time. While using the tool, I notice ZAP had passive scanning capabilities. With few examples (built-in passive rules), I started to build a plugin that scan JavaScript for both ZAP and Burp Pro.

The idea


Most modern applications (ab)use JavaScript to build client-side logic. The code is spread in JavaScript files and inline scripts tag. It can totalise thousands of lines of code.
The idea is to do static analysis on all JavaScript files intercepted by the proxy to mark security sensitive code sections.

Developing the rules


Doing a grep like scanner would have limited value. For this reason, Mozilla Rhino was chosen to do JavaScript parsing. By having a real parser, it will be possible to do more intelligent rules that eliminate some false positives. For example, the identification of innerHTML usage was the first rule developed.

The following line could be an exploitable XSS
element.innerHTML = "XSS here ->" + value + "";

While the following line doesn't need to be review.
element.innerHTML += "Static content";

The first example will trigger an alert while the second one is ignore because it is safe.

Screenshots



ZAP plugin

Burp Pro plugin

Try it yourself


The respective plugins are available to download at https://github.com/h3xstream/rhinauditor#downloads.
Note : The plugins are in an alpha stage.

Doing your own passive rules


With ZAP, the implementation of a PluginPassiveScanner is needed to analyse response content. [sample]

In Burp api, you need to implement IScannerCheck. [sample]