We’ve always been huge advocates of using automation to hasten the bulk of application security testing. When you integrate security tools into the continuous development cycle, it helps you find and fix security issues earlier than would otherwise be possible.

Security tools have gotten increasingly sophisticated in the last few years, and a whole bunch of them support automation to help you speed up security testing and identify vulnerabilities.

See More: Automatically upload ZAP scan results to be correlated

But there exists a class of vulnerabilities linked to an application’s functionality which can be hard for most tools to pick up.

Trust us to not take no for an answer. We simply had to try and modify our tools so they could  identify these specific vulnerabilities.

In this article, we’ll be looking at how to modify the functionality of the OWASP Zed Attack Proxy (ZAP), one of the most widely used open source DAST tools.

Upcoming Webinar: Automate ZAP & Burp testing on Jenkins with Cypress


Why did we pick ZAP?

ZAP, being open-source and completely free, is widely used by security professionals for both automated vulnerability scanning and manual penetration tests. It boasts some of the best features of any security tool and a has large support community, so there’s no shortage of scripts, plugins and add-ons available online. The tool also has a very well-defined and documented API, which makes it effortless to access all its features.

Read More: 7 features that make ZAP great for Application Security Testing

Why Scripting?

ZAP might be an open source tool, but it’s still difficult to actually make changes to the core software and recompile the code to include a very specific feature. And that’s exactly what we’re trying to do here.

ZAP has a scripting engine which can be used to modify its functionalities and extend its features through a simple interface. It provides us with the ability to write and develop different types of scripts within the tool itself. ZAP can access all the internal data structures including objects and methods. You can use any scripting language that supports JSR 223, like ECMAScript, Javascript, Zest, Groovy, Python, Ruby and several others.

webhooks - screenshot-1

The Scripts tree tab and Script Console tab

Script Console tab

This tab is used to write scripts which can be run within ZAP and also has a debug area which also displays error messages. It also provides a basic autocomplete feature which assists with the methods available associated to an object.

Scripts Tree tab

This tab consists of a tree of all the scripts organised based on its type. While creating a new script, it also gives an option to create a template which gives a basic structure of the type of script. The scripts can be saved as a file and loaded, and also enabled/disabled/removed whenever needed.

These scripts are categorised based on the specific functionality of the scripts. The different categories of scripts are:

Standalone – These are scripts which have a very specific functionality and are run only when initiated manually.

Targeted – These scripts are similar to Standalone scripts, but can be run on a specific set of URLs from the site tree. This scripts can be run on a subset of all the URLs in the application. This script can be run by right-clicking on the site tree and the script is invoked and runs only on the specified target.

Proxy – Scripts that will run against the msg that is being proxied through ZAP. These scripts can be used to replace a part of the request or response as the msg is being sent.

HTTP Sender – A proxy script will run only on the messages passing through the proxy, the HTTP sender will run on all request/response sent/received by ZAP.

Passive scan Rule – Passive scan scripts are scripts that would be run as part of a passive scan. The passive scan runs as soon as messages are proxied through ZAP. The passive scan does not make any request and only performs a static scan of all the messages captured by ZAP.

Active Scan rule – Active Scan Scripts are scripts that would be run whenever an active scan is initiated. These are scripts which would send requests to the application with malicious content as part of the request to find vulnerabilities.

Authentication Scripts – Authentication can be done using scripts to automate the authentication process. Once these scripts are written, they can be included as part of a context as a method of authentication into an application with different users with different privileges.

Sequence Scripts – Sequence scripts are used to simulate an ordered set of actions. This could be accessing certain pages in a specific order or performing certain actions in the pages.

A sequence script can be given as an input while initiating an active scan to scan only the requests part of the sequence. This can be accessed in the sequence tab when ‘Show advanced options’ is selected.

Script Input Vectors – These scripts allow us to specify custom input vectors that can be used to attack during active scans. We can extract the parameters from the HTTP requests and set the new value (attack) of the parameter when called by the scanners during the active scan.

Useful Modules: ZAP Scripting with Python (Jython)

The objects and methods shown below are extremely useful while writing scripts in ZAP.

#the message object that is acted upon to parse/manipulate

 #Request Header Object

  #fetches the URI from the request header

#Fetches the request body from the request

 #Fetches the request body from the request

   #Sets a different request body from the one in the original request

Passive Scan Rule script (example):

We know a passive scan will perform a static analysis of the request and responses. We may have a specific test case which might not be part of the ZAP passive scan engine. One such example would be to search for any sensitive information that we may have exposed on the client side. We can write a custom passive test case for this to look for such patterns. The script shown below is to actually look for AWS secrets that might be exposed on the client side.

Passive Scan Rule script

The script will look for the pattern “awsKeyId=”,”secretAccessKey=” on the client side. We could change the “searchlist” parameter to identify any pattern that may be sensitive in your application.

Active Scan Rule Script (example):

ZAP has a very extensive RULE Engine for the Active scans. But what if you have a vulnerability that ZAP isn’t checking? We can write a custom script for identifying those vulnerabilities in our application. In the script shown below, we’ll see how we can write a script to identify vulnerabilities in the way JWT tokens are handled by certain libraries.

JSON Web Token is a JSON-based open standard (RFC 7519) for creating access tokens that assert some number of claims. The token is Base64 Encoded and will have three parts when decoded. The Header, Payload and the Signature verify the integrity of the token.

JSON Web Token

Decoded JWT token

The Header has an “alg” parameter which is used to specify the algorithm used to generate the signature which may be HS256 (HMAC with SHA-256)  and RS256 (RSA signature with SHA-256). Interestingly the “alg” parameter also accepts the value “none”, which is used when the integrity of the token has already been verified.

Some libraries treat tokens signed with the “none” algorithm as a valid token with a verified signature. An attacker may leverage this vulnerability to create his/her own “signed” tokens with whatever payload they want, allowing the attacker to get access resources with an invalid token.

To test this we need to send a token with “alg” as “none” and check if the server is honouring the token.


JSON Script 1-1

JSON Script 2-1

ZEST Scripts

Zest is a language developed by the Mozilla security team. ZAP has an add-on for Zest that’s included by default as part of the tool. Zest scripts are intended to be written using graphical interfaces, making it easy to develop these scripts.

Zest script can be recorded by clicking on the “record new Zest script” button in the toolbar in ZAP as shown in the image below.


When we click on the record button, we will be prompted with a tab in which we can set the parameters related to the Zest script. We can choose the type of script that we intend to record (standalone, sequence or an authentication script). Once we start recording, the messages proxied through ZAP will be transformed to the Zest script is JSON format as shown in the image below.


The Zest script can be edited by right-clicking on the request in the script tab and adding statements such as loops, assertions or conditions. Zest can be used to generate scripts which could be used to perform actions like authentication, traversal of a web application or validate existence of manually found vulnerabilities.

Community Script

This community script repository has a large number of scripts of different types created by the community.

The scripting aspects of ZAP that we’ve discussed opens up limitless possibilities for new features and functionalities you’d want to integrate into the tool.


Leave a Reply

Your email address will not be published. Required fields are marked *