ZAP Plugin for casa-spiderplan

Add ZAP testing to your Spiderplan Personas.

Refer to the contributor guide for details about making changes to this plugin.

Features:

- Scan each waypoint as a Persona journey is traversed with both active and passive scans
- Compiles findings into a report compatible with GitLab CI's vulnerabilities dashboard

This is _not_ a replacement for full security testing. It will use out-of-the box configurations for ZAP whilst performing scans. You should attack any particular endpoints of concern with a more targeted approach.

DOM-based attacks are also disabled for performance reasons.

Pre-requisites

- ZAProxy must be running somewhere, e.g. in a docker container, as a desktop application, on a remote server. We use a docker container in the examples below.

Getting started

Install the plugin:

``bash
npm i -DE @dwp/casa-spiderplan-zap-plugin
`

Configure your worker bootstrap script to enable this plugin:

`javascript
const zapHooks = require('@dwp/casa-spiderplan-zap-plugin');

module.exports = () => {
// Other setup stuff ..

// Load hooks
const hooks = [
...await zapHooks({
// ZAP API key to use
apiKey: 'secret', // pragma: allowlist secret

// Location of ZAProxy
proxy: 'http://localhost:8080/',

// Target will be called from ZAP, so needs to call host.docker.internal
// on all but Linux machines
rewriteUrl: (p) => p.replace('localhost', 'host.docker.internal'),
}),
];

// Along with the other worker-init attribute, return the "hooks" attribute
// containing the list of hooks that will be used
return {
hooks,
};
};
`

Start a headless instance of ZAP:

`bash


Start the docker container (be sure no other services are using port 8080).

Note that the API key you define here needs to match what you specify in the

worker bootstrap script above

docker run --rm --name zap -d -u zap -p 8080:8080 -i owasp/zap2docker-stable \
zap.sh -daemon -host 0.0.0.0 -port 8080 \
-config api.addrs.addr.name=".*" \
-config api.addrs.addr.regex=true \
-config api.key=secret
`

Give the container a few seconds to fully start up. If you check the container logs, you will see some errors thrown regarding an issue getting latest version information; this is fine to ignore.

Run your Spiderplan tests as normal.

Once all persona tests are complete, a report of all findings can be generated in various formats, for example (assuming ZAP is still running):

`bash


JSON

curl -H 'X-ZAP-Api-Key: secret' http://localhost:8080/OTHER/core/other/jsonreport > report.json

HTML

curl -H 'X-ZAP-Api-Key: secret' http://localhost:8080/OTHER/core/other/jsonreport > report.html
`

Process overview

The following Spiderplan hooks are used:

- post-init-worker

Sets up a new ZAP context (one for each worker)
- pre-process-persona

Sets up some hooks on the httpClient to control whether waypoint requests go through the ZAProxy or not
- pre-get-waypoint

Each waypoint is "claimed" by a worker to ensure it gets scanned only once
- post-submit-form

Performs an active scan against the waypoint (both GET and POST will be tested)

It would be far more efficient to travel through a journey and then perform an attack on all traversed waypoints. However, as soon as ZAP begins posting attack payloads at a waypoint (containing random data), it effectively makes all subsequent waypoints unreachable as the session data is now corrupt and the user cannot progress beyond the last good waypoint. Additionally, the last waypoint in the journey is usually a submission of some kind which wipes all session data, making all captured requests redundant.

Configuring ZAP

The performance of this plugin relies quite heavily on how ZAP is configured. Particular attention needs paying to CI environments, where ZAP is likely running in a resource-limited environment. Limit the threads in both ZAP and the persona tests.

Performance

On an MDM mac (16GB RAM, 2.2GHz 6core CPU), running ZAP in a docker container:

- 302 Personas
- 6 worker threads
- Execution time: 6m30s

Current issues

It's a little flaky sometimes, with ZAP throwing exceptions such as ArrayIndexOutOfBoundsException, NullPointerException. The zap-docker (v2.10.0) option seems to more reliable than the GUI we have access to (2.7.0), although it does suffer from scan timeouts occasionally. There is a hard-coded 2 minute timeout on scans which goes some way to mitigating this (at least in the environments tested so far).

This appears to get worse as subsequent test runs are executed; starting from a fresh instance of ZAP works best.

References

- ZAProxy API documentation
- NodeJS client library
- OSX ZAP log is in ~/Library/Application\ Support/ZAP/zap.log`
- GitLab DAST reports ref
- Schema for GitLab reports
- Sample JSON GitLab reports