Introduction to OWASP ZAP for web application security assessments

The OWASP Zed Attack Proxy (ZAP) is one of the world’s most popular web application security testing tools. It is made available for free as an open source project, and is contributed to and maintained by OWASP. The Open Web Application Security Project (OWASP) is a vendor-neutral, non-profit group of volunteers dedicated to making web applications more secure. The OWASP ZAP tool can be used during web application development by web developers or by experienced security experts during penetration tests to assess web applications for vulnerabilities.

In this article, we will take a look at this tool with the aim of discussing the different features it provides and its strengths.

OWASP ZAP overview

The OWASP Zed Attack Proxy is a Java-based tool that comes with an intuitive graphical interface, allowing web application security testers to perform fuzzing, scripting, spidering, and proxying in order to attack web apps. Being a Java tool means that it can be made to run on most operating systems that support Java. ZAP can be found by default within the Kali Linux Penetration Testing Operating System, or it can be download from here and run on OSs that have Java installed. The OWASP ZAP proxy borrows heavily in GUI appearance from the Paros Proxy Lightweight Web Application security testing tool. Kindly see this article for a detailed look at the Paros Proxy tool.

Launching the OWASP Zed attack proxy

OWASP ZAP is found by default within the latest Kali Linux 2.0 Penetration Testing Linux distribution. It can be launched by navigating to the “Applications” menu and selecting the “Web Application Assessment” option. A list will appear showing the different tools used for web app security testing. Here we click on the OWASP ZAP tool and wait for it to launch. This can be seen below:

To launch OWASP ZAP via the terminal, simply type in “owasp-zap”.

Note that, on first launch, a license agreement shows up that we are required to accept before proceeding. It is important to read this in order to understand the implications of using the tool in different jurisdictions.

The GUI launches and ZAP asks us whether we would like to work within a persistent session where our results are regularly saved so that we can resume testing the web application.

We will choose the second option and select a location to store the persistent session so that, whenever we want to proceed from where we stopped, we simply load the saved profile.

The GUI contains three main windows, as seen in the screenshot below:

OWASP ZAP GUI overview

As seen above, the GUI window is divided into three major sections:

Left Section

The left section of the ZAP window shows the “Context” and “Sites” dropdown buttons. Occasionally, multiple websites can be targeted for scanning and they appear under the “Sites” dropdown. However, a specific website might be of interest. In this special case, it must be specified under the “Context” section. Consider this to be the scope of testing.

Right Section

Here, we are provided with a URL section where we are required to specify the target for scanning. The “Attack” button commences the attack on the target and the “Stop” button halts the attack. A security tester might be interested in manually probing a website for vulnerabilities. ZAP allows him/her to launch the browser of choice with the loaded URL for manual testing. This can be achieved by clicking on “Launch Browser” below the URL. Detected issues are still logged and sent onto the bottom section.

Bottom Section

This section contains six tabs that are vital in showing the activities taking place during the vulnerability scan. Below the tabs is a progress bar that displays the scan progress, number of sent requests, and allows for exporting of the details in CSV format.

The “History” tab displays the websites being tested. In this case we are testing only a single target, so the history record will show a single entry.

The “Search” tab allows the tester to make searches that fit any patterns. For instance, let us query all the GET requests that have been made and, as shown below, we are presented with information on all these.

Clicking on the first request gives more detail on the top right window as shown below:

The “Alerts” tab gives more detail about the issues discovered on the target being scanned. Issues are ranked by severity, with “Critical” being considered highest on the risk index and shaded red, “High” of considerable high risk and shaded orange, “Medium” of slight high risk and shaded yellow, “Low” of that which could lead to either high or medium risk, exposure of sensitive information or a compromise of the target, and shaded blue.

As can be seen above, seven issues have been discovered. We shall revisit this as we take a look at how to attack websites.

The “Spider” tab shows the files crawled (discovered) within the web application. Spidering can be likened to Fuzzing, where the directories and files resident on the website are discovered and logged for later active vulnerability scanning.

Spidering is important in discovering the entry points into the web application and what links are beyond the scope of attack. A progress bar is important in indicating the spidering progress as well.

