OWASP Zed Attack Proxy: Swiss Army Testing

ZAP Features & Specifics

• Proxy capture
• Traditional and AJAX Spiders
• Automated scanner
• Passive scanner
• Forced browsing
• Fuzzer
• Dynamic SSL Certificates
• Websockets support
• Authentication and session support
• Powerful REST API
• Automatic update option
• Integrated extensions and a growing market of add-ons
• Open source code
• Cross-platform
• Prioritized ease of use
• Comprehensive help
• Fully localized
• Translated into dozens of languages
• Based on the encouraged community
• Is being developed by an international team of volunteers

Getting Started With ZAP

The solution consists of two major sections. The first one is an automated vulnerability scanner that detects threats, gathers more information on them to avoid false reports, and informs a developer, DB administrator, or other specialists about the necessity of closing the security breach.

The second section is a request debugger that helps manually analyze the existing system requests and responses, as well as modify and check the triggers to events that the system might potentially be vulnerable to.

ZAP Vulnerability Scanner

To start using ZAP:

1. 1. 1. Open Terminal and enter zaproxy. This opens the UI.
      2. Enter the website URL and click “Attack”.

After that, the spider starts building the sitemap and the scanner performs various tests with the pages found. On detection of vulnerabilities, digits nest to the flags appear. Red ones indicate serious threats (like SQL injections and XSS). The vulnerable pages are also marked on the sitemap.
              3. To view all the detected vulnerabilities and security notices, click the “Alerts” tab.

In the left pane, the detailed list of vulnerabilities with their locations is displayed. In the right pane is the general vulnerability information:

• Details of the detected vulnerability and alert level.
• Vulnerability description.
• Solution suggestions.
• Link to the article on this vulnerability with additional information.

Also, check out the “Spider” tab.

This tab displays the route that the spider made, which pages have been removed from the inspection map (not from the scanned website domain), and which pages have been added to the map to scan further.
As the result, the received URLs are scanned for vulnerabilities. You can track the progress of it on the “Active Scan” tab.

This tab provides the following information:

• Time of the inspection request.
• Type of request.
• Request URL.
• Response code.
• The size of the request and response.

The information you can gather from these three tabs is usually enough to draw conclusions on how to optimize the system.

ZAP Debugger

Moving on to the second section. The ZAP debugger can work both with browsers and mobile devices (smartphones and tablets on different platforms). In order to go through the browser requests to ZAP, you have to adjust several settings.

First, navigate to the “Local Proxy” settings section and check the request port. By default, it’s 8888.

Then, go to the browser settings and change them to proxy using the same port. You can also use various extensions like FoxyProxy, SwitchyOmega, etc. to simplify this procedure.
After all the setting is done, you can check the necessary operation in the browser. Eventually, you’ll be able to see all the requests and responses executed.

Like all other tools of the class (Charles, Postman, etc.), ZAP displays all the necessary information on the requests and responses:

• Headers
• Cookies
• Body
• Request/response codes

You can also use these requests, modify them, and use them for testing. Also, you can use Zest – a scripted language for autotests, created specifically for ZAP.
Let’s try to do a test. For this:

1. Select the existing request.
2. Right click the request and select “Add to Zest Script”.

    3. In the pop-up, fill in the name and save the script.

   4. Now the script has to appear in the “Scripts” tab on the left menu. To see the body of the script in the JSON format, click the script. There are three parts of the script: general information on the            script type, script body that indicates which request it is going to send, checks indicating what you are about to check.

  5. Double-click the check type to open the menu and apply changes to checks.
After the script starts, the results are displayed in the “Zest Results” tab on the bottom menu. The information displays the following items:

• Script execution time.
• Response codes.
• Response sizes.
• Results of the check.

This is just a tiny bit of the ZAP auto testing creation capabilities. It supports all the basic auto testing functional features:

• Websockets support.
• Creation of global and local variables.
• Creation of request handling rules.
• Support of various authorization types.
• Proxy deployment (to pass the requests and responses to another tool).
• Template creation capabilities for multiple reuse in further tests.
• Usage of random values in the tests (fuzzer).

Manual ZAP Testing

Let’s get back to the manual testing, specifically to the exploratory testing. One of the baddest killer-features of ZAP is the ability to use the breakpoints which can be placed on the requests and responses. Similar functionality is presented in other debuggers like Charles and Fiddler, but here it’s more convenient and it’s totally free.

Using breakpoints in ZAP is really easy – right-click the existing request received from the browser via proxy, then click “Break”, and then specify the additional parameters if necessary.

To trigger the breakpoint, repeat the same request in a browser:

Now you can apply changes to any request parameter, cookie, etc., and send the modified request. The received response can be changed, viewed, and simulated on the client side.

This is how ZAP can become your Swiss army knife for testers of any qualification and direction – from rookie to manual tester, to security tester, writing complicated tests.