Monday, 6 February 2017

Introducing the JxBrowser add-on for ZAP

As modern web applications are increasing their reliance on JavaScript, security tools that do not understand JavaScript will not be able to work effectively with them.  ZAP already has components like the Ajax Spider and DOM XSS scanner that work by launching browsers and controlling them via Selenium, and we are planning to make much more use of browsers in the future.

To that end we are planning on releasing a new ZAP add-on which will contain JxBrowser, a wrapper around Chromium. We want ZAP to work as effectively as possible out of the box, and to be as easy to automate as possible. Being able to package JxBrowser in an add-on gives us an up to date browser that we know will work without any other user actions. While the add-on does contain a bundled version of Chromium it will not install Chrome on your computer. Your existing browsers and browser preferences will not be affected.

Please note: While JxBrowser is a commercial closed source wrapper around Chromium, TeamDev has generously given us a permanent free license to allow us to redistribute JxBrowser with ZAP. Most importantly ZAP will stay completely free. Additionally we will not be including the JxBrowser with the ZAP ‘core’ release which we maintain. It will also be very easy to remove the JxBrowser add-on from ZAP via the command line, in the same way that any other add-ons can be removed:
./ -addonuninstall jxbrowser

Why are we doing this?
As this is the first time we will have done anything like this I wanted to explain why we are packaging a closed source product with ZAP, what the implications are and how you can contact us to discuss any concerns you may have.

Unfortunately it is difficult for us to know which browsers will work on any specific system. Both Firefox and Chrome could be present, but we can’t tell until we try to launch them. IE and/or Edge are only going to be available on Windows systems and although Safari is always likely to be available on Mac OS it will not work with Selenium until an extra plugin is installed. As part of this on going effort we have recently decided to package the WebDrivers for Firefox, Chrome and IE in ZAP add-ons so that you will not have to download them manually. We want to be able to default to JxBrowser while allowing you to choose to use any of the browsers as you see fit. We will also be able to do things like launch JxBrowser from within ZAP pre-configured to proxy via ZAP.

Are there any licensing restrictions for JxBrowser?
As a ZAP user you will be able to use the ZAP JxBrowser add-on for any purposes.
However if you change the ZAP source code and call the JxBrowser API from one of your own products then you will need to arrange a suitable licence with TeamDev.
It is also worth noting that while JxBrowser does not ‘phone home’ the internal Chromium functionality may call 3rd party services (spell checking, geolocation, etc) in a similar way to other browsers.

When will the add-on be available?
We are putting the final touches to the add-on and will release it very soon. We will be releasing a new version of the Selenium add-on at the same time, you will need to update this so that we can hook the JxBrowser add-on into ZAP.

If you do have any concerns about our bundling of JxBrowser then please join in the discussion on the ZAP User Group or contact me directly.

Tuesday, 22 November 2016

Announcing the Official ZAP Jenkins Plugin

Using ZAP during the development process is now easier than ever. We are proud to present the Jenkins plugin, it extends the functionality of the ZAP security tool into a CI Environment.

The process explained
  1. A Jenkins CI Build step initializes ZAP
  2. Traffic flows (Regression Pack) through ZAP (Web Proxy)
  3. ZAP modifies requests to include Vulnerability Tests
  4. Target Application/Server sends Response back through ZAP
  5. ZAP sends reporting data back to Jenkins
  6. Jenkins publishes and archives the report(s)
  7. Jenkins creates JIRA tickets for the alerts

The ZAP Jenkins plugin makes use of the readily available and diverse ZAP API, allowing you to use the same session files and scan policy profiles between ZAP and the Jenkins plugin, so they can be interchangeably loaded.

So what can you do?
Automate the site mapping process with a selenium script, have ZAP act as an intercepting proxy to map the structure of your site and record passive alerts. Fire off an active scan and finish it off by generating a report in one of three available formats (xhtml, xml or json). These can be sent off to management or you can load the session later and inspect each raised alert at your convenience.

Providing a seamless workflow and the same functionality as the GUI. You can
  • Manage Sessions (Load or Persist)
  • Define Context (Name, Include URLs and Exclude URLs)
  • Attack Contexts (Spider Scan, AJAX Spider, Active Scan)
You can also:
  • Setup Authentication (Form Based or Script Based)
  • Run as Pre-Build as part of a Selenium Build
  • Generate Reports (.xhtml, .xml, .json)
All while giving you all the benefits of Jenkins to automate the process. Scan between build and deployment all from taking advantage of the automation server.

Where we go from here...
We plan to extend the authentication method to allow authenticated AJAX Spider Scans and support HTTP/NTLM Authentication. To further the continuous integration process, we will be adding Build Management tools in the near future which will allow you to set the thresholds that will determine a builds pass or failure. But we’re not stopping here, we will be continuously advancing our API to meet the needs of community requests for the Jenkins Plugin.

We will work with our community, taking advice and feedback to improve and support this plugin in the short and long term.

ZAP is, as it always has been; one of the largest open source security software. As such this plugin follows in its footsteps. We hope it will become one of your favorite additions into your development lifecycle.

