• How DAST scans an application
  • Crawling an application
  • Passive scans
  • Active scans
• Getting started
  • Create a DAST CI/CD job
  • Authentication
  • Available CI/CD variables
• Vulnerability detection
• Managing scan time
• Timeouts
• Artifacts
• Troubleshooting

DAST browser-based analyzer

The DAST browser-based analyzer was built by GitLab to scan modern-day web applications for vulnerabilities. Scans run in a browser to optimize testing applications heavily dependent on JavaScript, such as single-page applications. See how DAST scans an application for more information.

To add the analyzer to your CI/CD pipeline, see getting started.

How DAST scans an application

A scan performs the following steps:

1. Authenticate, if configured.
2. Crawl the target application to discover the surface area of the application by performing user actions such as following links, clicking buttons, and filling out forms.
3. Passive scan to search for vulnerabilities in HTTP messages and pages discovered while crawling.
4. Active scan to search for vulnerabilities by injecting payloads into HTTP requests recorded during the crawl phase.

Crawling an application

A “navigation” is an action a user might take on a page, such as clicking buttons, clicking anchor links, opening menu items, or filling out forms. A “navigation path” is a sequence of navigation actions representing how a user might traverse an application. DAST discovers the surface area of an application by crawling pages and content and identifying navigation paths.

Crawling is initialized with a navigation path containing one navigation that loads the target application URL in a specially-instrumented Chromium browser. DAST then crawls navigation paths until all have been crawled.

To crawl a navigation path, DAST opens a browser window and instructs it to perform all the navigation actions in the navigation path. When the browser has finished loading the result of the final action, DAST inspects the page for actions a user might take, creates a new navigation for each found, and adds them to the navigation path to form new navigation paths. For example:

