Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Security Regression Testing with Zap API
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
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
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
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
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>
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
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:
Now you should be able to browse the Zap API from either machine at
Alternatively, Zap running within a docker container
If you don't already have docker installed, the steps can be found here.
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
config/env/test.js needs to have
zapHostName set to the IP that docker assigns to the zap container, probably
To find this out, the following command will provide the running containers details:
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
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:
- Fix the XSS vulnerabilities in the
/profileroute, explained in the Tutorial Guide
- Restart Zap
- Reset the datastore
- Restart NodeGoat
- Rerun the security regression test(s)
You should be informed of a successful test with the following output: