Penetration testing web applications is not an easy task, no matter if you are a Java, PHP, Ruby or C# developer. Often development teams use web frameworks to develop their application and rely on build-in security features without understanding possible attack scenarios. Other times developers rely on the operation team when it comes to securing the web application.
Recently I came across a tool that solves this problem, the Zed Attack Proxy (ZAP). This open-source tool was developed at the Open Web Application Security Project (OWASP). Its main goal is to allow easy penetration testing to find vulnerabilities in web applications. It is ideal for developers and functional testers as well as security experts.
In this blog I want to give you an introduction on ZAP and how to integrate it in your development lifecycle.
Zed Attack Proxy Features
The latest version of ZAP 2.x is a client that runs on Windows, Linux and MacOS and requires Java 7. Here is a list of the main features:
- Intercepting Proxy
- Automated Scanner
- Passive Scanner
- Brute Force Scanner
- Port Scanner
- Web Sockets
- REST API
Once you start ZAP you will see a quick start tab. Simply insert the url of your web application and start the attack.
Legal disclaimer: Only run ZAP against your own environments, i.e. Test, Staging environments. It is illegal to attack websites from competitors or other people.
Once you start the attack ZAP will crawl through your web application and record all url’s from your domain. It will skip url’s that point to other domains. In the second step it will run different attack scenarios against the found url’s and record the results.
I was running ZAP against my own web application that is running on a tomcat server. Here is an example of what the result look like. As you can see ZAP found several warning of possible vulnerabilities. It lists the results in several categories. In my case I did not remove the examples folder that comes with the default Tomcat installation. ZAP found seven possible cross site scripting vulnerabilities that need to be fixed. You can select the warnings you are interested in and ZAP will show you the request and response raw data as well as hints on how to fix the vulnerability.
As you can imagine this quick start is just a basic security check for your application. The spider only finds url’s that were linked from the initial page. In order to be more thorough you need to do a little more.
Configure ZAP as a proxy
ZAP can be configured as a proxy. The following diagram shows the setup I am going to introduce now. I will configure my local web browser to use ZAP as a proxy while I am browsing my web application. This allows ZAP to record the traffic and use that traffic for a replay attack while modifying the request parameters.
First we need to activate ZAP as a proxy. Open ZAP -> Tools -> Options -> Local Proxy. Configure the address and port on which ZAP will listen for requests.
- Address: localhost
- Port: 8090
After that I need to change my local browser to use this proxy. In most browsers you can do this under Settings -> Network -> Proxy Settings.
Now I can use my browser to access my web application. ZAP will automatically record the traffic. In the Sites window you will find all websites and requests that ZAP recorded. When you right click on a single site you can configure ZAP to attack the found url’s.
Integrating ZAP with your continuous delivery lifecycle
As you can see ZAP is a good start for penetration testing your web application. In the next chapter I will explain how to integrate ZAP in your continuous integration / delivery lifecycle using Jenkins. I created a separate Jenkins Job that can be part of your continuous delivery pipeline or can be run on demand. To automate the penetration testing we need to have automated acceptance tests that drive the web application. In this example I have written jBehave tests that test all features of the web application. For more details on jBehave have a look at:
If you are not familiar with jBehave, you can also use Selenium, Robot or Cucumber.
The following diagram explains the setup. I am using jBehave to drive the web browser. ZAP needs to be configured as a proxy for the web browser so it can record the traffic.
After jBehave is done, I am using the ZAP REST API to run the url spider and afterwards start the attack of the web application. Once ZAP is done, you can get the results via the ZAP REST API as XML or JSON. I have written a small Java application to call the REST API. You can also use one of the following Plugins:
Here is an example of what the JSON formatted result looks like.
"alert": "X-Content-Type-Options header missing",
"solution": "This check is specific to Internet Explorer 8 and Google Chrome. Ensure each page sets a Content-Type header and the X-CONTENT-TYPE-OPTIONS if the Content-Type header is unknown",
"description": "The Anti-MIME-Sniffing header X-Content-Type-Options was not set to 'nosniff'",
All you need to do now is fix all security vulnerabilities in your source code and infrastructure configuration and your are ready to go live 🙂
Running penetration tests against your own web application are a lot easier than I thought at the beginning. OWASP provides a great open source tool that helps developers to build better and more secure web applications. There are a lot of videos out there that explain different features of ZAP. The written documentation, especially of the REST API, could be a little bit more detailed.
For companies that can not invest as much money in reward programs like Google (Google Reward Program) or Facebook (Facebook Whitehat) the Zed Attack Proxy is a pretty good tool that helps you uncover critical security vulnerabilities in your web application.
Let me know if you have used other tools for penetration testing or want to share your experience.