DAST, Dynamic Application Security Testing, is a web application security technology that finds security problems in the applications by seeing how the application responds to specially crafted requests that mimic attacks. DAST tools are also known as web scanners and the OWASP foundation refers to them as web application vulnerability scanners.
From a methodology point of view, a DAST attempts to replicate the labor of a manual pentester probing the application. This can be helpful at times, but if security and speed are important for the system, the limitations of the DAST technology make them insufficient. The shortcomings include poor coverage of security risks, lengthy scans, and lack of actionable advice for developers. Due to these limitations, a dynamic code analysis scan will have to be complemented with a variety of other security measures and tools. As the Application Security Testing market evolves, more modern technologies such as IAST are progressively replacing web scanners.
This post will provide an overview of this family of security testing tools including the typical web scanner design, its benefits and limitations, and practical advice for teams considering investing in a web vulnerability scanner.
Table of contents
What is DAST?
DAST tools, which stands for Dynamic Application Security Testing, and also known as web scanners, find security vulnerabilities in web applications. The vulnerability assessment is conducted from the exterior, with no access to the application source code architecture, so DAST is considered a black-box security approach.
A DAST vulnerability scanner has two key components:
- A crawler element to navigate through the application and discover as many URLs as possible.
- A detection component to execute multiple requests against each URL, including attack payloads.
The scan process begins when the operator points the web scanner to a home URL. Then, the crawler component begins navigating through the links. This means that the parts of the system that are not accessible from the home page will be out of reach, so they will have to be entered manually. This is cumbersome and error-prone as it introduces a human element.
Once the list of URLs has been built, the DAST will go through an extensive list of request formats that include payload attacks. Often, this list is generic, but to maximize the results, the list of payloads should be personalized to the technologies of the system being tested. This process will last many hours, and often, several days. Sometimes, a DAST scan brings down the application being tested, which requires manual reactivation.
The feedback of a web scanner includes the type of security vulnerability, the affected URL, and the parameters involved in the request. Since the point of view is external, there are no details regarding the location of the issue within the source code of the application.
Strengths and weaknesses of DAST tools
DAST tools are well known and enjoy a good market share in the vulnerability assessment space. Here is a review of the pros and cons of web scanners:
A DAST can scan an application independently from its underlying technology, such as programming language or internal architecture. There are two caveats regarding this, first, the discovery of the application: the web scanner must be able to navigate through the system, log in, and collect the URLs. And second, ideally, a DAST must be customized to the particular application technologies, which negates this benefit.
As a penetration testing utility
A manual pentest will benefit from a DAST, as it will automate some of the penetration tasks, such as parameter fuzzing and the insertion of lists containing known malicious payloads. Mature tools such as Burp Suite and OWASP ZAP are considered indispensable for manual penetration testing. However, the value of this benefit will depend highly on the skill of the operator.
Poor security risk coverage
The external point of view of a DAST makes it hard to find complex web application risks. According to the OWASP Benchmark, a scientific test to measure the accuracy of AST tools, even the best DASTs will only find about 18% the existing security vulnerabilities of an application.
Some risks are impossible to identify from the exterior, such as insecure deserialization and blind SQL injection.
Unclear vulnerability reporting
When a DAST identifies a security issue, the reported information only includes the type of vulnerability, the URL, and perhaps, the parameter of the request involved. But this is not actionable. It is up to the team to assign the vulnerability to the proper team, and then spend a long time finding the root cause in the source code.
Lack of zero-days support
A web scanner uses known payloads and attack schemes to find vulnerabilities. This means that any new bypass scheme that is not in the attack list will not be tested.
A web scanner relies on the concept of a “scan.” A thorough DAST can take several days to finish on complex applications. This is cumbersome and also means that it does not adapt well to teams that push code frequently. Also, the moment the report is generated, it is outdated because the detection approach is not continuous.
Too late in the game
DASTs run typically late in the application development process lifecycle (SDLC). This means that the team has already invested many weeks in the project, so the cost of going back and fixing the vulnerabilities identified is quite high.
Even worse, sometimes web scanners are used to test applications that are already in the production stage, which means that the application is already exposed to attackers.
Lack of continuous support
The vulnerability assessment approach is based on the concept of a scan. Once the team has corrected the issues identified during a scan, the process must be repeated to validate the corrections and ensure that the vulnerability has been eliminated.
Lack of DevSecOps support
DASTs are not well adapted to support DevSecOps practices. The vulnerability scans take a long time to finish, and the interpretation of the scan results is difficult to automate. This means that a trainer operator must review manually the scan results and evaluate next steps.
Not adapted to modern technologies
Modern web development trends involve technologies such as APIs, client-side MVC architectures, and non-web protocols such as JSON and SOAP. DAST scanners are not well adapted to these new technologies and sometimes they are impossible and impractical to use.
BONUS: Free White Paper
Eliminate the noise of false positives with IAST technology. Learn the answers to the key questions regarding IAST tools.
Get Your Whitepaper
DAST vs SAST & IAST
The main difference of DAST compared to SAST and IAST is that web scanners do not have any context of the application architecture. This is because a DAST is completely external to the system and has no visibility of the internal behavior of the application.
Compared to SAST and IAST, a DAST must attack the application to find vulnerabilities. IAST tools leverage regular legal traffic, and DAST scans do not require to run the applications.
Regarding the vulnerability assessment point-of-view, a DAST performs a black-box analysis, with no access to the internal application details, compared to a white box analysis in the case of SAST, and a hybrid or grey box analysis in the case of IAST.
How to select a vulnerability web scanner
Here is a simple checklist to serve as a starting point when evaluating the purchase of a DAST web scanner:
- How is the risk coverage? What is the OWASP Benchmark score?
- Does it provide enough information to be useful? Anything on top of URL and vulnerability?
- Is the collection of attacks and bypasses well maintained to reflect new risks?
- What is the key licensing aspect? Is it the number of scans, the size of the application, etc.?
- How do you deploy the tools? On-premise, or as a service?
- Does it fit the automation pipeline?
How to incorporate a DAST
The first step would be to identify the applications to test since it will determine some critical aspects. For instance, if the application is in development and not deployed publicly, an on-premise DAST deployment is ideal.
In order to interpret the results, the team will have to identify the right person with the right skills. It is important to find this person early in the adoption process.
Then, it is recommendable to define a triaging workflow to process the vulnerability scan results. The rate of false positives in a DAST is low, but they are still possible. It is also important to assign the resolution of the issues to the right team, which will not be immediate if the application is complex.
Since a web scanner does not implement continuous vulnerability assessment, the scan process will have to be repeated to confirm that the corrections work. So the team must agree on a timeframe for the repetition.
For a more detailed view of how dynamic analysis compares against SAST and IAST, read this post.