OWASP ZAP

OWASP ZAP Investigation

ZAP (Zed Attack Proxy) from OWASP is an open source analytics tool which allows users to perform security testing against web applications.

The purpose of this document is to record the steps taken to try out a ZAP scan against a hosted CHEFS instance and future steps that could be investigated.

The ZAP tool is a desktop application that can be run locally on a security tester's computer and targetted against a testing environment. It can run using passive scanning and automated attacks, or do security analysis while a user manually explores a site through a browser (connected with ZAP). ZAP allow has scripted methods of running that can be integrated to automated pipeline processes.

Important: You should only use ZAP to attack an application you have permission to test with an active attack. Because this is a simulation that acts like a real attack, actual damage can be done to a site’s functionality, data, etc.

Resources

ZAP Getting Started - https://www.zaproxy.org/getting-started/

ZAP Desktop UI docs - https://www.zaproxy.org/docs/desktop/ui/

ZAP Videos - https://www.zaproxy.org/videos/

Useful intro video on automated sanning - https://www.youtube.com/watch?v=wLfRz7rRsH4

Useful video explaining the differences between sanning types - https://play.vidyard.com/rLq2nvgbuGwVn2BX9gA8r2

Some ZAP discussion on BC Gov rocket chat - https://chat.developer.gov.bc.ca/channel/devops-how-to?msg=urjjxAbYigtFQiyMW

DevHub notes (warning, out of date) - https://developer.gov.bc.ca/OWASP-ZAP-Security-Vulnerability-Scanning

Setting Up ZAP and environment

All steps in this documentation were done on Windows 11 with ZAP 2.11.

Download ZAP from the OWASP site (note: a Java runtime is required if you don't have already, can get it here) and install it

Read through the quick start guide

On starting ZAP you can persist the session for future use, for all these tests No, I do not want to persist this session was selected.

You will need a URL to the instance of the application you want to test against, for these CHEFS tests a Pull Request env was used (though Dev would be fine), but if playing around with ZAP a localhost could be used, though for real security testing we'll want network calls to be going through the OpenShift infrastructure.

Automated Scan

The quick start automated scan is the most relevant surface level testing to do against an application. It will crawl the application with it's spider and passively scan, then actively attack any discovered pages, functionality, and parameters.

A list of alerts with severity ratings will be created after this scan.

• Start ZAP and click the Quick Start tab of the Workspace Window.
• Click the large Automated Scan button.
• In the URL to attack text box, enter the full URL of the instance you are testing against. For the CHEFS example this would be the front page of the application at https://chefs-dev.apps.silver.devops.gov.bc.ca/app
• Select both spider options and pick the browser you want to the test to use.
• Click Attack to start.

After the attack, analyze the Alert types. For CHEFS you'll notice some alerts could be generated from external sites, as the spider will find the links to GitHub, Fider, etc. You can use the "scope" functionality to filter out irrelevant urls, but you will have to use your knowledge of the application being tested to determine if some links are relevant or not.

See the documentation and links about Scope and Contexts

For the next steps about analyzing the results you will need your expert knowledge of the application you are testing to determine if Alerts are red herrings, non-risks, or need attention. For the initial CHEFS analysis we created a confluence page with alert results and after analyzing to determine which alerts need action, JIRA tickets were created for remediation or more research.

You can save the results of a scan with Report >> Generate Report... in the toolbar. You can select specific contexts and sites in that to narrow it down the same way you can filter alerts.

Manual Scan

A quick useful explainer of the different scan types can be seen in this video: https://play.vidyard.com/rLq2nvgbuGwVn2BX9gA8r2

For a site like CHEFS, most of the functionality is behind a login, so the automated scan will not hit most of the pages or functionality in the site. Since those pages are protected by the login, the automated scan is the most important target to start with to determine if an unauthenticated attacker has any avenues. But the next step should be to run security analyisis on the post-login part of the application.

ZAP allows you to do a Manual Explore scan where you can run through appliation functionality in a browser after logging in while ZAP attempts attacks and scans behind the scenes on the pages you are accessing.

• From Quick Start launch the Manual Explore item
• Enter the URL as in the automated scan above and select the CHEFS site
• You can disable the HUD for this testing. See details about the HUD and it's many power tools here. For targetted, specific, advanced penetration testing the HUD can be leveraged later.
• Select your browser and launch.

ZAP will generate the same type of alerts while you run through the application. For a CHEFS test a full application regression test (creating forms, submitting, managing users, exporting, etc etc) should be done.

Next Steps

Automated and manual scans have been done and alerts recorded for CHEFS. For the future there are more ways of leveraging ZAP, especially in CI/CD.

GitHub Actions

There is a ZAP GitHub Marketplace action that seems fairly easy to slot into any workflows needed. We could potentially look at it in either

• Pull request workflows to check the deployed PR environment
• Manually triggered (or merge triggered) workflows to regression test the dev environment

The ZAP Marketplace action can be found at https://github.com/marketplace/actions/owasp-zap-full-scan

As well, the BC Gov Devops org has a template that expands on this marketplace action

https://github.com/bcgov/pipeline-templates/blob/main/docs/github.md#owasp-scan

https://github.com/bcgov/pipeline-templates/blob/main/.github/workflows/owasp-scan.yaml

We could look into recording results of these scans, there has been discussion of people integrating with SonarCloud or other tools like that but we haven't looked into this idea yet.

The Service BC team has integrated ZAP scans into their master-deploy and pull-request-deploy flows. https://github.com/bcgov/queue-management/tree/master/.github/workflows

The MOH team has is working on ZAP GH Action integration as well. https://github.com/bcgov/moh-hnweb/blob/main/.github/workflows/frontend-zapscan.yml