• DAST processes navigation path LoadURL[https://example.com].
• DAST finds two user actions, LeftClick[class=menu] and LeftClick[id=users].
• DAST creates two new navigation paths, LoadURL[https://example.com] -> LeftClick[class=menu] and LoadURL[https://example.com] -> LeftClick[id=users].
• Crawling begins on the two new navigation paths.

It’s common for an HTML element to exist in multiple places in an application, such as a menu visible on every page. Duplicate elements can cause crawlers to crawl the same pages again or become stuck in a loop. DAST uses an element uniqueness calculation based on HTML attributes to discard new navigation actions it has previously crawled.

Passive scans

Passive scans check for vulnerabilities in the pages discovered during the crawl phase of the scan. Passive scans are enabled by default.

The checks search HTTP messages, cookies, storage events, console events, and DOM for vulnerabilities. Examples of passive checks include searching for exposed credit cards, exposed secret tokens, missing content security policies, and redirection to untrusted locations.

See checks for more information about individual checks.

Active scans

Active scans check for vulnerabilities by injecting attack payloads into HTTP requests recorded during the crawl phase of the scan. Active scans are disabled by default due to the nature of their probing attacks.

DAST analyzes each recorded HTTP request for injection locations, such as query values, header values, cookie values, form posts, and JSON string values. Attack payloads are injected into the injection location, forming a new request. DAST sends the request to the target application and uses the HTTP response to determine attack success.

Active scans run two types of active check:

• A match response attack analyzes the response content to determine attack success. For example, if an attack attempts to read the system password file, a finding is created when the response body contains evidence of the password file.
• A timing attack uses the response time to determine attack success. For example, if an attack attempts to force the target application to sleep, a finding is created when the application takes longer to respond than the sleep time. Timing attacks are repeated multiple times with different attack payloads to minimize false positives.

A simplified timing attack works as follows:

1. The crawl phase records the HTTP request https://example.com?search=people.
2. DAST analyzes the URL and finds a URL parameter injection location https://example.com?search=[INJECT].
3. The active check defines a payload, sleep 10, that attempts to get a Linux host to sleep.
4. DAST send a new HTTP request to the target application with the injected payload https://example.com?search=sleep%2010.
5. The target application is vulnerable if it executes the query parameter value as a system command without validation, for example, system(params[:search])
6. DAST creates a finding if the response time takes longer than 10 seconds.

Getting started

To run a DAST scan:

• Read the prerequisite conditions for running a DAST scan.
• Create a DAST job in your CI/CD pipeline.
• Authenticate as a user if your application requires it.

Create a DAST CI/CD job

• This template was updated to DAST_VERSION: 2 in GitLab 14.0.
• This template was updated to DAST_VERSION: 3 in GitLab 15.0.

To add DAST scanning to your application, use the DAST job defined in the GitLab DAST CI/CD template file. Updates to the template are provided with GitLab upgrades, allowing you to benefit from any improvements and additions.

To create the CI/CD job:

1. Include the appropriate CI/CD template:

   • DAST.gitlab-ci.yml: Stable version of the DAST CI/CD template.
   • DAST.latest.gitlab-ci.yml: Latest version of the DAST template. (Introduced in GitLab 13.8).
   The latest version of the template may include breaking changes. Use the stable template unless you need a feature provided only in the latest template.

   For more information about template versioning, see the CI/CD documentation.

2. Add a dast stage to your GitLab CI/CD stages configuration.

3. Define the URL to be scanned by DAST by using one of these methods:

   • Set the DAST_WEBSITE CI/CD variable. If set, this value takes precedence.

   • Adding the URL in an environment_url.txt file at your project’s root is great for testing in dynamic environments. To run DAST against an application dynamically created during a GitLab CI/CD pipeline, write the application URL to an environment_url.txt file. DAST automatically reads the URL to find the scan target.

     You can see an example of this in our Auto DevOps CI YAML.

4. Set the DAST_BROWSER_SCAN CI/CD variable to "true".

For example:

stages:
  - build
  - test
  - deploy
  - dast

include:
  - template: DAST.gitlab-ci.yml

dast:
  variables:
    DAST_WEBSITE: "https://example.com"
    DAST_BROWSER_SCAN: "true"

Authentication

The browser-based analyzer can authenticate a user prior to a scan. See Authentication for configuration instructions.

Available CI/CD variables

These CI/CD variables are specific to the browser-based DAST analyzer. They can be used to customize the behavior of DAST to your requirements. For authentication CI/CD variables, see Authentication.

Vulnerability detection

Vulnerability detection is gradually being migrated from the default Zed Attack Proxy (ZAP) solution to the browser-based analyzer. For details of the vulnerability detection already migrated, see browser-based vulnerability checks.

The crawler runs the target website in a browser with DAST/ZAP configured as the proxy server. This ensures that all requests and responses made by the browser are passively scanned by DAST/ZAP. When running a full scan, active vulnerability checks executed by DAST/ZAP do not use a browser. This difference in how vulnerabilities are checked can cause issues that require certain features of the target website to be disabled to ensure the scan works as intended.

For example, for a target website that contains forms with Anti-CSRF tokens, a passive scan works as intended because the browser displays pages and forms as if a user is viewing the page. However, active vulnerability checks that run in a full scan cannot submit forms containing Anti-CSRF tokens. In such cases, we recommend you disable Anti-CSRF tokens when running a full scan.

Managing scan time

It is expected that running the browser-based crawler results in better coverage for many web applications, when compared to the standard GitLab DAST solution. This can come at a cost of increased scan time.

You can manage the trade-off between coverage and scan time with the following measures:

• Limit the number of actions executed by the browser with the variable DAST_BROWSER_MAX_ACTIONS. The default is 10,000.
• Limit the page depth that the browser-based crawler checks coverage on with the variable DAST_BROWSER_MAX_DEPTH. The crawler uses a breadth-first search strategy, so pages with smaller depth are crawled first. The default is 10.
• Vertically scale the runner and use a higher number of browsers with variable DAST_BROWSER_NUMBER_OF_BROWSERS. The default is 3.

Timeouts

Due to poor network conditions or heavy application load, the default timeouts may not be applicable to your application.

Browser-based scans offer the ability to adjust various timeouts to ensure it continues smoothly as it transitions from one page to the next. These values are configured using a Duration string, which allow you to configure durations with a prefix: m for minutes, s for seconds, and ms for milliseconds.

Navigations, or the act of loading a new page, usually require the most amount of time because they are loading multiple new resources such as JavaScript or CSS files. Depending on the size of these resources, or the speed at which they are returned, the default DAST_BROWSER_NAVIGATION_TIMEOUT may not be sufficient.

Stability timeouts, such as those configurable with DAST_BROWSER_NAVIGATION_STABILITY_TIMEOUT, DAST_BROWSER_STABILITY_TIMEOUT, and DAST_BROWSER_ACTION_STABILITY_TIMEOUT can also be configured. Stability timeouts determine when browser-based scans consider a page fully loaded. Browser-based scans consider a page loaded when:

1. The DOMContentLoaded event has fired.
2. There are no open or outstanding requests that are deemed important, such as JavaScript and CSS. Media files are usually deemed unimportant.

3. Depending on whether the browser executed a navigation, was forcibly transitioned, or action:

   • There are no new Document Object Model (DOM) modification events after the DAST_BROWSER_NAVIGATION_STABILITY_TIMEOUT, DAST_BROWSER_STABILITY_TIMEOUT, or DAST_BROWSER_ACTION_STABILITY_TIMEOUT durations.

After these events have occurred, browser-based scans consider the page loaded and ready, and attempt the next action.

If your application experiences latency or returns many navigation failures, consider adjusting the timeout values such as in this example:

include:
  - template: DAST.gitlab-ci.yml

dast:
  variables:
    DAST_WEBSITE: "https://my.site.com"
    DAST_BROWSER_NAVIGATION_TIMEOUT: "25s"
    DAST_BROWSER_ACTION_TIMEOUT: "10s"
    DAST_BROWSER_STABILITY_TIMEOUT: "15s"
    DAST_BROWSER_NAVIGATION_STABILITY_TIMEOUT: "15s"
    DAST_BROWSER_ACTION_STABILITY_TIMEOUT: "3s"

Artifacts

Using the latest version of the DAST template these artifacts are exposed for download by default.

The list of artifacts includes the following files:

• gl-dast-debug-auth-report.html
• gl-dast-debug-crawl-report.html
• gl-dast-crawl-graph.svg

Troubleshooting

See troubleshooting for more information.