We hope to expand this project and open it to community involvement, we welcome you; the community members to help us maintain and improve the plugin and we thank you for your continued support.

Documentation: See the Wiki for more details.

Questions: Ask on our Google Group.

Issue Tracking: Report on the Jenkins JIRA for the project, please read the JIRA guidelines before reporting an issue.

Monday, 22 August 2016

Announcing ZAP Unit Test Bounties

Unit tests are wonderful things, but they are painful to add to a mature project that doesn’t have enough of them. We would love to have more ZAP unit tests, and we are therefore launching a Unit Test Bounty program, where we pay for unit tests for specific areas of the ZAP codebase.

We are going to start with the passive scan rules (release and beta quality).
These are all defined in the zap-extensions src packages:
We do already have some release quality unit tests in the corresponding test package:
These can be used as a basis of the new tests. Unit tests should be included for real issues (true positives) as well as false positives.
For details of how passive scan rules work see the blog post: Hacking ZAP #3 Passive Scan Rules

We have raised issues for all of the release and beta quality passive scan rules that do not have unit tests, and assigned a bounty on them in Bounty Source. The bounties vary based on the amount of work we expect will be required. We will increase the bounties paid if the pull request (PR) include fixes for false positives or false negatives.

The open bounties can all be seen on the Bounty Source page

We plan to extend the bounties to cover active scan rules in the future. We expect the bounties to typically be higher than for the passive scan rules due to the added complexity.

We will pay out these bounties only when we have merged a PR that has an associated bounty. The PRs must test all of the associated rule functionality and must conform to our Development Rules and Guidelines. Also see
We will work with submitters to help them improve any non-conforming PRs so that they meet our standards. We will also give the first person who submits a nearly conforming PR a reasonable time (eg 2 weeks) to reach the required standard rather than immediately accepting another later PR from someone else that does conform.
We will not reserve issues in advance, nor will we reserve an issue based on an inadequate PR.

You will see that the bounties are not huge. In our defence there are quite a few of them, implementing them should not take too much work and in any case we are an open source project with no revenue stream other than donations!

We also have plans to expand this program to other aspects of ZAP. If you would be interested in sponsoring such plans then please get in touch, or you can just donate money directly to the ZAP project via the Bounty Source page or via the ‘Donate’ Paypal button on You can also donate money to ZAP when you join or renew your OWASP membership.
Do let us know if you are explicitly sponsoring this initiative so that we can give you the public credit you deserve :)

Friday, 3 June 2016

ZAP 2.5.0

ZAP 2.5.0 is now available:

This release contains a large number of enhancements and fixes which are detailed in the release notes:

API changes

There have been some API changes which are not backwards compatible, and the reason for the version change to 2.5. These are detailed in the release notes.
The API has also been extended to cover even more of the functionality in ZAP, including full access to the statistics.

The Java API is no longer packaged with this release.
You can download the latest version from:

It will also be available on Maven Central:
  • GroupId: ‘org.zaproxy’
  • ArtifactId: ‘zap-clientapi’
  • Version: ‘1.0.0’
Note that this may not be available immediately, depending on how long the publishing process takes.

Daemon obeys Mode

ZAP now obeys the mode setting when running as a headless daemon.

Spider subtree option

The spider now has an option to constrain it to a specific subtree. This allows you to explore one part of an application without having to cover all of it.


ZAP now maintains a wide range of statistics which can be invaluable for understanding what is really happening when interacting with large applications.
These are available via the API and can also be sent to a Statsd server.
For more information see


The stable and weekly docker images now allow you to run the ZAP Desktop UI in a browser.
This means that you can run ZAP without having to install Java.
For more details see

The Docker images also include the ‘ZAP Baseline’ script.
This runs the ZAP spider against the specified target for (by default) 1 minute and then waits for the passive scanning to complete before reporting the results.
This means that the script does not perform any actual 'attacks' and will run for a relatively short period of time (a few minutes at most).
This script is intended to be ideal to run in a CI/CD environment, even against production sites.
For more details see

Thank you to everyone who contributed to this release.
To keep up to date with ZAP related news follow @zaproxy on twitter.

Tuesday, 29 March 2016

ZAP Newsletter: 2016 March


Welcome to the March newsletter, read on for some really good news, details of the new site level stats ZAP now supports and an introduction to scripting.

Table of Contents:


The big new this month is that ZAP was voted the TOP free/open source security tool for 2015 by Toolswatch readers:
This is the second time we've come top and is a great validation of what we are doing. Thank you to all of you who voted for us!

Other important news is that ZAP is taking part in the Google Summer of Code (GSoC) 2016. For those of you who don't know, GSoC pays students to work on open source projects over the summer, and we've had key ZAP features like WebSockets, the Ajax Spider and Access Control testing implement by GSoC students.
The deadline for submissions has just passed and we've had 9 ZAP proposals. We'll evaluate those asap, but we dont currently know how many slots OWASP (and ZAP) will actually get so fingers crossed!

And in other breaking news, CommonSense Media have just published a Information Security Primer for Evaluating Educational Software which makes heavy use of ZAP - you can read all about it here:

