Security Regression Testing with Zap API

Kim Carter edited this page Jun 9, 2016 · 10 revisions
Clone this wiki locally

Zapping NodeGoat

Short video on how this works https://youtu.be/DrwXUOJWMoo

The Zap REST API should work with any of the setup options. In saying that, it would be a lot more work to be able to run the NodeGoat tests and see the output if you choose not to run the tests locally. These details are specific to Option 2 - Run NodeGoat on your machine. Following are the details used to get OWASP Zap API regression testing NodeGoat. Specifically only the applications profile page at this stage.

There are details on getting Zap running in a docker container on the Zap wiki. We also detail the steps taken to do this below.

Zap Installed on Another Machine.

In this case Zap is on a VirtualBox guest, although in practise it shouldn't matter where Zap is running from. For example we have an alternate option which allows us to use the Zap Api running in a docker container, which we also discuss as we run through the steps below.

NodeGoat running on your local machine

In VirtualBox you will need a Host-only Network added. By default this will be called vboxnet0 in your VirtualBox settings. An ifconfig on the host will reveal a new network interface called vboxnet0. If you were using docker and wanted to use the OWASP Zap docker container, you may see something like docker0 with an IP address similar to 172.17.0.1 once you have docker installed and running. If going the virtualbox route, this allows guests and host to communicate with each other without anyone outside of the host-only network interface being able to see the communications. In this example we set the Adapter IP address to 192.168.56.1. That address will be assigned to your host as an additional network interface.

With this step taken, you will also need to make sure the hostName property in the config/env/all.js is set to the same IP address, as this IP address is used in the regression test(s) to inform the selenium web driver where our NodeGoat is listening from. In addition to that, requests are proxied through the Zap API back to this same address. If using the Zap docker image, then you would want to set the same hostName to the IP address that docker assigns your physical host (as mentioned, probably something like 172.17.0.1)(additional details below).

If you have a firewall running, You will need to allow TCP in on interface vboxnet0. From: 192.168.56.0/24 to: 192.168.56.1 on port 4000 (NodeGoat) and 35729 (LiveReload). Alternatively if you're intending on using the Zap docker image, swap the just mentioned values for docker0, from 172.17.0.2 to: 172.17.0.1. Same ports.

Zap running on a local VirtualBox guest

On the guest machine in the VirtualBox Network settings, set one of the Adapter tabs so that the network adapter is attached to Host-only Adapter. Once the networking is restarted on this guest, it will have a network interface bound to something like 192.168.56.20 (specified by the 192.168.56.0/24 range decided above when you setup the vboxnet0 interface).

The Zap local proxy will need to be bound to the same IP address and port that the guest Host-only adapter is bound to in order to have requests it receives sent via the Host-only adapter to the host that NodeGoat is listening on. 192.168.56.1 in this example. By default the Zap local proxy will be set to 127.0.0.1. Change it to the VMs externally visible network interface. So you can set the Zap local proxy and port to 192.168.56.20 and 8080 for this example via the Zap GUI:
Tools -> Options -> Local proxy.
The other way to do it is via the ~/ZAP/config.xml file in the following section:

<proxy>
   <ip>192.168.56.20</ip>
   <port>8080</port>        
</proxy>

Update the zapHostName and zapPort properties in file config/env/test.js to reflect the host name (or IP address) and port that the Zap API is listening on within your virtual guest. If you want to debug the security regression tests, add the same properties to the config/env/development.js file.

You will also need to make sure the zapApiKey in the config/env/test.js file matches that in the Zap UI Options menu -> API -> API Key, or in the ∼/ZAP/config.xml file in the <api><key></key></api> section. Again, if you want to debug the security regression tests, make sure the key value matches in the config/env/development.js file also.

Start Zap the usual way. Zap can and probably should be scripted to start automatically on each test or suite run, also reset the database so you have a known state if you are planning on using the API in your development team. Zap can be terminated via its API and is usually good practice to do so on each test or suite run, Alternatively you can just create a new session via the Zap Api. If you don’t have a UI:

owasp-zap -daemon

Now you should be able to browse the Zap API from either machine at http://192.168.56.20:8080/.

Alternatively, Zap running within a docker container

If you don't already have docker installed, the steps can be found here.

Run once:

docker pull owasp/zap2docker-stable

Run each time a container is required:

docker run -u zap -p 8080:8080 -i owasp/zap2docker-stable zap-x.sh -daemon -port 8080 -host 0.0.0.0 -config api.disablekey=true -addoninstall selenium

As mentioned above, config/env/all.js needs hostName set to what docker assigns to our local host. ifconfig will reveal this, probably something similar to 172.17.0.1. This is the IP that needs to be put into config/env/all.js and assigned to hostName.

Both config/env/development.js and config/env/test.js needs to have zapHostName set to the IP that docker assigns to the zap container, probably 172.17.0.2

To find this out, the following command will provide the running containers details:

docker ps

Use the container Id of the output in the following command:

docker inspect <container Id> | grep IPAddress

which yields the IP address to assign to zapHostName.

Other useful commands:

Stop all containers:

docker stop $(docker ps -a -q)

Remove all containers:

docker rm $(docker ps -a -q)

Remove all images

docker rmi $(docker images -a -q)
Start the Security Regression test(s) from your local machine

For each test run, this is the usual set of steps:

# In one terminal create clean state in datastore:
grunt db-reset
# Then start NodeGoat:
npm start
# In another terminal start the security regression test(s):
grunt testsecurity

By default the XSS vulnerabilities exist in the /profile route. By running grunt testsecurity, the test/security/profile-test.js will be run and you should be informed of a failed test with output similar to the following:

Zapping NodeGoat

Once you:

  1. Fix the XSS vulnerabilities in the /profile route, explained in the Tutorial Guide
  2. Restart Zap
  3. Reset the datastore
  4. Restart NodeGoat
  5. Rerun the security regression test(s)

You should be informed of a successful test with the following output:

Zapping NodeGoat