Dynamic Scanning
In order for an application to get ATO, it needs to meet more than a minimum level of application security, so the application team needs to run both static and dynamic security scans and document good results. Running a “dynamic” scan means running a program that analyzes a live running application for common vulnerabilities.
As part of the process of getting an ATO at TTS, your application team will need to set up OWASP ZAP to do dynamic vulnerability scanning of your application. ZAP can function as either an active (Spider & Attack options) or a passive (man-in-the-middle/proxy) scanner, but is usually used as a combination of both. If you (or another person on your application team) has questions about setting this up, ask #infrastructure for help.
Preface
You will need a running application to test, which you will want to be as production-like as possible—ideally a staging environment. Running a scan can cause a spike in requests and errors, so inform your team and #infrastructure if you are going to run it on a production site.
We gave an introduction to ZAP talk as part of our engineering tech talks series.
Slides and additional information available here.
Using the the Quick Start is a good way to get a basic idea of what ZAP does.
Scanning
- Set up ZAP as a proxy.
- Unfortunately, the “Plug-n-Hack” extension mentioned on the Quick Start page is currently non-functional.
- If the browser gives you a certificate error (e.g.
"This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox may only connect to it securely."
), you will need to install ZAP’s root certificate.- In ZAP, go to
Tools
->Options
->Dynamic SSL Certificate
and click theSave
button to save the certificate to your computer. - You will then need to install the certificate. For Firefox, go to
Preferences
->Advanced
>Certificates
->View Certificates
->Import
to import the certificate you saved from ZAP. - For additional information see ZAP’s documentation on Dynamic SSL Certificates.
- In ZAP, go to
- Seed the scanner.
- Navigate through the various types of pages/interactions on your site, including signing in. You should see domain name(s) start to show up under the
Sites
list. - For each of the domains in the
Sites
list that you control (i.e. nothttps://fonts.googleapis.com
):- Right-click the domain to bring up the context menu.
- Select
Include in Context
->Default Context
. - In the
Session Properties
window that pops up, clickOK
.
- Navigate through the various types of pages/interactions on your site, including signing in. You should see domain name(s) start to show up under the
- Run the spider.
- In the menu bar, click
Tools
->Spider...
. - Click
New Scan
. - Next to
Starting point
, clickSelect...
. - In the
Select Node
window, clickDefault Context
, theSelect
. - Click
Start Scan
. - You should see the
Spider
table fill up with results, but the domains you don’t control should sayOUT_OF_CONTEXT
.
- In the menu bar, click
- If your site uses AJAX, run the AJAX Spider.
- Run the actual scan.
- In the menu bar, click
Tools
->Active Scan...
. - In the
Active Scan
window, follow the sameStarting point
steps as above.
- In the menu bar, click
- View the alerts.
- Click the
Alerts
tab. - Above the
Alerts
list, click the(so that it turns red) to
Show only URLs in scope
.
- Click the
- Investigate the listed alerts.
- Export the results.
- In the menu bar, go to
Report
->Generate HTML Report
.
- In the menu bar, go to
Examining the Results
The Spider
As configured, the Spider does not follow links to other domains or subdomains. If your project uses either (for example, you use S3 for assets, or the api is at a different sub domain), you will want to click and update the options to include the domains & subdomains within the scope. There is a guide available for those options here.
Alerts
The Alerts pane lists all alerts discovered while scanning the site. As described on the alerts page, the red and orange-flagged alerts must be taken care of before the application can be ATO’d. You have a little more flexibility when dealing with the yellow and blue flags, but all of them must be either corrected or, in the case of false positives, documented.
Optional: When you get false positives, you can file issues with the ZAP project to help them improve the alerting rules to prevent false positives.
If you’re running the attack against a local server you may see some alerts that you wouldn’t see on cloud.gov. Debugging web servers are more ‘chatty’ about errors than production servers.
Other Tools Within ZAP
Fuzzing
“Fuzzing” refers to feeding a large amount of random (and/or potentially malicious) data to an application with the intention of finding vulnerabilities related to poor error handling or incomplete input validation. Typically, fuzzing is used on query parameters and form fields.
Any request in ZAP can be fuzzed. Simply right click on it, select Attack -> Fuzzer. Read more about ZAP’s Fuzzing capabilities here.
More Information
The ZAP User Guide is phenomenal. If you run into an issue, this should be the first place you check.
The OWASP Vulnerable Web Applications Directory has a great list of (intentionally) vulnerable targets that are useful for testing the capability of ZAP.
We are currently collecting best practices for using ZAP. If you have a particular approach, extension, or option that you find effective, open an issue!