New / Improved Add-ons

This section details add-ons that have been added or significantly updated since the last newsletter.
A new version of the Zest add-on has been published which included a significant number of bug fixes. There is also an update to the Selenium add-on which includes the latest Selenium release that ensures Firefox doesn't visit the 'first run' page every time it is started.

The Alert Filters add-on has also been updated with various bug fixes and has been promoted to beta status. This add-on allows you to configure rules which automatically change the level at which alerts are raised for specific contexts. For more details see the help pages This add-on is included with the weekly releases and may well be included by default in future full releases.

New Features

This section details enhancements that have been made to the core and are available in the latest weekly release.
The traditional spider has been updated so that you can constrain it to a subtree when using it via the UI or API. For example this means that with this option if you start spidering from you can be sure that it wont explore any other apps under - without this option it will explore anything in that domain it finds links to.

ZAP now records a range of site based statistics, including:
  • Response codes, eg
    • stats.code.200
    • stats.code.302
  • Content types, eg
    • stats.contentType.text/css
    • stats.contentType.text/html;charset=utf-8
  • Tags (some of which are built in but can also be user defined), eg
    • stats.tag.Password
    • stats.tag.Hidden
    • Anticsrf tokens generated
    • stats.acsrf.anticsrf
  • Response times (using a logarithmic scale) eg
    • stats.responseTime.1
    • stats.responseTime.2
    • stats.responseTime.4
    • stats.responseTime.8
    • stats.responseTime.16
  • Authentication information, eg
    • stats.auth.success
    • stats.auth.failure
    • stats.auth.state.loggedin
    • stats.auth.state.loggedout
    • stats.auth.state.noindicator
    • stats.auth.state.unknown
The stats are currently only available via the API, but they can be really helpful, for example if you are trying to work out how effectively ZAP has scanned a large site.

Tutorial: Introduction to Scripting

This section teaches you more about a different ZAP feature every month.
There is an almost infinite range of web applications and so its not possible for any tool to build in support for all of the strange things you will encounter. As ZAP is an open source project you can change the source code to handle anything you like. However this isnt always practical - ZAP is a large and complex project and even if you understand the code base very well, firing up an IDE to rewrite ZAP every time you encounter something strange is definitely not ideal.
Fortunately ZAP has powerful scripting capabilities, and ZAP scripts can access all of the code and data structures.
There are so many aspect to ZAP scripting that one tutorial wont be enough, so we're going to start with an overview.

Scripting support is included in all ZAP releases, but if you want to use scripting in the 'core' version then you will really need to download the Script Console and Zest add-ons from the marketplace.
By default ZAP supports ECMAScript (JavaScipt) and Zest, a graphical security scripting language from the Mozilla Security team.
You can also download add-ons which extend support to Jython and JRuby. ZAP will be able to support any language that supports JSR 223 so if there's another scripting language you would like us to support then please raise an enhancement request issue.
To use ZAP scripts from the UI you need to use the Scripts and Script Console tabs, which are hidden by default and can be accessed via the relevant tabs with the green plus sign.

Scripts tab

The Scripts tab shows all of the scripts available in a tree view.
There are 2 nodes under the top 'Scripting' node:
  • Scripts: the scripts that you have available
  • Templates: the templates from which you can create scripts
Underneath both of these nodes are the full list of script types that are supported. Script types are pluggable, which means that any ZAP add-on can register its own script types. The following script types are included with ZAP by default:
  • Active Rules - these run as part of the Active Scanner and can be individually enabled.
  • Authentication - scripts that are invoked when authentication is performed for a Context. To be used, they need to be selected when configuring the Script-Based Authentication Method for a Context.
  • Fuzzer HTTP Processor - these can access and change the fuzzing HTTP requests and responses, control the fuzzing process and interact with the ZAP UI.
  • Fuzzer WebSocket Processor - these can access and change the fuzzing WebSocket messages, control the fuzzing process and interact with the ZAP UI.
  • Http Sender - these run 'inline' and are similar to Proxy scripts except that they also apply to all requests that originate from ZAP.
  • Passive Rules - these run as part of the Passive Scanner and can be individually enabled
  • Payload Generator - these generate the raw attacks that the fuzzer submits to the target application.
  • Payload Processor - these can be used to change specific fuzzer payloads before they are submitted.
  • Proxy - these run 'inline', can change every request and response proxied through ZAP and can be individually enabled. They can also trigger break points.
  • Script Input Vectors - scripts for defining exactly what ZAP should attack
  • Stand Alone - scripts that are self contained and are only run when your start them manually
  • Targeted Rules - scripts that are invoked with a target URL and are only run when your start them manually
At the top of the Scripts tab is a toolbar with buttons that allow you to Load, Save and create New scripts. When you use the 'New Script…' button you will be prompted to select one of the available templates. You can also create scripts by right clicking on the template you want to use. Some templates are blank but many of them perform useful functions, and all of them include lots of documentation to help you customize them.

Script Console tab

