Comprehensive Report on Zed Attack Proxy (ZAP) Scripts and Features

This report provides a comprehensive overview of Zed Attack Proxy (ZAP) scripts, a widely used open-source tool for web application security testing. It delves into various script categories, including active and passive rules, and explains their functionalities. The report details authentication methods, the role of the HTTP sender, and the Heads Up Display (HUD) for real-time analysis. It also explores payload generation, fuzzing techniques using HTTP and WebSocket processors, and session management. Furthermore, it covers the script input vector and extender features. The report highlights the importance of ZAP in identifying vulnerabilities, offering insights into its practical application in penetration testing and vulnerability assessment. The report also discusses the advantages and disadvantages of ZAP features, which helps in understanding its capabilities and limitations in ensuring web application security.

Zed Attack Proxy (ZAP) Scripts
Student’s name
Institution Affiliation(s)
Zed

Table of Contents
Active Rules.....................................................................................................................................2
Authentication..................................................................................................................................2
HTTP Sender...................................................................................................................................4
Heads Up Display (HUD)................................................................................................................4
Payload Generator...........................................................................................................................5
Payload Processor............................................................................................................................6
Fuzzer HTTP Processor...................................................................................................................6
Fuzzer WebSocket Processor..........................................................................................................7
Passive Rules...................................................................................................................................7
Session Management.......................................................................................................................8
Proxy................................................................................................................................................9
Script Input Vector..........................................................................................................................9
Extender.........................................................................................................................................10
References......................................................................................................................................11
1

The Zed Attack Proxy (ZAP)
ZAP is an instrument for finding weaknesses in web apps. ZAP is a free and open-source
and is maintained through the OWSP flagship community project making it the world’s most
popular and free open source security testing tool for web apps. The capabilities and features of
ZAP that has a massive number of developers worldwide working to produce new add-ons and
modules make it instrumental in carrying out automated web scanning and manual penetration
tests. In this paper, I am going to explore the various scripts available in ZAP.
Active Rules
A critical part of ZAP is its ability to do active scanning for those vulnerabilities that are
known, for instance, SQL injection. Active scan rules that appear like they are hidden are
encoded in java plugins making then not editable on the go. The active rules script runs
automatically during scanning. The use of a global active scan rule is essential in activating the
active scan rules. If the active rules are to be changed for any reason, then it calls for one to start
programming customizable plugins. The most common solution is by scanning scripts to create
active scan patterns (Crouch, 2012).
Authentication
ZAP handles multiple types of authentication (called Authentication Methods) that can be
used for websites or web apps. Each Context has an Authentication Method defined that dictates
how authentication is handled. The authentication is used to create Web Sessions that correspond
to authenticated web app Users (Chodakowski, 2016).
To detect when response messages from web servers correspond to authenticated
requests, a set of indicators can be configured. The Logged in symbol, when present in a
response message (either the header or the body), signifies that the response message
2

corresponds to an authenticated request, e.g., presence of a logout link or a Welcome back, User
X pattern. Similarly, the Logged out indicator indicates an unauthenticated request, e.g., presence
of a login link. If ZAP detects the logged out indicator, it will re-authenticate. Otherwise, it's
assumed that it is already authenticated and will continue as usual. Only one (1) of the two (2)
indicators is necessary for proper functionality. In the case neither of the indicators has been
specified, all messages are considered, by default, authenticated (Wilhelm, 2013).
When working with CAS, a single POST request with the credentials is not enough to
trigger the authentication. When we GET the login page, some input values used by CAS are
generated (the login ticket and some Spring Web Flow related parameters), and they must be
included in the POST request for the authentication to work. So this script sends a GET to the
login page, parses its response looking for the values generated by CAS, and sends a POST
request with these values and the credentials, which is enough to trigger the authentication, but
it's not enough to enable a successfully authenticated scan with ZAP. There is one more step that
is needed because of redirects: CAS loves them, and ZAP doesn't (Makino & Klyuev, 2015).
We have authenticated on the CAS server, for example, http://mydomain/cas-server, so
when we access the app like http://mydomain/my-app, for the first time, we will be redirected to
the CAS server. Since we are authenticated, the CAS server will redirect us back to the app:
There are two problems here: the first is that ZAP's Spider explicitly doesn't follow redirects. So
if the Spider accesses the app, it will get a redirect response, and the page will never really be
spidered (Conrad, Misenar, & Feldman, 2017). However, this redirect happens only for the first
time we access the app after the authentication, so we could just access the app once before
ZAP's Spider starts, right? Almost. This is a circular redirect, and the second problem is that
ZAP doesn't support it.
3

