# OWASP ZAP

## Summary


Software security testing is the process of assessing and testing software to discover security risks and vulnerabilities. Such testing could be a **passive scan** to look for vulnerabilities. Or it could be an **active penetration test** (aka pen test) that simulates malicious users attempting to attack the system. 

In complex systems, it's difficult to manually determine all possible vulnerabilities. The **Zed Attack Proxy (ZAP)** is an open source tool to automatically find vulnerabilities in web applications. It's part of the *Open Web Application Security Project (OWASP)*. 

ZAP can be used as a man-in-the-middle between browser and app server. It can also be used as a standalone application, or as a daemon process without UI. ZAP is suitable for experienced security professionals as well as web developers and functional testers.

## Discussion

### Why should I use ZAP?

ZAP is free and open source. ZAP is for experts as well as beginners. Based on Java, it's cross-platform and hence it can be used on Windows, MAC or Linux. It's also easy to install and use. It's fully documented and there are plenty of community resources to help those who are new to ZAP. It's internationalized with translated versions in many languages. We can also use it with other tools that enable CI/CD workflows. Thus, it's flexible and extensible. 


### Could you describe some important ZAP terminology for beginners?

The following may be a starting point for beginners: 

    + **Contexts**: Typically, a context will correspond to a web application. It's a way of grouping together a set of URLs.
    + **Scope**: Defined by contexts, it's the set of URLs to test.
    + **Modes**: Each mode allows for certain types of attacks. This gives flexibility while testing. Selecting the mode affects the scope.
    + **Alerts**: An alert is a potential vulnerability. It's associated with a request. A request can have multiple alerts. An alert is flagged with a risk level: High, Medium, Low, Informational, False Positive.
    + **Tags**: A short text associated with a request. A request can have multiple tags. Passive scanning can do automatic tagging based on preset rules.
    + **Notes**: You can associate text with a request. These are for your reference or later action.
    + **Add-ons**: Add extra functionality to the ZAP core. They can be installed from the online Add-on Marketplace. Examples include Ajax Spider, Diff, Forced Browse, Fuzzer, etc.
    + **Replacer**: This is an add-on to replace strings in requests and responses.

### What are the modes in which I can use ZAP?

As of version 2.5.0, ZAP can be used in one of four modes: **Safe**, **Protected**, **Standard** and **ATTACK**. As the names suggest, Safe mode will avoid anything potentially dangerous while ATTACK mode will aggressively try to attack new URLs as soon as they are discovered. You can configure the ATTACK mode behaviour using *Scan Policy*. When pen testing is desired on sites you have permission to test, Protected mode can be used. Standard mode allows for all types of attacks. 

In both Safe mode and Protected mode (for URLs out of scope), ZAP will not perform certain types of attacks. These include spider crawling, active scanning, fuzzing, force browsing, breaking (intercepting) and resending requests. 


### How can I use ZAP as a proxy?

ZAP can be used as **intercepting proxy**. It stands between the tester's browser and the web application so that it can intercept and inspect messages sent across, and then forward them to the destination. In passive scan, message contents are not modified. In active scan, they are modified to simulate attacks. 

To use ZAP as a proxy, you must update configuration in ZAP as well as the browser you intend to use for the tests. Configuring Proxies page on ZAP Wiki gives the details. Once you have configured ZAP as your browser's proxy, connect to the web app under test. ZAP should now start showing one or more entries in the Sites and History tabs. These are requests and responses that ZAP has intercepted for analysis.


### How will ZAP determine what to test in my web application?

ZAP uses a mix of techniques some of which may require a test engineer's help. One of the simplest is to use the **Quick Start** add-on. You enter a URL, typically the home or sitemap URL of the web app. ZAP will crawl it using its Spider add-on. This will give ZAP a list of URLs to test. It will then do an active scan of these. 

For a more in-depth test, you should put ZAP in proxy setup. Then, manually explore your application using your browser. Alternatively, perform automated regression using Selenium or similar tool. ZAP will capture all the requests and responses. It can then use them later to do an attack. 


### What is Spider?

Web spiders and crawlers are commonly used by search engines to discover Internet content. In the context of ZAP, **Spider** is an add-on. It's used to automatically discover new resources (URLs) on a particular site. It begins with a list of URLs to visit, called *seeds*, which depends on how the Spider is started. The Spider then visits these URLs, identifies all the hyperlinks in the page, and adds them to the list of URLs to visit. This process continues recursively until new resources are not found.

Spider can discover URLs that are not visible as links on pages. 

Sites that are Ajax heavy cannot be effective crawled by Spider. An alternative add-on created by Guifre Ruiz, called **Ajax Spider**, should be used. For good coverage, both spiders should be used.


### What are Passive Scan and Active Scan?