When you select a script in the Scripts tree then it is displayed in the Script Console.
For most scripting languages this is where you will edit it, the only exception to this is Zest which is displayed graphically in the Scripts tab. At the top of this tab is a toolbar that allows you to Run the script displayed and Stop it if it is running. Note that not all scripts can be run in this way - some types can only be run via other ZAP components. For example Active Rules can typically only be run when you start an Active Scan. Underneath the panel displaying the script is another panel which shows the script output.
This panel has its own toolbar with buttons for:
  • Clearing the script output panel
  • A toggle for clearing the script output panel every time a script is run
  • A toggle for locking the automatic scrolling of the output panel
  • A toggle for switching between showing the output of all scripts and just showing the output of the selected script

Script Options

The Scripts Options panel allows you to add any number of directories that contain scripts. The scripts must be in subdirectories named after the relevant script type and must have an appropriate extension for the script language used.
Scripts that can be written to will be added to the Scripts tree and those that are read only will be added to the Templates. This means you can build up your own libraries of scripts and even manage them in a central place using a shared drive.

Community Scripts repo

The Community Scripts repo is a collection of ZAP scripts written by the community, ie people like you :)
It lives on github: and, not surprisingly, is structured so that it can be added as a script directory via the Script Options. It is also available as an add-on on the ZAP Marketplace:

Hopefully that gives you an overview of the scripting support in ZAP. Future tutorials will go into scripting in more detail. In the meantime if you have any questions about ZAP scripting then we have a dedicated group where you can ask them:

Upcoming Talks and Training

ZAP will be featured in the OWASP Pune Chapter Meeting on March 31st in Pune (not surprisingly):

Adrian Winckles will be demoing ZAP at the SecureCambridge Cyber Security Technology Showcase on April 5th in Cambridge:

Azzedine RAMRAMI and Sebastien Gioria will be demoing ZAP in their 'Securing your application with OpenSource tools' at Devoxx France on April 22nd in Paris:

Sumanth Damarla (@Sumanth_Damarla) will be giving a talk: "Securing Web @ZAP" at the I T.A.K.E Unconference on May 19th in Bucharest:


Please fill in this quick Feedback Form so that we can make sure this newsletter is as useful to you as possible.

Coming next month...

That depends on you!
Let us know what you would like to see using the above feedback form.
If you would like to write content for the newsletter then please get in touch - anything ZAP related, such as talks / training you are giving, a 3rd party tool you develop or maybe an add-on you'd like to explain in more detail.
And we're also looking for one or more editors for the ZAP newsletter - you don't need any detailed ZAP knowledge, just a bit of time each month you can dedicate to chasing up people for content and bashing it into something that reads better than this one :P Think thats you? Get in touch!

Simon Bennetts (ZAP Project Lead)

Friday, 19 February 2016

ZAP Newsletter: 2016 February


Welcome to a slightly delayed February newsletter - we were holding on for some expected news that will now have to wait until next time ;)

Table of Contents:


We have started another user questionnaire. We ran one 2 years ago - the answers were very helpful and definitely shaped the direction ZAP is now taking. So if you want your voice to be heard then please fill it in.

Both OWASP and Mozilla will be applying to take part in Google Summer of Code this year. ZAP has greatly benefited from students taking part in this via both of these organizations, and we’re hoping at least one will be accepted so that we can take part again. If you have any suggestions for suitable projects or anything else to contribute then please join the discussion on the Dev group.

New / Improved Add-ons

This section details add-ons that have been added or significantly updated since the last newsletter.
Add-ons are available to download and install within ZAP.
Just click on the ‘Manage Add-ons’ toolbar button and select the Marketplace tab:

Note that all add-ons on the Marketplace are completely free and open source and anyone can publish add-ons to it - see the zap-extensions wiki for details.

New versions of the Active scan rules (beta) and SAML add-ons have been released - these include security fixes so if you use them then please update them asap.

