In a galaxy far, far away there is a dark magic button to find all security vulnerabilities in all applications created or ever be created. No specific knowledge is required, just press the button and get results. That, my friends, is the joy of the DAST tool (which stands for dynamic analysis security testing).
Dynamic analysis security testing is the process of running a scan on the target system (such as a network, infrastructure, APIs, GraphQL, or otherwise) to find vulnerabilities, ideally before shipping the application. Dynamic analysis is a great way also to find any configuration issues, missing security headers, unnecessarily open ports, and other security issues that would manifest themselves only when the application is running.
It sounds a bit unrealistic, but that’s how Dynamic Analysis Security Testing (DAST) tools work, or at least from the user's perspective. DAST utilizes a Black Box testing methodology, which is ideal for when it is not required to have any knowledge about the application’s code, structure, or internal architecture. You must find the inputs and define what is a normal output and what is an exception, then test each of them. DAST requires a running instance of the application where it determines completeness of the scan by a path coverage metric. If all possible inputs were tested, then path coverage is 100%.
One of the benefits of dynamic analysis is that it finds evidence-based security testing. Usually, the scanner would present evidence on why this is a security issue. In comparison, static analysis often finds theoretical vulnerabilities, which are not always exploitable vulnerabilities.
The value of dynamic analysis is improved if it was integrated into the software development process, ideally into the Continuous Integration (CI) stage.
Integrating dynamic analysis is a great way to capture low-hanging fruit in staging or production. It is an easy win on a vendor security questionnaire.
To provide good coverage the DAST tool needs to “learn” an application by visiting web pages and extracting URLs for other pages. It can be a fully automated process where the DAST tool scans and tries to find all inputs, or it can be done with the assistance of people and other resources. DAST tools can act as a proxy, listening to traffic and “learning” the application. Manual (a user visits the website) or automated (recorded user’s actions are re-played with web driver) browsing can be used to generate starting points for DAST tools.
Once inputs are defined, an active scan phase begins. Numerous requests are sent to the application to detect deviations from expected results. While DAST is essential for application security testing it cannot provide a complete overview of all vulnerabilities. Unfortunately, not all found bugs are vulnerabilities, DAST tools can generate a lot of false positives. However, confirmed issues can often be easily re-tested.
DAST tools operate in runtime, they work the best to find authentication, session management, and access control issues. Because it is a black box testing with no knowledge of the context, some issues can be related to using 3rd party components. Various misconfigurations can also be found only in runtime.
DAST is also effective as a static code analyzer for finding different injection issues. The most notorious are SQL injections, Cross-site scripting, and OS command injections. Buffer overflow is another critical vulnerability that can be found with DAST fuzzing user input and sending a specific combination of characters to crash an application.
Effectiveness of DAST depends on how well it knows the application and the number of tests that will be performed. It does not work as fast as static code analyzers and it requires a working environment, but it is still a great way to test the whole application from an attacker’s perspective.
Here are the three things you should look out for when choosing the scanner:
Automating dynamic analysis security testing requires the scanner to be running in a headless mode. The scan should be easily scripted from your automation server. There are some great scanners out there but they only run in a desktop mode, meaning someone has to configure the scan and click a button. Those are not the best for integration into the CI/CD pipeline
Not all scanners are created equal. Some are better for API or Web-based applications (non-API powered), while others are ideal for mobile. A fourth option is great for infrastructure-based scanning. It is very rare that a scanner would be able to cover everything as efficiently. So prioritize your needs, and pick your scanner appropriately.
Nothing is more frustrating than a tool that delays the CI/CD run by more than 10-15%. Most scanners take hours to run, not minutes, which would introduce delays to the build process. Some newer scanners have the ability to scan parts of the application, which would speed it up.
Get a list of the best DAST tools for 2022 here.
SAST and DAST are often used in tandem. As a static analysis screening tool, SAST is better at flagging coding errors, while DAST is better at finding runtime errors. Using DAST alongside SAST solutions also helps to mitigate the high risk of false positives that SAST solutions tend to provide.
Interactive application security testing (IAST) takes more into consideration for modern web and mobile apps than SAST or DAST solutions typically will. IAST combines aspects of both DAST and SAST in order to perform its analysis in real-time within the application and anywhere the development provides. IAST can also function in a continuous integrated environment, QA, or in the production environment.
Run-time application security protection (RASP) is the most different from SAST, DAST, and IAST. Less of a testing tool, RASP is more focused on everyday security protection within the application by controlling application execution and protecting the app when it has been breached. In this way, it’s an excellent bonus tool in addition to security testing.
See a deeper comparison of DAST, SAST, IAST and RASP here.