Before we move onto ZAP, you should completely close out of Burp Suite as both of these proxies run on port 8080 by default. Although you can have both running at the same time on different ports, the functionality that such an arrangement provides is outside the scope of this book. You can open ZAP via the menu structure in BackTrack clicking Applications→BackTrack→
Vulnerability Assessment→Web Application Assessment→Web Application Proxies→owasp-zap as shown in Figure 3.9.
ZAP is very similar to Burp Suite in many ways as they both include several of the same tools such as a site map, an intercepting proxy, a spider, and the ability to encode/decode values. ZAP also has a port scanner that could be used during web server recon, a fuzzing tool for rapid input sent to the application, and a directory brute force tool that guesses common and known directory names on the web server.
CONFIGURING ZAP
When you open ZAP the first time, a license dialog box appears that you must first accept. Then a SSL certificate warning dialog box greets you. In order for
ZAP to function properly over HTTPS, it needs to have an onboard SSL certifica- tion. You can simply click the Generate button to have a certificate created for you immediately as shown in Figure 3.10 and Generate again in the Options
dialog box to correctly accept it into ZAP.
Once your dynamic SSL certificate has been generated, it is displayed to you in the Options dialog box as shown in Figure 3.11. Once you’ve reviewed any options you’d like to inspect, you can click the OK button to get down to the business of using ZAP.
FIGURE 3.9
Opening OWASP’s Zed Attack Proxy (ZAP) in BackTrack.
FIGURE 3.10
RUNNING ZAP
As you visit pages, the Sites tab will be populated in the same manner that the Site Map was generated in Burp Suite. Right-clicking any IP address or URL brings up the context menu in which you can select to scan, spi- der, brute force, or port scan the target application and server as shown in
Figure 3.12.
The first task you should complete is to spider the site to find all resources to be scanned. This spidering is priming the pump for the scanner to do its work. After you select Spider site from the context menu, the spider tab will display the dis- covered content and a status bar indicator of the spidering process as shown in
Figure 3.13.
When the spider is done, you can execute the active scan of the web application by using the context menu or by selecting the Active Scan tab. If you use the tab, you just have to click the play button to start the live scanning. The active scan’s output is found as shown in Figure 3.14.
ZAP also has passive scanning functionality so that as you perform manual browsing all the responses from the web application that pass through the proxy
FIGURE 3.11
Generating certificate in ZAP.
FIGURE 3.12
Right-click menu from the “Sites” tab in ZAP.
FIGURE 3.13
Spider progress in ZAP.
FIGURE 3.14
will be inspected for known vulnerabilities. This is such a handy feature to be able to effectively scan for vulnerabilities without having to send a large num- ber of malicious requests back to the web application. This feature is enabled by default in ZAP just as it is in Burp Suite.
REVIEWING ZAP RESULTS
Once the active scanning has completed, you can review the findings in the
Alerts tab where a tree structure will display the discovered vulnerabilities. It’s not surprising that our DVWA application has several existing vulnerabilities (that’s the whole point!) as illustrated by the SQL injection finding here. ZAP provides a brief description of the vulnerability, what page it was discovered on (login.php in this example), and the parameter’s value that triggered the finding as shown in Figure 3.15.
We now have the exact URL to attack and we know the parameter that is vulnerable. Instead of using a benign proof-of-concept request sent to the web application, we can send in malicious input to compromise the web application. We can perform this attack in the actual HTML form field in a browser if we want to type our malicious input there, or we can use a proxy to intercept the request and edit the parameter’s value. We can even use additional tools, such as sqlmap, to exploit the application. We will be doing a little bit of each of these scenarios coming up during the actual web application hacking.
The full report of ZAP Scanner’s findings can be exported as HTML or XML via the Reports menu. As soon as you save the report file as HTML, as shown in
Figure 3.16, it will open in your default browser for you to review further. The full report details the findings for each of the discovered vulnerability in the same format as the Alerts tab view. Below is the report entry for an SQL injection vulnerability on the include.php page. The most important parts are the URL and the parameter value that triggered the vulnerability.
FIGURE 3.15
Alert Detail:
High (Suspicious): SQL Injection Fingerprinting Description: SQL injection may be possible. URL:
http://127.0.0.1/vulnerabilities/fi/?page=include.php'INJECTED_PARAM Parameter: page=include.php'INJECTED_PARAM
. . . Solutions:
Do not trust client side input even if there is client side validation. In general,
If the input string is numeric, type check it.
If the application used JDBC, use PreparedStatement or CallableStatement with parameters passed by '?'
If the application used ASP, use ADO Command Objects with strong type checking and parameterized query.
If stored procedure or bind variables can be used, use it for parameter passing into query. Do not just concatenate string into query in the stored procedure!
Do not create dynamic SQL query by simple string concatentation. Use minimum database user privilege for the application. This does not eliminate SQL injection but minimize its damage. Eg if the application require reading one table only, grant such access to the application. Avoid using 'sa' or 'db-owner'.
. . . FIGURE 3.16
ZAP BRUTE FORCE
The other tool in ZAP to use during scanning is the Brute Force (formerly known as DirBuster) found on the brute force tab. It comes preloaded with lists of com- mon directory names and simply requests these directories to see if they exist. These preloaded lists are listed in order of importance (top is best) as found by research of the most common directories found online. Once a directory is dis- covered, the tool will continue to brute force search for deeper directories until it has exhausted the entire list as shown in Figure 3.17.
This tool takes a long time to run, especially if you use any of the large word lists, so be aware that it won’t be completed nearly as fast as the spider or scan- ner tools. However, you can leave the Brute Force tool run while you use other tools in ZAP or complete other hacking tasks.