DAST Scanning

Excluding DAST Scan Rules

8min

Excluding specific DAST rules so they do not run is a great way to tailor your DAST scans so that only the rules that apply to your specific web application instance and/or technology stack are run. For instance, it might not make sense to run SQL Injection rules if you don't use SQL.

To exclude rules you'll need to understand and reference the rules using the ZAP rule id. The full list of rules including their IDs can be found on the ZAP site. Rules listed as 'active' are run for Full and API scans, those listed as 'passive' are run for Baseline scans.

Alternatively, if following the rule_config.txt approach below, the generated rules file will contain the full set of rule IDs for your scan mode along with a basic description.

Excluding Using a rules_config.txt File

Generating and editing a rules_config.txt file is an easy way to ignore specific rules from being reported.

  • Works across all DAST Scan Modes (baseline, fullscan, and apiscan).
  • The file contains a sort description of each rule, making it easier to track down specific rules.
  • The file can be added to source control, maintaining a full version history of any ignored rules.

The rules that are ignored will still be run but the results will not be reported as Web Vulnerability (DAST) Issues, therefore the overall execution time of the DAST scan will not be reduced.

Generating a Baseline rules_config.txt File

Execute the SOOS DAST script, passing --otherOptions="-g rules_config.txt". This will write the rules file to the mapped local directory c:\temp\rules.

docker run -v c:\temp\rules:/zap/wrk/:rw -it --rm soosio/dast --clientId=<soos_clientid> --apiKey=<soos_apikey> --projectName="<project_name>" --scanMode=fullscan --otherOptions="-g rules_config.txt" <target_url>

The rules file will be generated for the specified --scanMode, meaning the list of rules will differ when generating a rules file for fullscan, baseline, or apiscan.

Once the file has been generated, open it in a text editor and set any rules to IGNORE that you don't want results reported for. Make sure to maintain the tabs separating each column.

10003 WARN (Vulnerable JS Library (Powered by Retire.js) - Passive/release) 10009 IGNORE (In Page Banner Information Leak - Passive/beta) 10010 WARN (Cookie No HttpOnly Flag - Passive/release)

Referencing a Modified rules_config.txt File

Execute the SOOS DAST script, passing --otherOptions="-c rules_config.txt". Ensure that the rules_config.txt file exists in the mapped local directory c:\temp\rules.

docker run -v c:\temp\rules:/zap/wrk/:rw -it --rm soosio/dast --clientId=<soos_clientid> --apiKey=<soos_apikey> --projectName="<project_name>" --scanMode=fullscan --otherOptions="-c rules_config.txt" <target_url>

Any ignored rules which find issues will still show results in the CLI output (since they are still run), but the results will be marked as IGNORED. The results of ignored rules will not create issues in SOOS.

Excluding Rules Using --disableRules CLI Argument

The --disableRules parameter can be used to specify a list of comma separated rule IDs that should not be run. Unlike ignoring rules with the rules file approach above, disabling rules will ensure they are not run at all. Use this option to improve performance of long running DAST scans by completely excluding certain rules from being executed.

The --disableRules CLI argument my not disable certain rules, especially alpha/beta rules.

Example:

docker run -v c:\temp\rules:/zap/wrk/:rw -it --rm soosio/dast --clientId=<soos_clientid> --apiKey=<soos_apikey> --projectName="<project_name>" --scanMode=fullscan --disableRules="10021,10096,40025" <target_url>

Due to the way ZAP disables rules, when using --disableRules the rule will still appear as if it's run, displaying PASS: Name of Rule [RuleId] in the CLI output, however the rule will not actually be run and will not create issues in SOOS.

Improving Long Running DAST Scan Performance

The maximum timeout for SOOS DAST scans is 180 minutes. Any scan that does not complete within that timeframe will return an 'incomplete' status. Depending on the size of the site being scanned, active scans may exceed this time limit due to the complexity of the rules being run. It is recommended to use the --disableRules parameter to omit any rules that are not necessary, for example any rules that do not match the technology being used.

Additional techniques for improving scan performance can be found under Adjusting Scan Times and Fine Tuning DAST Results.

Vulnerabilities identified during unfiltered scans will be moved to the 'Resolved' issues list if subsequent scans use --disableRules to omit the rule associated with any previously discovered vulnerability.