The last tab is the “Active Scan.” This is vital in showing the progress of the ongoing scan in real time, with every processed file being displayed.

The screenshot above shows the “Active Scan” tab with options to pause or stop the scan as well as a progress bar with the status and number of current scans running.

Web application security assessments with OWASP ZAP

In order to perform web application security testing to discover vulnerabilities, we launch ZAP.

Once launched, the initial mode (attack mode) allows us to attack websites that are specified within the URL section at the right-hand window. We shall be using http://www.webscantest.com/, which is a web application that has been intentionally left vulnerable to web application attacks.

On clicking on “attack” above, ZAP progresses to scan the target website for vulnerabilities, and reports them. Alternatively, we can set up an intercept on our browser by clicking on the “Launch Browser” button under the “Attack” button. This ensures that all the websites visited by the browser are scanned for vulnerabilities every time they are visited.

ZAP proceeds to scan the target website for any vulnerabilities, and discovered issues are sent to the “Alerts” tab at the bottom window. Alerts are identified as per the OWASP top 10 listing of the most prevalent web application vulnerabilities.

As shown above, the first issue on the “Alerts” tab is identified as “Cross Site Scripting”. This is a vulnerability that allows attackers to inject malicious JavaScript code into the web application input fields. ZAP identifies that by injecting a payload onto the URL of the website; the application will respond in a manner as to process the injected code. The injected payload “<script>alert(1);</script>” used is injected onto the URL as shown below:

http://webscantest.com/business/account.php?accountId=<script>alert(1);</script>

The result can be seen in the screenshot below:

The second discovered vulnerability shows the improper use of operating system commands within the web application, allowing attackers to abuse these commands to read files contained within the server hosting the web application.

Consider the originally intended use of the whois functionality below:

The intended use of this functionality is to return the correct details of a public IP address, to show information including geographical location of the hosting company, IP address network range in CIDR format, registration date, etc. In the screenshot above, we query information on Google’s DNS server, IP address 8.8.8.8. As intended, the application responds as intended. However, we can check to see whether proper input sanitization has been performed on the input field by injecting a malicious payload (ZAP&cat /etc/passwd&).

The response is shown below:

The web application responds by disclosing the contents of the password file within the Linux server located at /etc/passwd. This is a very dangerous vulnerability because it could allow attackers to read any file within the server. The vulnerability above can be avoided by ensuring that library calls are used instead of external processes to achieve the desired functionality.

The third discovered vulnerability, ranked as MEDIUM, is a directory indexing issue. ZAP reports that, by visiting certain directories within the URL, an attacker is able to gain access to files resident on the back end of the server, such as files containing code. This is illustrated below:

In the event that improper permissions have been set, an attacker may be able to navigate through various directories within the web application and download these sensitive files.

Scan results report

After the assessment of the web application is complete, ZAP allows the security tester to generate a comprehensive report with the discovered vulnerabilities. Reports can be generated in various formats, including HTML, XML, JSON and MD (markdown).

To generate a report, from the menu bar select “Report” and then select “Generate HTML Report.” We shall use the HTML format for this article. You will then be required to specify the storage destination, and generate the report.

The screenshot below shows the generated report:

The report contains important information, including a summary of alerts classified according to their severity, the description of each vulnerability, the affected URL, the method used to obtain the affected file, the injectable parameter where the payload is to be applied, and, finally, the malicious payload.

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

Conclusion

The OWASP ZAP tool is an important tool that proves handy during the development and testing of web applications. As we have seen above, some flaws can be so deeply hidden within the application that the only way to discover the vulnerabilities is by using a tool such as OWASP ZAP. This tool combines the abilities to perform both automated scans as well as allowing the tester to manually sift through pages, tampering through requests.

Sources

• OWASP Zed Attack Proxy Project
• Wikipedia OWASP ZAP
• Zaproxy - Github
• Scanning website vulnerabilities using OWASP ZAP
• Quick and easy website scan 
• OWASP ZAP tutorial - OWASP academy
• How to hack like pro