HTTP Sender
The HTTPS sender add-on is accessed via the context menu within the Sites Tree or
History table. It displays tabs in a status panel, in which various summary information is shown
regarding the target server's HTTPS certificate, and the offered SSL/TLS cipher suites.
This add-on leverages another OWASP project that is referred to as Deep Violent to perform its
certificate and cipher suite information gathering (Gokte, 2017).
Heads Up Display (HUD)
The browser makes a request that goes through ZAP, does the service, and comes all way
back through the ZAP. HUD injects a page in between your target on the target domain as HUD
is acting as a man in the middle, that is, between ZAP and the target. All main browsers are
supported, but only Firefox and Chrome browsers work at the moment. The HUD can break your
apps while the apps can also break the HUD, but this process can be undone through the ZAP
settings (Hamed, Dara, & Kremer, 2017). The HUD can also be exploited by an attacker to
4

attack your apps. HUD still has a long way to go a needs improvements in testing and stability,
web socket display and manipulation, expose of more ZAP features and browser event display
manipulation.
HUD has some caveats, and thus experts do not recommend using it in potentially
malicious sites. However, it is already included in the ZAP Bug Bounty program, although it
does not have all the functionalities that one needs to carry out a full pentest. HUD is an
excellent way of testing the security of apps and has its releases done every week (Hernández,
Villalba, & Lacuesta, 2018).
Payload Generator
Payload Generator allows you to select the payload generators to use when fuzzing a
request. Payload generators produce the primary attacks that the fuzzer sends to the target
application. The following types of generators are provided by default:
a) Empty or Null - generates the selected payload multiple times, leaving the message
without changes. This payload generator is useful to send various messages that are later
processed, for example, with a Fuzzer HTTP Processor Script.
b) File - select any local file for one-off attacks
c) File Fuzzers - choose any combination of the fuzzing data registered with ZAP, e.g., via
add-ons like fuzzdb
d) Numberzz - allows to generate a sequence of numbers, with custom increment easily
e) Regex - generate attacks based on regex patterns (Hamed et al., 2017).
f) Strings - raw strings, that can be entered manually or pasted in
g) Script - custom scripts that can create any payloads required
h) Json - generate attacks by fuzzing the provided json
5

You can write custom payload generator scripts - these can supply any payloads that you need.
Add-ons can also define additional payload generators.
Payload Processor
The Payload Processor button launches the Payload Processors dialog, that allows you to
configure payload processors that apply to the payload generator you have selected.
Fuzzer HTTP Processor
We can explain fuzzing as a method of sending or submitting many unexpected or invalid
data to a target. ZAP will allow users to fuzz requests while using:
a) A build-in set of payloads (Conrad et al., 2017).
b) Payloads defined by optional add-ons
c) Custom scripts
To access the Fuzzer dialog, you can either:
a) Right-click a request in one of the ZAP tabs such as the History or Sites and select Attack
or Fuzz.
b) Highlight a string in the Request tab, right-click it and select Fuzz
c) , then select the Tools fuzz menu item and then select the request you want to fuzz
. Allows selecting the enabled Fuzzer HTTP Processor scripts. The scripts will allow you to:
a) Obtain the list of payloads
b) Stop fuzzing
c) Increase the error count
d) Send new messages
e) Add messages to the Results tab
f) Set custom state messages in the Fuzzer tab
6

