What is DAST?

Testers often use black-box testing as a compliment to white-box testing, or in the case where they have no way of accessing the source code. This approach assesses the application from the outside-in and mimics a hacker’s interactions with the system. Dynamic Application Security Testing, or DAST, as these tools are often referred to, are black-box testing tools that work as vulnerability scanners.

What are DAST tools?

DAST tools detect vulnerabilities in a running application by injecting malicious payloads to identify potential flaws that allow for attacks like SQL injections or cross-­site scripting (XSS), for example. DAST can also help detect runtime flaws which SAST cannot find.

OWASP provides a list of the main Vulnerability Scanners. Without endorsing any of the vendors, the page presents the tools and platforms for which they are adapted.

How do DAST tools work?

DAST tools enable the automated review of a web application by testing all the access points as they communicate through the frontend. The tools simulate malicious user behavior and emulate random actions which can be completed by complex test cases defined by an operator or interactions with third-party systems, like email registration validation or entering an SMS validation code.

The calls, including web cryptography API, keychain, network, filesystem, SQL, as well as content providers, broadcast receivers, URI handlers etc. will be intercepted, collected, probed and checked for vulnerabilities to determine if every piece is behaving as it should be or if it is not part of the expected result set.

On top of the exposed HTTP and HTML interfaces, some solutions also test for remote procedure call, Session Initiation Protocol [SIP], etc.

DAST tools are especially helpful for detecting:

  • input/output validation: (e.g. cross-site scripting and SQL injections);
  • server configuration mistakes;
  • authentication issues; other problems which manifest in real time or become visible only when a known user logs in

Security researcher Shay Chen has compiled an extensive list of both commercial and open-source web application security scanners and benchmarked them as part of the WAVSEP (Web Application Vulnerability Scanner Evaluation Project), which evaluates the various aspects of web application scanners: input vectors, scan barriers, performance, accuracy and result consistency. The list provides a great overview of the status of the DAST space.

Advantages of DAST

DAST tools allow for sophisticated scans on the client side and server side without needing the source code or the framework the application is built on. They usually require minimal user interactions once configured and can be run as part of a nightly scan. DAST solutions are also less prone to reporting false positives than SAST: if a malicious SQL query could be executed, it means there is indeed SQL injection vulnerability. The introduction of IAST has even improved the results as it reduces the false positive rate further.

The scanners understand arguments and function calls and will attempt to detect vulnerabilities in query strings, headers, fragments, verbs (GET/POST/PUT) and DOM injection. By scanning the complex environment of the application (interconnected web servers, proxies, databases, caches etc.), DAST tools detect potential configuration issues and third party vulnerabilities which cannot otherwise be found if you focus only on the code itself.

Furthermore, since DAST tools interact with the application from the outside, they are mostly technology- and language-independent. Consequently, they can be used with any programming languages and with both off-the-shelf and custom-built frameworks. They can also be integrated with popular SDLC tools such as issue trackers and continuous integration pipelines (JIRA, GitHub, etc.).

Disadvantages of DAST

Lots of false positives. DAST tools attempt to simulate attacker behavior, but have limited understanding of some of the dynamic aspects of JavaScript and are unable to differentiate between a real exploitable vulnerability and one that can’t lead to any harm. The “stress test” that DAST tools do will return a much larger set of reported issues than an application actually has. This means that security owners will have to filter and prioritize the results of a DAST test to winnow out all of the false positives.

Additionally, DAST tools only interact with applications from the outside. They can’t get the context of what’s happening inside the application, and only have an external view of security. And since these tools can only be used towards the end of the SDLC, vulnerabilities will only be discovered after the development cycle is completed. They require full compilation upon every code change, which prevents them from fitting well in an agile methodology system, and runs them into scaling issues. For large projects, DAST tools may need special infrastructure, special tests, and multiple instances of the application to run different data input. Moreover, they do not help with coding design flaws, which can lead to stability issues.

Some tools can’t cover 100% of the application area which means they might, at best, miss minor or less-visited areas of the application. The tester should be aware of their web application attack surface to:

  • verify that the tool was correctly configured to understand the application
  • actively expand the tool’s coverage

When using a DAST scanner, data may be overwritten or malicious content injected into the tested web application. Tests should be performed in a production-like, but non-production environment, to ensure accurate results while protecting the data.

How can you overcome the limitations of DAST?

DAST covers different areas that SAST does not reach and vice versa. In a comprehensive testing strategy both should be mobilized on top of manual reviews and testing to help catch different security problems before the web application is released or grows its user base.

Additionally, security solutions should be put in place in different parts of an application’s lifecycle. If you use DAST pre-production, you should consider a production environment security tool, as well as other non-scanners.