@dwp/casa-spiderplan-zap-plugin NPM

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:

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

Configure your worker bootstrap script to enable this plugin:

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:

# 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):

# 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.