StackHawk
Hamburger Icon

Dynamic Application Security
Testing (DAST) Tools
Overview & Guide

stackhawk

StackHawk|January 16, 2024

Dynamic Application Security Testing (DAST) is a method of testing a running version of your application to identify potential vulnerabilities and risks. This guide provides an overview of DAST, delves into its inner workings, compares DAST with Static Application Security Testing (SAST), and provides insights on how to make informed decisions regarding security tooling.


Overview of Dynamic Application Security Testing

Dynamic Application Security Testing, also known as DAST, is a form of testing a running version of your application to identify potential security vulnerabilities. With DAST, a scanner sends requests to your web application that simulate malicious attackers and evaluates the response received from the application for an indication of a security bug. As they run through the test suite of simulated attacks, any potential vulnerabilities are recorded for review.

DAST tools have long been a favorite of enterprise security teams, software engineering teams, and penetration testers alike. This form of testing finds vulnerabilities that your team has introduced in the software development lifecycle as well as exploitable vulnerabilities from open-source components used within the application. It is often used alongside Static Application Security Testing (SAST) and Software Composition Analysis (SCA) tools. DAST is known for its low false positive rates and clear surfacing of application security risks.

DAST vs. SAST

Dynamic Application Security- Image 1 image

While both SAST and DAST are essential tools in an organization's security toolkit, they focus on different stages of the Software Development Life Cycle (SDLC) and offer distinct benefits. Understanding these differences can help teams choose the right combination of tools to optimize their security testing.

  • SAST (Static Application Security Testing) analyzes an application's source code, binaries, or bytecode before the application is executed. It examines the code structure, logic, and patterns for security vulnerabilities, making it ideal for early detection. By finding issues like insecure coding practices or logic flaws, SAST can identify vulnerabilities like buffer overflows, hardcoded secrets, and syntax errors, all without the need for a running application. However, a challenge with SAST tools is a higher likelihood of false positives, which can lead to time-consuming triage for developers and security staff alike.

  • DAST (Dynamic Application Security Testing), conversely, focuses on testing a running application. It simulates attacks from the perspective of an external attacker, without access to the source code. This makes DAST solutions ideal when trying to detect vulnerabilities that only manifest in runtime environments(also known as "runtime vulnerabilities"), such as SQL injection, cross-site scripting (XSS), and other input-related attacks. Because it interacts with the application in its final environment by simulating user interactions, DAST provides real-world results with fewer false positives, but it may miss vulnerabilities in non-executable code.

Some of the key differences between these two types of tools include, but are not limited to:

  • Timing

    • SAST is used earlier in the SDLC during development with access to the source code, allowing developers to catch issues in the code itself.

    • DAST is typically applied in the later stages when the application is deployed in a staging or production-like environment.

  • Code Access

    • SAST operates by requiring access to the application's source code or binaries.

    • DAST works externally without the need to review the underlying code, testing the application as a black box for various security issues.

  • Vulnerability Detection

    • SAST identifies vulnerabilities related to coding errors and insecure logic paths.

    • DAST finds vulnerabilities based on the application's runtime behavior, focusing on potential weaknesses that arise during execution.

  • False Positives

    • SAST tools are more prone to false positives, requiring additional time for analysis and triage.

    • DAST generally produces fewer false positives because it evaluates the application in a real environment.

In a comprehensive strategy, SAST and DAST should be used together. SAST catches vulnerabilities early in development, while DAST confirms that the application is secure in its deployed state, ensuring a wholistic security approach throughout the development lifecycle. For an even more detailed look at the differences you can check out our comparison (spoiler, you should use both) in DAST-vs-SAST.

How it Works

DAST scanners initiate their process by targeting the host where your application is deployed. This could be a publicly accessible website or web application; however, it is generally recommended to perform DAST scans in a pre-production environment. Since the scanner emulates an attacker, it could potentially modify or delete data in your production environment, leading to undesirable consequences.