g) Raise alerts
Scripts can include both Required and Optional parameters the values for which the user will
be prompted to provide when the Processor is added to the fuzzer. The parameter names are
defined within the script(s) via the methods getRequiredParamsNames and
getOptionalParamsNames, each of which simply returns an array of strings representing the
names of the parameters.
Fuzzer WebSocket Processor
Fuzzer WebSocket Processor scripts are called before forwarding a fuzzed WebSocket
message to the client or server. The payloads will have already been injected at this point
(Wilhelm, 2013). A template script is provided, that gives details of the methods and parameters
supported.
Passive Rules
The following are some of the release quality passive scan rules for ZAP.
a) Application Errors - Check server responses for HTTP 500 - Internal Server Error type
responses or those that contain a known error string.
b) Cache-Control - Checks Cache-Control and Pragma response headers against general
industry best practice settings for the protection of sensitive content (Wilhelm, 2013).
c) Charset Mismatch - This check identifies responses where the HTTP Content-Type
header declares a charset different from the charset defined by the body of the HTML or
XML.
d) C
e) SRF Countermeasures - This scanner identifies potential vulnerabilities with the lack of
known CSRF countermeasures in pages with forms (Lewis, 2017).
7

f) Insecure Authentication - Digest authentication or HTTP essential has been used over an
unsecured connection. The details can be read and then reused by someone who has
access to the network.
g) Private Address Disclosure checks the response content for the inclusion of RFC 1918,
IPv4 addresses as well as Amazon EC2 private hostnames that can give an attacker useful
information about the IP address scheme of the internal network. It might be helpful for
further attacks targeting internal systems (Wilhelm, 2010).
Session Management
This scanner checks for the existence of session token type parameters being rewritten to
the URL. To help reduce false positives, the scanner checks the length of the symbolic value. If
the value of the parameter is not greater than eight characters in length, then the parameter is
ignored. This tool automatically detects, using the defined session tokens or the automatically
detected default session tokens, any HTTP session that exists in the communication. The
detected sessions are shown in the HTTP Sessions Tab (Wright, 2008).
The user can, using the button available on the HTTP Sessions Tab, create a new session
without destroying the existing one, or can force one of the sessions as active. When a session is
active, all the outbound requests sent to the corresponding Site are modified, the session tokens
being set up to match the active session. In this way, the user can easily force some messages to
be part of a particular session and then switch and send messages on another session (Beuchelt,
2017).
Proxy
The Scripts tree tab shows you all of the scripts you currently have loaded organized by
type. It also explains to you the templates you have available - these cannot but run directly, you
8

use them to create new scripts. It also allows you to add new scripts, load, save, and remove
them (Gantz, 2014). The tab include a toolbar that will enable you to:
a) Load a script from filestore
b) Save a script to filestore
c) Create a new script
Scripts that are run within ZAP components, such as the Active Scanner, can be enabled and
disabled via the right-click menu option. All scripts can be removed from the UI via a right-click
Remove Script menu option (Hamed et al., 2017).
Script Input Vector
This screen allows you to configure the active scan input vectors. These are the elements
that the active scanner will attack. Scanning all of the features supported will take longer, but not
scanning some elements may cause some vulnerabilities to be missed.
If the enable script input vector option is selected, then the active scanner will use any
enabled script input vectors. Script input vectors are scripts that you have written or imported
into ZAP and allow you to target elements that are not supported by default. This screen also
allows you to configure the parameters which will be ignored by the active scanner (Broad &
Bindner, 2014).
Extender
Enabled extensions will be loaded by ZAP, thus adding the functionalities provided by
those extensions. Disabled extensions will not be loaded. Core extensions are extensions that, if
disabled, will impair ZAP's minimal functionality. Extensions marked as the core cannot be
disabled. Extensions may depend on other extensions to work (Engebretson, 2013a). When one
of those extensions (dependencies) is disabled, it will make ZAP automatically disable all the
9

extensions that depend on them. So it may happen that when disabling one extension, other
extensions that rely on it will also be disabled. Automatically disabled extensions will not be
allowed to be enabled until all the dependencies are enabled (Engebretson, 2013b).
10