Apart from using Spider, there are broadly two different ways in which ZAP looks for vulnerabilities: 

    + **Passive Scan**: ZAP by default passively scans all HTTP messages (requests and responses) sent to the web application. Passive scanning does not change the requests and responses in any way, and is therefore safe to use.
    + **Active Scan**: Attempts to find potential vulnerabilities by using known attacks against the selected targets. You must perform active scan only if you have permission to test the application. *Fuzzing* is a technique that can be used as part of active scanning. With fuzzing, invalid or unexpected data is submitted to find vulnerabilities.Rules used for passive and active scans are well documented. 

Logical vulnerabilities, such as broken access control, will not be found by any active or automated vulnerability scanning. Manual penetration testing should always be performed in addition to active scanning to find all types of vulnerabilities. 


### Can ZAP be used as part of a CI/CD pipeline?

Automated pen testing is possible with ZAP and this is an important part of continuous integration. It helps to uncover new vulnerabilities as well as regressions of previous vulnerabilities in an environment that is changing quickly, and for which the development may be highly collaborative and distributed. In fact, ZAP is available as a plugin for Jenkins. 

ZAP provides a Rest Application Programming Interface (API) that allows other tools to interact with ZAP programmatically. Other tools can make use of this API to trigger attacks. The ZAP API is available in JSON, HTML and XML formats. The ZAP API is particularly useful for Security Regression Tests.

Beginners can use a simple web UI to explore and use the API: at `http://zap/` when you're proxying via ZAP; or via the host/port ZAP is listening on, such as `http://localhost:8080/`.

As part of cloud-based workflows, in one example, Microsoft has explained how ZAP can be used in Azure. For passive scans, it can be part of CI/CD pipelines. For longer active scans, a nightly pipeline is preferred. 


### My site runs on HTTPS. How does ZAP handle SSL certificates?

Since ZAP is set up to act as a proxy between your browser and the web application, using SSL (HTTPS) will cause the certificate validation to fail and the connection to be terminated. This is because ZAP encrypts and decrypts traffic sent to the web application using the original web application certificate. This is done so that ZAP can access the plain text in the requests and responses. 

To prevent this failure from happening, ZAP automatically creates an SSL certificate for each host you access, signed by ZAP's own Certificate Authority (CA) certificate. To have your browser trust these SSL certificates, you need to first import and trust the ZAP Root CA certificate. Once it is trusted, the other ZAP SSL certificates signed by it will be trusted as well. 

ZAP Root CA certificate is required only for active scans. For passive scans, since content is not modified, the web app's original certificate can be used.


### Could you share some user stories and case studies of ZAP?

OWASP ZAP is used by countless organizations across the globe for validating their web application security postures, from governments agencies and educational institutions to large enterprises. Some of these include Mozilla, Microsoft, Ernst & Young, Accenture, and Google.

It's been commented that the alert levels flagged by ZAP don't always correspond to reality. A minor risk may be flagged as High and vice versa. Reporting is in HTML and this could be improved. 


### What are the alternatives to using ZAP?

There are plenty of alternatives to ZAP offering similar or subset of features. Some of these include Burp Suite, Nikto, Acunetix, w3af, Arachni, Andiparos, HTTP Analyzer, etc. 

When comparing alternatives, we need to consider many aspects: features, ease of installation/upgrade, ease of use, learning curve, cost, support (commercial or community), release rate (how often tool is updated), API and extensibility, available third-party integrations, etc. UpGuard's **CSTAR Score** is one way to quantitatively compare the alternatives, where CSTAR stands for *Cybersecurity Threat Assessment Report*. For example, Arachni scores only 399 whereas ZAP scores 788. 

CSTAR Score is also a quick and objective way for business stakeholders to assess security compliance without looking into the details. For example, an audit of the healthcare sector in 2016 revealed a low CSTAR score of 420 (danger zone). 

## Milestones

2005

Based on Java 1.4.2, **Paros Proxy** is released as a tool to test security vulnerabilities in web apps. 

2012

Simon Bennetts forks Paros Proxy and experiments with it as a way to learn about security tools. ZAP takes its birth from here. In December, ZAP 2.0.0 is released. This release contains contributions from three GSoC (Google Summer of Code) Projects that enhance the capability of ZAP. Meanwhile, Guifre Ruiz creates **Crawljax** (aka Ajax Spider), an open-source Java spider for AJAX web apps. 

2014

Add-on **SOAP Scanner** is released. It comes out of GSoC2014. Scanned and detected WSDL files are now read and SOAP petitions now follow the correct format. 

May  
2015

Not meant for desktop environments, **ZAP as a Service (ZaaS)** is proposed. The idea is to run in 'server' mode: "long running, highly scalable, distributed service accessed by multiple users with different roles". 

2016

The **ZAP Sonar Plugin** is available for reporting into SonarQube v6.3 or higher. The official **ZAP Jenkins Plugin** is released. This extends the functionality of the ZAP security tool into a CI environment. 

2017

Introducing the **JxBrowser** add-on for ZAP. With **ZAP Browser Launch** we can now launch a browser from within ZAP. In November, ZAP 2.7.0 is released.