Once the scanner targets the host, it launches an HTML spider to catalog all accessible paths and actions. Depending on the chosen tool, it might also employ an Ajax spider for single-page applications, utilize the OpenAPI specification to test your REST APIs, or examine the GraphQL introspection endpoint to map out your GraphQL API query tree. Ideally, your tooling should comprehensively cover your application and associated APIs and automate this process as much as possible.

Then, the scanner executes a suite of tests, transmitting requests to all identified paths/endpoints and analyzing the responses for indications of security vulnerabilities. The results are then compiled in the report or displayed via the interface of your DAST tool, ideally providing the essential information developers require to remediate any discovered issues.

What it Finds

DAST scanners find a wide variety of web application security vulnerabilities without looking directly at an application's source code. This can include SQL Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and many other vulnerabilities. These scanners find the majority of the OWASP Top 10 vulnerabilities. To see examples of vulnerabilities detected by DAST scanners, check out the tests run by open-source ZAP, widely regarded as the most popular application security testing tool.

The OWASP Top 10 vulnerabilities that DAST scanners do not find are typically beyond the reach of generalized automated testing. However, some DAST tools are now incorporating support for custom scripts, enabling testing of complex business logic and the identification of vulnerabilities more specific to your application. Examples include broken authentication and cross-tenancy checks.

DAST Products and Tools

There are many DAST tools in the market, including several open-source or free options. Below is a list of the leading tools in the space that you could use for testing.

StackHawk

Dynamic Application Security- Image 2 image

StackHawk is a modern DAST tool built for automation in CI/CD. For teams that want to catch vulnerabilities before they hit production and integrate security testing into engineering workflows, StackHawk is the leading option. StackHawk is built on top of the open source ZAP project and provides engineering teams with simplified automation, vulnerability triage, and fixes of securing findings.

ZAP

Dynamic Application Security- Image 3 image

ZAP, is an open source DAST scanner, stands as the most widely used application security scanner in the industry. Having set the standard for the past decade, ZAP excels in automation. It offers both a desktop application for scanning and an API that enables automated scanning of web applications.

Burp Suite

Dynamic Application Security- Image 4 image

Burp Suite, a product of PortSwigger, is a penetration testing tool. For penetration testers or in-house application security teams looking to do manual scans, Burp Suite is an excellent tool. There is also an enterprise edition that leverages agent deployments.

Detectify

Dynamic Application Security- Image 5 image

Detectify is a more modern entrant in the DAST space, although it leverages a crowd-sourcing approach to identifying vulnerabilities. The DAST scanner runs against production applications on a schedule.

Netsparker

Dynamic Application Security- Image 6 image

Netsparker is an established DAST tool that supports enterprise security teams. With on-premise deployment and a professional services arm to lead rollout, Netsparker fits enterprises that are not yet investing in DevSecOps.

Rapid7

Dynamic Application Security- Image 7 image

InsightAppSec is the DAST solution provided by Rapid7, another long standing enterprise security platform. InsightAppSec supports on-premise deployment and scheduled scans of production, making it another excellent solution for enterprises that are not yet investing in DevSecOps.

Veracode

Dynamic Application Security- Image 8 image

Veracode is an enterprise application security platform with solutions including SAST, SCA, IAST, and now DAST solutions. For large enterprises that prioritize a single platform for all application security needs, Veracode may be the right choice.

How to Select a DAST Tool

Once you decide to get started with dynamic application security testing, the hardest part of the process may be deciding which tool is right for you. Below are a few items to consider when selecting a tool.

Scan Frequency: Automated, Scheduled, or Manual

Consider how often you would like to kick off scans. The following options are the most common methods of scanning.

CI/CD Automated Scans

The future of application security is automated and integrated with the DevOps pipeline (known as DevSecOps by many). With automated security scans in the CI/CD pipeline, there are many benefits that lead to faster discovery and fixes of security threats, including:

  • Developers are alerted of any new vulnerabilities before they hit production, optionally breaking the build to ensure a review happens before the release

  • Testing can be run against underlying services and APIs instead of the customer-facing application, leading to faster identification of the underlying issue when a bug is found

  • With tests on every pull request, smaller increments of change are tested, allowing developers to quickly fix vulnerabilities while still in the context of the code they were working on