And a new version of the Wappalyzer (technology detection) add-on has been released which includes the latest changes from the Wappalyzer project (

A new Community Scripts add-on has been released. This is a packaged version of the community-scripts repo ( which is a collection of ZAP scripts that anyone can easily contribute to. Please contribute any scripts you create for your own use using pull requests!
Also note that version 1 of this add-on contained a bug which can result in your ZAP configuration being lost, so if you downloaded that one then please update to the latest version asap.

Tutorial: Contexts

This section teaches you more about a different ZAP feature every month.
Contexts are a way to group sets of related URLs together. You can use contexts to define the applications you are testing, as well as parts of those applications that you want to handle in non-default ways. Contexts allow you to define extra properties associated with those URLs so that ZAP can handle them more effectively. They are displayed at the top of the Sites and can be imported and exported using the buttons on the Sites toolbar.

For this tutorial we will be using the BodgeIt Store, a simple vulnerable web application available from, but you can use any application that uses authentication.

You need to access the target application before you can add it to a Context, so open the BodgeIt home page in your browser while proxying through ZAP. Find the BodgeIt top node in the Sites tree, right click it and 'Include in Context -> Default Context'. The Session Contexts Dialog will be displayed, which is part of the Session Properties dialog and is where you can define all of the properties associated with each context. The 'bodgeit' node and all of the nodes underneath it will now have been added to the 'Default Context'.
Note that you can define as many contexts as you need.

All details about a context are defined in the session properties. You can access these at any time by double clicking on the relevant context or by pressing the 'Session Properties' button on the main toolbar.

Context: Top Page

The top page of each context allows you to specify the name and description. It also allows you to define if this context is 'in scope', ie they are part of the system that you are testing at any specific time. All nodes that are in scope are shown with a 'target' icon on them in the Sites tree. You can also switch Contexts in and out of scope by right clicking them in the Contexts tree. You can choose to spider or scan all of the contexts that are in scope with one command. You can also use the 'Protected mode' - this will only allow you to attack nodes that are in scope. Many of the ZAP tabs, including the Sites, History and Alert tabs have buttons which allow you to only display information that is in scope.

Context: Include In / Exclude From Context

The first 2 child pages allow you to define the URLs that are included in the context. This is done using regular expressions (regexes). The easiest way to include any leaf nodes and subtrees is to use the 'Include in Context' and 'Exclude from Context' right click options in the Sites and History tabs. However if you need to define more complex regexes then you will need to do this manually using theses screens. Always double check the nodes that are included by verifying that the target icons are set correctly.

Context: Structure

The Structure page allows you to define the properties that define the context structure. The Sites tree is ZAP’s representation of the structure of all of the sites you visit. It is very important that ZAP correctly understands the structure of the applications you are testing otherwise it will not be able to attack them correctly.
By default ZAP assumes that URLs are of the form:
In this case the URL Key Value Pair Separator is '&' and the the URL Key Value Separator is '='
If (for example) part of an application you are testing uses URLs of the form:
then you should define those URLs to be part of a context and change the separators in this screen to ':' and ';'.

Structural Modifiers are controls which change how ZAP represents the structure of the application. There are currently 2 types of Structural Modifiers:
  • Data Driven Content which identify URL paths that represent data - these can be used to tell ZAP that specific pages are generated from database content and can so be treated the same
  • Structural Parameters which identify parameters that represent application structure instead of user data - these can be used to allow ZAP to correctly represent 'single page applications'
For more details see the relevant section in the User Guide.

Context: Technology

This page allows you to specify the technologies used in the context, if known. By default all technologies are included. If you exclude technologies that you know are not used then this may speed up active scanning as rules specific to the excluded technologies can be skipped.

Context: Authentication

This page allows you to manage the way authentication is handled for this context. Once you have defined the authentication and one or more valid users then you will be able to perform authenticated attacks on your target application, as well as perform more advanced testing of the applications access control. There are very few standards with regards to web application authentication, but ZAP is extremely flexible and so should be able to cope with any situation you come across. It can even cope with browser based single-sign-on systems like Personna.
For this tutorial we will just handle the simple Form Based authentication that the BodgeIt store uses. A future tutorial will go into more depth on authentication.

In the BodgeIt store register a new user. BodgeIt will automatically log this user in, so logout and login again as we want the login request and not the registration request.
Identify the login POST request in the History tab, right click it and select 'Flag as Context-> Default Context: Form-based Auth Login Request'
You will now be shown the Context Authentication page, which you will need to tweak.

The Login Form Target URL and Login Request POST Data should be filled in correctly. However at least one of the Username or Password parameter fields will need changing - they should be:
  • Username Parameter: username
  • Password Parameter: password
In order for ZAP to know when it need to authenticate we need to configure a way for it to tell if the user is logged in or not. We do this via regex patterns which should match strings that indicate that the user is either logged in or logged out. You only need to define one of these, not both. You can configure these manually, but it’s easier and safer to use the UI:
  • In the ZAP history select a request made to bodgeit before you authenticated
  • Look at the response, find and highlight the HTML which defines the Login link
  • Right click the highlighted text and select "Flag as Context -> Default Context: Authentication Logged-out indicator"
You will now be shown the Context Authentication page again with the Logged-out regex pattern correctly defined. ZAP now understands how he BodgeIt authentication works, but it will need to know about at least one user before you can make use of this. You can configure that using the next screen.

Context: Users

This page allows you to define as many users as you need for testing. If your application supports roles you should define at least one user for each role. You will need to fill in the correct authentication details for each user. ZAP will have automatically added the one used in the authentication request you specified, you just need to make sure it is enabled.

Context: Forced User

The forced user mode allows you to force a specific user to be used for all requests that are generated by or proxied through ZAP. The forced user mode is switched on and off via an icon on the main toolbar. It will be disabled until all of the necessary configuration has been made. For this example select the user you previously registered with ZAP. Once you have saved the dialog you should see that the Forced User mode button is now enabled.

Before enabling it make sure that you have logged out of BodgeIt. Then click the button to enable Forced User mode and click on one of the links in BodgeIt. You should see that you are now logged in - ZAP will have authenticated as that user in the background.

If you are not authenticated then you will have made an error in your configuration. All of the authentication requests ZAP makes on your behalf will be shown in the History tab, so you can use those to help you resolve your issue. The Forced User mode is one of the simplest authentication tools but it is very useful for checking that you have configured the authentication correctly.

Once you have checked that the forced user mode works you can now perform authenticated spidering and active scanning of your application. You can do this by keeping the forced user mode on, or by switching it off and then selecting the user you want to use in the Spider or Active Scan dialogs.

Context: Session Management

This page allows you to manage the way in which Session Management is being done for the Context. After selecting the Session Management Method type, the options that need to be configured depend on the Session Management Method. For most applications you probably wont need to change anything on this page.

Context: Authorization

This page allows you to define how unauthorised requests are handled by your application. This is used by the Access Control add-on which allows you to automatically test your applications access control.

3rd Party Tool: Faraday

Faraday is an Integrated Multi-User Pentest Environment that’s principal goal is to map and leverage information you generate in real-time. Named after the British scientist Michael Faraday who was famous for his meticulous note taking (as well as the Faraday cage), our tool tries to emulate his rule of systematically recording everything.

With more than 10 years in the industry, we have learned over here at Infobyte that pentesters and security teams have unique toolsets and skills. The idea isn’t to change a security professional’s workflow but to get everyone on one platform in real-time where information can be easily documented and used to gain greater insights for a security team.

With 50+ supported tools Faraday is the connective tissue that brings together your different tools and team members to increase efficiency and analysis of your security engagements.
The ZAP plugin recognizes information such as Hosts, Interfaces, Services, Vulnerabilities and send this to Faraday. With only a copy of a report, all this information is available in Faraday for all the members of your team.

How can we use it?
  1. Open OWASP ZAP and start a attack, wait for the attack to finish.
  2. Go to Report menu => Generate XML report…
  3. Save the report with any name.
  4. Open Faraday and copy that report to $HOME/.faraday/report/$WORKSPACE where $WORKSPACE is the active workspace name in Faraday.
  5. Ready! All information is loaded now
Here, you can see the “Tree Hosts” showing you information of a report of OWASP ZAP.
Hosts, interfaces, Services, Notes and how many vulnerabilities have been loaded. You can see more information about vulnerabilities found: Name, Description, Severity, References ( URLs, CVE and CWE), Path, and more. If you like web interfaces more than QT interface, Faraday has one! Here you can see the same information as in the QT interface , but you here you can work with the information. Group vulnerabilities by a field, show or not a field, show details about a vulnerability, edit or delete one, and download all the data such as CSV file. Also, Faraday greatly speeds up the time needed for a security engagement by simplifying vulnerability adjustments with severity classifications (CVSS standards supported).

However, too much information can get confusing… Faraday has a dashboard with a summary of the active workspace for a more general overview of your project. Faraday comes in three flavors, a free community version that can be downloaded on our Github and a pro and enterprise version. In the Professional and Corporate editions you have role differentiation, different workspaces., workspace comparisons, tags, webshells, graphic customization (Corporate) and one-click report generation which typically has been the bane of security teams.

We believe that awesome open-source tools don’t get the love they properly deserve and because of that we developed the Faraday awards, in which with your purchase of Faraday, you get to choose one open-source tool and we make a donation on your behalf to that tool It’s a way of giving back to an underappreciated community.

More information can be found at:

Upcoming Talks and Training

Dan Billing (@TheTestDoctor) will be holding "The Test Doctor’s Proxy Surgery" at the TestBash Workshop Day on March 10th in Brighton:

Sumanth Damarla (@Sumanth_Damarla) will be giving a talk: "Securing Web @ZAP" at the I T.A.K.E Unconference on May 19th in Bucharest:

Featured Contributor: Johanna Curiel

Each month we introduce you to one of the many ZAP contributors.

Q: Who are you?
Johanna Curiel (aka @jctechno), Software & Security Engineer.

Q: Where are you based?
Curacao, Dutch Caribbean

Q: What do you do in your day job?
I work as a programmer and pen tester part-time. At the moment I'm also working on cyber security research.

Q: Why do you contribute to ZAP?
Because I use it in my work. It's a tool with some wonderful features that work even better than many commercial tools in the same category. Also I have learned many things from using ZAP and understanding its programming core and architecture.

Q: How do you contribute to ZAP?
Sporadically. Promoting it as pen testing tool, instruction videos, participating as mentor, working on documentation, testing and reporting issues.
Editors note: Johanna has also been helping with applying for grants - more on that in a future newsletter ;)

Q: What would you like to contribute in the future?
I have been working on an some add-ons, but I have not publicise them. I really would like to get more into creating add-ons and ZEST scripts and publicise them to the community.

Q: What do you like about the ZAP community?
ZAP has great contributors, all working to help improve ZAP in different ways. It is amazing what a group of people can reach when they work towards a goal with the guidance of a great leader.

Q: What do you get out of contributing?
Most important is that I use ZAP in my work. ZAP is for free and open source, with some incredible features that I use it in my pen testing and research. ZAP is the best free proxy available and by contributing you also give something back to help and keep ZAP developing and improving. ZAP has helped me understand security vulnerabilities much better.

Q: Do you have any advice for people who would like to contribute to ZAP?
There are many ways you can contribute, whether promoting it, documentation, translating , coding, testing. Start with something small that you enjoy doing. Take your time to learn ZAP and find out where your skills can help best.

Q: Do you contribute to any other open source projects?
Yes. I do contribute to other open source initiatives , specially those ones I would like to see grow and develop further.

Q: What do you do outside of work?
I live in the Caribbean so it's quite nice weather most of the time. I like windsurfing with my daughter , swimming, BBQ and traveling.

Q: What do you [most] dislike about the ZAP development?
I think ZAP is one of the easiest open source software to join development. There is a lot of documentation available to new developers wanting to get involved. I like the way the code has been structured and with the add-on concept it makes it even easier to experiment on your own, so I have nothing to dislike about. But as a developer if you think to be a serious contributor , you will need to invest some serious time to understand the code and start development, this is a quite common barrier to all new developer contributors.

Q: What do you think could be done [a lot] better?
I would like to see more instruction videos or documentation on how to use ZAP with more complex features and writing ZEST scripts . There is a lot already published on youtube but ZAP has had an amazing development the last years that most of the videos are outdated.


Please fill in this quick Feedback Form so that we can make sure this newsletter is as useful to you as possible.

Coming next month…

That depends on you!
Let us know what you would like to see using the above feedback form.
If you would like to write content for the newsletter then please get in touch - anything ZAP related, such as talks / training you are giving, a 3rd party tool you develop or maybe an add-on you’d like to explain in more detail.
And we’re also looking for one or more editors for the ZAP newsletter - you don't need any detailed ZAP knowledge, just a bit of time each month you can dedicate to chasing up people for content and bashing it into something that reads better than this one :P Think thats you? Get in touch!

Simon Bennetts (ZAP Project Lead)

Monday, 4 January 2016

ZAP Newsletter: 2016 January


Happy New Year!
For the first newsletter of 2016 we have a special feature on a new vulnerability “XCOLD Information Leak” that caught the eye of one of our key contributors, how he found it and how you can use a new ZAP rule to detect it.

Table of Contents:


Steve Springett (@stevespringett) has implemented a ZAP Sonar plugin which integrates ZAP into SonarQube v5.1 or higher. He’s also looking for anyone interested in maintaining this going forwards, so please have a play with it and get in touch with Steve and/or myself if you might be interested in keeping it going. Don't worry if you don't know much about the ZAP side of things, we can help with that!

A new release of the ZAP jenkins plugin is now available. You can download it here :
This release implements the form based authentication method and fixes some issues.

Do you want to know things like:
  • How many downloads ZAP gets?
  • What are the most popular ZAP add-ons?
  • How ZAP performs against wavsep and wivet?
You can find all of that out via:
These stats are maintained by zapbot, which now even has its own icon :)

