GitLab DAST: Template Setup, Authentication, and Step-by-Step Scanning Guide

GitLab DAST helps maintain the security of your web application, enabling you to identify and fix potential vulnerabilities before malicious hackers can exploit them.

In this blog, you will learn about GitLab DAST, its template, authentication, how its scanning works, proxy and browser-based analyzers, and GitLab DAST alternatives around the web.

Let’s get started.

What is GitLab DAST?

GitLab DAST is a tool for finding potential security issues in web applications. It simulates attacks on the application, just as a potential attacker would, to uncover weak spots. Using GitLab DAST allows you to discover and fix security vulnerabilities before they become problematic.

It can determine if your website is vulnerable to SQL Injection attacks (where a hacker could manipulate your database), XSS attacks (where a hacker could run malicious scripts in your users' browsers), and many more.

GitLab DAST Template

The GitLab DAST Template provides a predefined setup for your GitLab DAST scanning. It's a configuration file, often in YAML format, that outlines the settings and parameters for your DAST scan. You must provide details such as the website URL to be scanned, authentication requirements, and specific scan options.

This template streamlines setting up DAST scans, making it easier and more efficient to regularly check your web applications for potential security vulnerabilities. Using a template ensures that your scans are consistent and comprehensive, covering all the necessary areas of your application.

GitLab DAST Authentication

It verifies that a web application is safe and secure. It confirms the identity of the user trying to access the web application.

When conducting a DAST scan, it's sometimes necessary to perform an authenticated scan. This means the scanning tool needs to log into the web application as a registered user. This benefit allows the tool to review parts of the application that unauthenticated users cannot access.

You must configure certain variables to set up authenticated scanning in GitLab DAST. These include:

• DAST_AUTH_URL: This is the URL of the login page of your application.

• DAST_USERNAME: This is the account username the scanning tool will use to log into your application.

• DAST_PASSWORD: This is the account password the scanning tool will use to log into your application.

• DAST_USERNAME_FIELD and DAST_PASSWORD_FIELD: These are the names of the username and password fields in the login form of your application.

Setting up authentication ensures a more thorough and accurate DAST scan of your web application.

How to Conduct a GitLab DAST Scanning?

GitLab DAST (Dynamic Application Security Testing) is an essential tool for scanning your web applications for potential vulnerabilities. However, ensure you don't run a DAST scan in a production environment, even when using a passive scan. Here's a step-by-step guide on how to perform a GitLab DAST scan:

1. Setup: GitLab DAST scan operates on the URL of the application that it expects to scan, which it sets in the DAST_WEBSITE environment variable. If you're working with ephemeral environments in CI/CD pipelines, store the URL in a file named environment_url.txt. The DAST scan template job will use this file to set the DAST_WEBSITE variable.

2. Requirements: Ensure you have a GitLab Runner with the docker-in-docker executor. Since DAST scans for larger applications may take an hour or more, set a sufficiently long timeout value for the runner performing the scan.

Additionally, verify if the project's CI/CD timeout is appropriate. Note that shared runners on GitLab.com have a 180-minute timeout, regardless of the project settings.

1. Configure the DAST Scan:

   • Set the DAST_WEBSITE variable to the application's URL you wish to scan.

   • If your application requires authentication, configure the DAST_AUTH_URL, DAST_USERNAME, DAST_PASSWORD, DAST_AUTH_VERIFICATION_URL, DAST_USERNAME_FIELD, and DAST_PASSWORD_FIELD variables.

   • If you wish to skip the target check, set DAST_SKIP_TARGET_CHECK to 'true'.

   • If you need to mask specific headers, set the DAST_MASK_HTTP_HEADERS to a comma-separated list of headers.

   • To exclude specific URLs, set the DAST_EXCLUDE_URLS to a comma-separated list of URLs.

2. Add the DAST Job to your GitLab CI/CD Configuration:

   • For GitLab 11.9 and later, include the DAST template by adding the following to your .GitLab-ci.yml file:

include: 
template: <template_file.yml> 
variables: DAST_WEBSITE: 
<https://example.com>

3. Run the DAST Scan: Trigger the CI/CD pipeline to commence the DAST job.

4. Review the Scan Results: After completing the scan, you can access and review the results in the GitLab UI.

Following these steps, you can effectively identify and address potential vulnerabilities and secure your application.

GitLab DAST Example

Set up your Runner and add a new job to .GitLab-ci.yml with the help of CI/CD Template for DASH:

include:
template: <DAST.Gitlab-ci.yml>
variables:
DAST_WEBSITE: <https://example.com>

This setup creates a new DAST job in your CI/CD pipeline to run tests on the specified URL and detect possible vulnerabilities.

You must define the URL in two ways:

• The DAST_WEBSITE variable.

• The file named environment_url.txt is at the root of your project.

You should also validate the user before performing DAST scans:

include:
template: DAST.Gitlab-ci.yml
variables:
DAST_AUTH_URL: <https://example.com/sign-in>
DAST_USERNAME: john.doe@example.com
DAST_PASSWORD: john-doe-password
DAST_USERNAME_FIELD: session[user] # the name of the username field at the sign-in HTML form
DAST_PASSWORD_FIELD: session[password] # the name of the password field at the sign-in HTML form

Customize the DAST tool's settings by using the variables parameter in the project's pipeline configuration file (.GitLab-ci.yml):

include:
template: DAST.Gitlab-ci.yml
variables:
DAST_TARGET_AVAILABILITY_TIMEOUT: 120

If you're using GitLab before version 11.9, manually define it with this snippet:

*dast:
image: [registry.Gitlab.com/Gitlab-org/security-products/zaproxy](<http://registry.Gitlab.com/Gitlab-org/security-products/zaproxy>)
variables:
website: "[<https://example.com>](<https://example.com/>)"
allow_failure: true
script:
- mkdir /zap/wrk/
- /zap/zap-baseline.py -J gl-dast-report.json -t $website || true
- cp /zap/wrk/gl-dast-report.json .
artifacts:
reports:
dast: gl-dast-report.json

Here, the website variable should contain the URL for running the tests.

To perform an authenticated scan, use this definition:

*dast:
image: [registry.Gitlab.com/Gitlab-org/security-products/zaproxy](<http://registry.Gitlab.com/Gitlab-org/security-products/zaproxy>)
variables:
website: "[<https://example.com>](<https://example.com/>)"
login_url: "<https://example.com/sign-in>"
username: "[john.doe@example.com](<mailto:john.doe@example.com>)"
password: "john-doe-password"
allow_failure: true
script:
- mkdir /zap/wrk/
- /zap/zap-baseline.py -J gl-dast-report.json -t $website
--auth-url $login_url
--auth-username $username
--auth-password $password || true
- cp /zap/wrk/gl-dast-report.json .
artifacts:
reports:
dast: gl-dast-report.json

What is GitLab DAST Proxy-Based Analyzer?

The GitLab DAST proxy-based analyzer tests web applications for security vulnerabilities. It belongs to GitLab’s Dynamic Application Security Testing (DAST) suite and intercepts and analyzes traffic between a web application and a client using a proxy.

The analyzer scans web applications with simple HTML during the development process and utilizes the Software Security Project Zed Attack Proxy (ZAP) to perform scans in two modes:

1. Passive Scan Only (Default): In passive scan, DAST performs ZAP’s Baseline Scan, which does not actively attack the application but helps identify common vulnerabilities without unintentionally impacting the application.

2. Passive and Active (or Full) Scan: In this mode, ZAP performs passive and active scans, attacking the application to generate a more detailed security report. This is useful for conducting a thorough analysis of the application's security.

What is GitLab DAST browser-based analyzer?

The GitLab DAST browser-based analyzer tests modern web applications for security vulnerabilities. It specifically targets applications that heavily rely on JavaScript. It runs in a browser to optimize testing and is available in the Ultimate tier of GitLab.com, Self-managed, and GitLab Dedicated.

The analyzer identifies security weaknesses (CWEs) in web applications. Run DAST scans against a test server only, as it can perform any function that a user can, such as clicking buttons or submitting forms, and may trigger bugs leading to modification or loss of production data.

What is GitLab DAST API analyzer?

GitLab DAST API analyzer tests web APIs for security vulnerabilities. It scans web APIs using technologies such as GraphQL, REST, and SOAP. It performs dynamic application security testing (DAST) of web APIs to help discover bugs and potential security issues that other QA processes might miss. DAST API analyzer can test the following web API types:

• REST API

• SOAP

• GraphQL

• Form bodies

• JSON

• XML

Run DAST API scans against a test server only, as it can perform any function that the API can, including modifying and deleting data. You can run DAST API scans as part of a CI/CD workflow, on-demand, or both.

Include the DAST API analyzer in your CI/CD pipeline to find vulnerabilities in web APIs with minimal JavaScript usage. For apps with heavy JavaScript usage, use the DAST browser-based analyzer.

DAST GitLab CI/CD YAML

The DAST GitLab CI/CD YAML file is a configuration file that defines the DAST (Dynamic Application Security Testing) job in a GitLab CI/CD pipeline. This file specifies settings and variables that determine how to perform the DAST scan, including the URL to scan, authentication details, scan options, and more.

Here is an example of a DAST GitLab CI/CD YAML file:

*dast:
image: [registry.Gitlab.com/Gitlab-org/security-products/dast:latest](<http://registry.Gitlab.com/Gitlab-org/security-products/dast:latest>)
script:
- /analyze
variables:
DAST_WEBSITE: [<https://example.com>](<https://example.com/>)
DAST_AUTH_URL: <https://example.com/login>
DAST_USERNAME: username
DAST_PASSWORD: password
DAST_FULL_SCAN_ENABLED: "true"
only:
- master
allow_failure: true
artifacts:
paths: [gl-dast-report.json]

The DAST GitLab CI/CD YAML file typically contains the following key components:

1. Defining the DAST job: The YAML file includes a job definition for DAST scanning, specifying the stages, variables, and configurations for the scan.

2. Setting Environment Variables: Environment variables configure the scanning tool. These variables include settings like the website URL to scan, authentication details, target availability timeout, and exclusion URLs.

3. Authentication Configuration: The YAML file allows for setting up authenticated scans by providing the authentication URL, username, password, and field selectors for the login form.

4. Scan Options: You can define configuration options such as enabling full scans (passive and active scanning), setting time limits, and excluding specific URLs during the scan in the YAML file.

5. Artifact Handling: The file specifies how to handle and store artifacts generated during the DAST scan, such as the DAST report, for later analysis.

6. Integration with GitLab CI/CD: The DAST GitLab CI/CD YAML file integrates the DAST job into the CI/CD pipeline, enabling automated security testing of web applications during the development process.

GitLab SAST vs DAST

GitLab SAST (Static Application Security Testing)

GitLab SAST analyzes source code to identify vulnerabilities without executing it. It detects flaws like SQL injection and XSS early in the development process. Integrated into the CI/CD pipeline, SAST provides continuous monitoring and immediate feedback to maintain high-security standards.

GitLab DAST (Dynamic Application Security Testing)

GitLab DAST tests running applications to find vulnerabilities that appear during execution. It simulates real-world attacks to uncover issues such as authentication flaws and insecure configurations. Integrated into the deployment pipeline, DAST ensures comprehensive security by detecting runtime vulnerabilities that static analysis might miss.

GitLab DAST Alternatives

GitLab DAST identifies vulnerabilities in web applications through dynamic application security testing. The alternatives to GitLab DAST include:

1. Akto

Akto is a proactive API security platform designed to help security and engineering teams secure their APIs. Akto excels in API inventory management, running business logic tests in CI/CD pipelines, and performing comprehensive API security testing.

While GitLab DAST primarily focuses on web applications, Akto specializes in API security and can be deployed both in the cloud and on-premise, providing flexibility for businesses with different deployment needs.

2. Beagle Security

Beagle Security is a DAST tool that helps in identifying security vulnerabilities in web applications and APIs. It provides automated VAPT (Vulnerability Assessment and Penetration Testing), can detect advanced attack vectors that vulnerability scanners fail to detect, and is backed by an AI engine for better results with the least false positives.

Beagle Security's AI engine enhances detection capabilities and reduces false positives, providing more accurate and actionable security insights than GitLab DAST.

3. OWASP ZAP

OWASP ZAP is an open-source tool for performing dynamic application security testing. It can scan web applications for vulnerabilities and integrate them into a CI/CD pipeline.

Unlike GitLab DAST, OWASP ZAP is open-source, allowing for extensive customization and community-driven improvements. This makes it a cost-effective and highly adaptable option for organizations with specific security needs.

4. Veracode

Veracode is a comprehensive application security platform with SAST, DAST, and SCA (Software Composition Analysis) capabilities. Organizations use it to secure their applications and APIs throughout the software development lifecycle.

Unlike GitLab DAST, Veracode offers an extensive range of security testing capabilities (including SAST and SCA) within a single platform, providing a more holistic approach to application security across the entire development lifecycle.

Final Thoughts

This blog provides a comprehensive overview, from understanding what GitLab DAST is and how its scanning mechanisms work, including proxy and browser-based analyzers, to discussing available market alternatives.

As an Application Security Engineer, to bolster your security strategy, you should choose a reliable DAST tool that integrates seamlessly into your CI/CD pipeline. Among the mentioned alternatives, Akto stands out as a top choice. Akto provides robust API security testing capabilities and comprehensive vulnerability assessments. Its flexibility in deployment—both cloud-based and on-premise—ensures it meets diverse business needs.

Leverage Akto to fortify your web application security. Akto provides actionable insights and proactive security measures, empowering your team to mitigate risks effectively and maintain a secure development lifecycle.