Scheduled Scans

For teams that are not yet ready to adopt application security automation, they may select to run regularly scheduled scans against the application. While running a scanner on external infrastructure and initiating the scan may seem simpler, there are several concerns associated with this method of dynamic application security testing:

  • Scheduled scans are typically performed on the production site. Since DAST scanners actively probe the application, the security tests are often restricted in scope to prevent impacting the production environment. This approach, however, may leave the application exposed to some of the most malicious attacks.

  • When a vulnerability is discovered, inefficient internal processes need to occur to determine the root cause of the identified vulnerabilities.

  • Production applications include protections against bot-type activities, such as rate limiting, making it challenging for a scanner to run tests effectively.

Manual Scans

Manual scans are often easy to get started with but lack scalability across teams. Additionally, findings from these scans are less reproducible for the individuals who are typically deploying fixes. Manual scans that inherit shared configuration from automated testing, however, are highly beneficial in validating fixes.

Authenticated Scans

If your application requires user login, you will need a scanner that supports authenticated testing methods or scans. Using an automated or scheduled scanner may complicate this. You should ensure that the vendor accommodates your form of authenticated scanning, such as cookie-based, external token, and bearer token

Application Target: Production vs. Pre-Production Sites

As highlighted earlier, scanning in a pre-production environment rather than in a production setting offers numerous advantages. These include the ability to detect vulnerabilities before they become live, avoiding the need to bypass rate limiters, firewalls, and Web Application Firewalls (WAFs), and reducing the time required for fixes.

While the ability to run these scans is partially dependent on the company's deployment pipeline, there is value in a scanner that is built to support pre-production scanning and has the ability to run tests in a dedicated application testing environment (such as a staging environment).

User of Tool: Security Analyst or Engineering Teams

When selecting a tool, one of the primary considerations should be the individual who will use the tool. While testing and addressing application security flaws and vulnerabilities often involve a combination of security and development teams, developer-centric security tooling is growing in popularity to support a variety of testing methods.

These tools are increasingly being used with a focus on enabling developers to write more secure code, make triage decisions, and deploy fixes in their existing workflows, with the security team's responsibility shifting to risk-based guidance and oversight.

API Security Testing

The application security testing landscape has shifted over the past decades, with APIs serving as a primary potential attack vector. If you are running application security testing against modern applications, ensure that the tooling you select supports API testing as a first-class part of the tool.

Additionally, if you are using GraphQL as part of your tech stack, you'll want to ensure that GraphQL API testing is supported by your DAST tool. You'll also want to ensure that the tool supports scanning federated GraphQL implementations.

Single Page Application Security Testing

Single Page Applications (SPAs), built-in frameworks like React or Angular, have rapidly grown in popularity in recent years. Without a static DOM, traditional HTML spiders cannot identify the various paths to run a dynamic application security test against. Testing SPAs necessitates using a tool equipped with an AJAX spider, alongside a tool capable of scanning the underlying APIs.

Deployment Model: On-Prem vs. SaaS

In determining the right application security testing tool, consider the deployment model that works best for your organization. Most companies will prefer a SaaS solution, but some companies still require an on-premise solution.

Conclusion: Just Start Testing

Dynamic application security testing is an excellent way to ensure that you are delivering secure software applications and avoiding the risk of a breach. Getting started is relatively simple and there are numerous free and open source tools to support your testing process and enhance your existing security posture. DAST offers developers a major security advantage by helping to identify security vulnerabilities and generating high-quality vulnerability assessment reports. The key message here is to simply begin testing!

Detecting Security Vulnerabilities with StackHawk!

If you're looking for the fastest way to get started with DAST, look no further than StackHawk. Sign up today to receive a free trial of the DAST platform built by developers to help developers find security vulnerabilities more efficiently.


StackHawk  |  January 16, 2024

Read More

Why DAST Should Be Your First Application Security Priority

Why DAST Should BeYour First Application Security Priority

DAST vs SAST

DAST vs SAST

Long Live DAST! Evolution of Dynamic API Security Testing

Legacy DAST is DeadLong Live Modern DAST!