GitLab has recently introduced a browser-based Dynamic Application Security Testing (DAST) feature in version 16.4 (or DAST 4.0.9). This development is part of GitLab's ongoing efforts to enhance browser-based DAST by integrating passive checks. The release includes active check-in capabilities.
Customers conducting active scans (full scans) will now automatically use GitLab active checks as the DAST team releases them. Each corresponding ZAP alert will be deactivated at that time. However, customers can opt out and revert to ZAP alerts by setting the CI/CD variable DAST_FF_BROWSER_BASED_ACTIVE_ATTACK to false.
The key change in this update is the replacement of ZAP alerts with GitLab's active checks, specifically using GitLab check 22.1 for detecting path traversal vulnerabilities. This change aims to improve the detection of vulnerabilities in modern web applications for developers and security teams.
An active check in this context refers to a series of attack simulations run against a web application to identify specific weaknesses. These checks are performed during the active scan phase of a DAST scan. The process involves identifying injection locations in HTTP requests recorded during the crawl phase. These locations can include areas like cookie values, request paths, headers, and form inputs. The active check attacks use various payloads, which can be text or binary content, to test these injection points. Each payload is injected into different injection locations, creating new HTTP requests. The responses to these requests are then analyzed to determine if the attack was successful.
As a side, Elephant in AppSec podcast episode, Meta's principal security engineer, Aleksandr Krasnov, highlighted the growing "shift left" trend in the tech industry, emphasizing early security integration in the software development life cycle (SDLC). However, he cautioned against deprioritizing the latter stages of the SDLC. Krasnov pointed out that this imbalance is reflected in the inefficiency of Dynamic Application Security Testing (DAST) tools, which often fail to provide significant value to organizations and security engineers. His insights underscore the need for a balanced approach to application security.
In another blog post, the GitLab team elaborated on the working of the DAST scan. The DAST scan running in a browser-based environment retrieves the application's URL from the DAST_WEBSITE environment variable. This URL should direct to a test environment, as running a DAST scan on a production environment is not advisable, even for passive scans. In cases of transient environments created within the CI/CD pipeline, the URL can be stored in an environment_url.txt file. This file is then used by the DAST scan template job to configure the DAST_WEBSITE variable. This process is demonstrated in the GitLab Auto DevOps deploy template job.
The duration of a DAST scan can vary, potentially exceeding an hour, depending on the web application's complexity. It's important to set a sufficiently long job timeout for the runner executing the DAST scan. Additionally, the CI/CD timeout at the project level should also be adjusted to accommodate the scan's completion.
For more information about GitLab’s browser-based DAST scanning, interested readers can refer to the official documentation. DAST scans are available in the free trial of GitLab Ultimate.