New / Improved Add-ons

This section details add-ons that have been added or significantly updated since the last newsletter.
Add-ons are available to download and install within ZAP.
Just click on the ‘Manage Add-ons’ toolbar button and select the Marketplace tab:

Note that all add-ons on the Marketplace are completely free and open source and anyone can publish add-ons to it - see the zap-extensions wiki for details.

The Selenium add-on has been updated to include the latest version of the selenium jar - this fixes problems with the latest version of Firefox so update asap.

The Passive scan rules - alpha have been updated to include a new scanner for identifying info leaks via X-ChromeLogger-Data or X-ChromePhp-Data. See the special feature below.

Special Feature: XCOLD Information Leak

This special feature from Kingthorin (kingthorin) explains how functionality aimed at assisting developers caught the eye of an IT Security Professional:

Ottawa ended up with an uncharacteristically green Christmas this year, but finally got snow as I’m drafting this (Dec 29th), so I'm going to dub this the XCOLD Info Leak (X-ChrOmeLogger-Data).

It all started rather innocently when an item in the Firefox 43 release notes caught my eye:

With my penetration tester hat on all I could think was: “Huh? What? I can get server logs in a client? Sweet, I can think of all sorts of Low to Pwned scenarios … Yay!”

Off I went to read further:
Basically it boils down as follows:
  • Decide you want server side messages available to clients.
  • Stick some code into your web app.
    • Support seems to be quite extensive: Python, PHP, Ruby, Node.js, .NET, ColdFusion, Go, Java, and Perl. Though the majority of the existing install/usage seems to be PHP.
  • Boom get messages in the browser (Chrome requires an extension, while Firefox now has native support).