References
Beuchelt, G. (2017). Chapter 10—Securing Web Applications, Services, and Servers. In J. R.
Vacca (Ed.), Computer and Information Security Handbook (Third Edition) (pp. 183–
203). https://doi.org/10.1016/B978-0-12-803843-7.00010-7
Broad, J., & Bindner, A. (2014). Chapter 9—Exploitation. In J. Broad & A. Bindner (Eds.),
Hacking with Kali (pp. 131–166). https://doi.org/10.1016/B978-0-12-407749-2.00009-4
Chodakowski, K. (2016, October 25). Introduction to Zed Attack Proxy. Retrieved March 14,
2020, from Research.securitum.com website:
https://research.securitum.com/introduction-to-zed-attack-proxy/
Conrad, E., Misenar, S., & Feldman, J. (2017). Chapter 3 - Domain 3: Security engineering. In E.
Conrad, S. Misenar, & J. Feldman (Eds.), Eleventh Hour CISSP® (Third Edition) (pp.
47–93). https://doi.org/10.1016/B978-0-12-811248-9.00003-6
Crouch, A. (2012, December 5). Security Testing: OWASP ZAP (Zed Attack Proxy). Retrieved
March 14, 2020, from Coveros website: https://www.coveros.com/security-testing-
owasp-zap-zed-attack-proxy/
Engebretson, P. (2013a). Chapter 6—Web-Based Exploitation. In P. Engebretson (Ed.), The
Basics of Hacking and Penetration Testing (Second Edition) (pp. 141–165).
https://doi.org/10.1016/B978-0-12-411644-3.00006-6
Engebretson, P. (2013b). Chapter 8—Wrapping Up the Penetration Test. In P. Engebretson
(Ed.), The Basics of Hacking and Penetration Testing (Second Edition) (pp. 187–198).
https://doi.org/10.1016/B978-0-12-411644-3.00008-X
11

Gantz, S. D. (2014). Chapter 10—Audit-Related Organizations, Standards, and Certifications. In
S. D. Gantz (Ed.), The Basics of IT Audit (pp. 197–219). https://doi.org/10.1016/B978-0-
12-417159-6.00010-9
Gokte, S. (2017, December 15). An intro to OWASP Zed Attack Proxy. Retrieved March 14,
2020, from Srijan website: https://www.srijan.net/blog/intro-owasp-zed-attack-proxy
Hamed, T., Dara, R., & Kremer, S. C. (2017). Chapter 6—Intrusion Detection in Contemporary
Environments. In J. R. Vacca (Ed.), Computer and Information Security Handbook
(Third Edition) (pp. 109–130). https://doi.org/10.1016/B978-0-12-803843-7.00006-5
Hernández, S., Villalba, T., & Lacuesta, R. (2018). MQTT Security: A Novel Fuzzing Approach
[Research Article]. https://doi.org/10.1155/2018/8261746
Lewis, K. (2017). Chapter 4—Verifying User and Host Identity. In J. R. Vacca (Ed.), Computer
and Information Security Handbook (Third Edition) (pp. 59–65).
https://doi.org/10.1016/B978-0-12-803843-7.00004-1
Makino, Y., & Klyuev, V. (2015). Evaluation of web vulnerability scanners. 2015 IEEE 8th
International Conference on Intelligent Data Acquisition and Advanced Computing
Systems: Technology and Applications (IDAACS), 1, 399–402.
https://doi.org/10.1109/IDAACS.2015.7340766
Wilhelm, T. (2010). CHAPTER 5—Creating and Using PenTest Targets in Your Lab. In T.
Wilhelm (Ed.), Professional Penetration Testing (pp. 119–151).
https://doi.org/10.1016/B978-1-59749-425-0.00009-9
Wilhelm, T. (2013). Chapter 3—Setting up Your Lab. In T. Wilhelm (Ed.), Professional
Penetration Testing (Second Edition) (pp. 37–74). https://doi.org/10.1016/B978-1-59749-
993-4.00003-3
12

Wright, C. (2008). Chapter 18—Auditing Web-Based Applications. In C. Wright (Ed.), The IT
Regulatory and Standards Compliance Handbook (pp. 515–560).
https://doi.org/10.1016/B978-1-59749-266-9.00018-7
13