Curious to see if this was already in Production use I headed over to Shodan, to see what there was to see. The following images are courtesy of Shodan, via .

Ok so X-ChromeLogger-Data is in use. Not extensively but the numbers are increasing. The image here is from 2015-12-29, I had previously poked around on this topic around the 18th. Though I don’t remember the specific number I’d previously queried there seems to have been an increase in a short period and over the holidays.

It also seems that X-ChromePhp-Data is in use to a much lesser extent. So off I go to see what kind of data people might be exposing.

Keep in mind the following findings are based on public data, I’m not revealing anything here that the site(s) haven’t already revealed to the world.

Below I’ve just copied the Base64 encoded header values from the Shodan results and run them through the handy online decoder at

Alternative 1: Proxy your shodan result browsing through ZAP, select the base64 string and use the “Encode/Decode/Hash” context menu:

Alternative 2: You could also pop the dev tools console (F12) and do a atob(“”); and hit enter. For example atob(“ZW5jb2RlIHRoaXM=”); returns encode this. I used the online service below since the dev tools console doesn’t line wrap :(

Picking the first X-ChromePhp-Data shodan result I got the following:

Ok not terribly revealing, however it does give the entire disk location of AppController.php. Might be able to leverage that in other attacks or use the knowledge to social engineer something.

Here’s another example that’s really verbose, note Undefined index: admin references:


Here’s another, note the failures in processing various tokens, PREBODY, and HTTP_USER_AGENT. Those details might lead a pentester to another useful finding such as UA specific response or UA injection of some sort.
Here’s one that appears to be a WordPress plugin:
Here’s what seems to be a windows host running some WordPress gallery:
To top it off, here’s an example leaking raw SQL details:
I guess that’s enough examples. As you can see a ton of information is and can be leaked via this functionality.

While the benefits to a developer are obvious I would suggest that the following considerations or implementation choices be made if using the functionality:

  1. Do you want this turned on for Production use?
  2. If you do want it on for Production use can you ensure that you don’t leak information that might be leveraged by an attacker or malicious individual?
  3. Can you tie it to your authorization framework so that the information (header + content) is returned only to admins and support personnel not “all” users?
Curious if your app or site is exposing anything similar to the examples above? Do you have the XCOLD Info Leak? Checkout the new ZAP passive plugin that looks for and identifies information leaks via X-ChromeLogger-Data and X-ChromePhp-Data. This is included in the latest Passive scan rules - alpha available from the ZAP Marketplace.

Update: Here's a slide deck from a presentation kingthorin recently did on XCOLD with OWASP-Ottawa:

Upcoming Talks and Training

Akash Mahajan (@makash, the founder of The App Sec Lab) will be running a hands on workshop: "Application #SecurityTesting with OWASP ZAP" at the Open Source Summit on February 6th in Bangalore:

Featured Contributor: Paulo Brito

Each month we introduce you to one of the many ZAP contributors.

Q: Who are you?
Paulo Brito (aka PB, @pbrito1), computer security enthusiast, computer science student.

Q: Where are you based?
Campinas, Brazil

Q: What do you do in your day job?
I am a journalist. I work as a free lancer, writing mainly IT and business stories for a couple of brazilian newspapers and magazines. I also publish a blog on computer security at

Q: Why do you contribute to ZAP?
ZAP is a fantastic security tool. As I localize it for PT BR I help to make ZAP resources available for all portuguese speaking students and information security professionals. I'd love to also contribute writing code but I'm still learning, so the best way I could contribute to the ZAP community was localizing the framework.

Q: How do you contribute to ZAP?
I am currently translating the help files and the user interface. At this moment roughly 70% of the work is done. It's a lot of text, so it's taking also a lot of time. Sometimes I have to step back and retranslate when an improvement is deployed, and this will happen forever, because ZAP will always being improved.

Q: What would you like to contribute in the future?
I will certainly be available to keep the localization updated.

Q: What do you like about the ZAP community?
I like the fact that ZAP is a community with an important goal, developing an extremely important tool for web/computer security pros, and that really cares about its members, maintaining them always informed on what's going on.

Q: What do you get out of contributing?
I get the pleasure of contributing to a build a superb computer security framework, besides learning how to use ZAP and understanding how each feature is designed to check a security flaw. I also get a better understanding on how these flaws need to be fixed.

Q: Do you have any advice for people who would like to contribute to ZAP?
I would say that this is a project that's worth to contribute to. The project has a clear objective and its development is of great value to the community of information security professionals. Its members are talented people, dedicated to a good cause and deserve all the help we can give, contributing to strengthening the ZAP project.

Q: Do you contribute to any other open source projects?
No. ZAP is the only project I am currently contributing to.

Q: What do you do outside of work?
Outside of my work I like to listen classical music – I am a fan of Mozart and Bach -, watch aviation documentaries and traveling when possible.

Q: What do you [most] dislike about the ZAP development?
I don't see any point I could dislike regarding the development. To the contrary, what I see is all the coders/testers working all the time to improve the framework

Q: What do you think could be done [a lot] better?
I don't exactly how, but may be OWASP could start (if didn't yet) evangelizing on ZAP to universities faculty and students, besides doing some PR (public relations) to enlarge the users base and the volunteers community as well.


Please fill in this quick Feedback Form so that we can make sure this newsletter is as useful to you as possible.

Coming next month…

That depends on you!
Let us know what you would like to see using the above feedback form.
If you would like to write content for the newsletter then please get in touch - anything ZAP related, such as talks / training you are giving, a 3rd party tool you develop or maybe an add-on you’d like to explain in more detail.
And we’re also looking for one or more editors for the ZAP newsletter - you don't need any detailed ZAP knowledge, just a bit of time each month you can dedicate to chasing up people for content and bashing it into something that reads better than this one :P Think thats you? Get in touch!

Simon Bennetts (ZAP Project Lead)