Dynamic Application Security Testing (DAST)

Today, we will discuss Dynamic Application Security Testing (DAST). This analysis is performed directly on platforms after the source code has been compiled and can be combined with SAST. This approach enables the analysis to be live, continuous, and effectively integrated into the DevSecOps process without disrupting the pace of new product releases, website updates, or database migrations.

The foundation of dynamic analysis is to conduct attacks on the application and search for vulnerabilities. This process can be carried out without using specialized products. Many companies offer rewards for discovered vulnerabilities, thereby engaging white-hat hackers to help secure their systems. All that is required is to have your service publicly accessible (for example, a website) or to issue licenses for your software to interested parties. This process is known as “black-box testing” (because there is no access to the source code — the application is used “as is”). Users must guess what lies inside and how to exploit it. This process, often called bounty hunting, is similar to searching for treasure without a map. In previous years, as part of its Bug Bounty programs, Google paid out a total of more than $12 million, with the largest single payout amounting to $605K.

Despite the popularity and accessibility of this method, there has also been a rising demand for automated systems that “attack” the application without human intervention.

DAST tools do not care where changes have occurred in your architecture. Another feature of DAST is that it is the only security testing method independent of the programming language. DAST does not inspect the source code, byte code, or assembly code — it tests the finished product. A basic DAST module is available in both open-source and commercial vulnerability analysis solutions, but more advanced mechanisms exist in tools like sqlmap. The operation of such tools is similar to checking gas pipelines for leaks—except that instead of using a soap solution on pipes, simulated attacks are used on the application.

If you are fortunate enough to discover a security problem, you can add special use-case scenarios to your test suite. This is somewhat like building a recycling plant, where the entire waste stream is sorted: metal and plastic are sent for recycling, glass bottles are returned for beverage production, and some waste is incinerated. This allows you to distribute the load between the automated system and the testing/quality assurance department.

Some DAST solutions not only detect vulnerabilities by launching “dummy” attacks on the application but also enable effective on-the-go protection. This process, called patching, is similar to blocking a road during repairs. Once a vulnerability is found, it must be temporarily closed until it is fixed. The vulnerability can be closed either manually or automatically by initiating a new process, in which a patch is applied to the vulnerable area until an updated version of the application is released. Some vendors combine several products by merging DAST with other security measures (for example, a WAF), but if desired, you can set up and automate this process yourself by integrating “heterogeneous” products.

Code testing can be initiated using free solutions, one of which is the OWASP ZAP product. This product has extensions for various CI/CD tools. Although its functionality is not very extensive, it can be enhanced and improved if you invest your resources or partner with others. The use of commercial tools allows you to modify and simplify the testing process. This process can be roughly divided into several parts:

Building the Application Tree: The scanner clicks on all buttons and opens every possible interface — as if the touchscreen “glitched” after getting wet in the rain. In reality, the application intentionally performs this crawling to map out all interconnections and potential access points to the data.Cataloging: This is similar to conducting an IT asset inventory within a company. During this process, the system categorizes interfaces by their types to enable more detailed analysis later on.Launching an Attack on the Application: Depending on the previously identified interface, the DAST tool attempts to “hammer” the system with its attacks. These attacks are usually harmless and pose no real threat, so they should not affect the application’s functionality.Analyzing the Outcomes and Making Decisions: The scanner highlights all successful attempts to access data that should be protected.

Since the analysis is performed on a deployed system, two approaches have emerged:

Separate Testing Environment: To avoid harming the product and its development, it is better to have a separate testing environment. Physically, this appears as a copy of the application in an isolated setting on which the dynamic scanner operates. With this approach, you must plan for additional “hardware,” but using DAST solutions in the initial stages will be less risky.Live Application Testing: If your processes are very mature, development can proceed in parallel with testing, and virtual patching can be applied. Thus, dynamic testing can be conducted on the live application without additional purchases, extra user accounts, or dedicated support.

If, for dynamic testing, you also provide the source code along with the deployed application, the process can be transformed into Interactive Application Security Testing (IAST). This approach is also effective when the source code is published — when a developer fully uploads their work to public repositories. It is similar to publishing your food recipes so that the entire world can replicate them and delight guests at home. This approach allows the wider community to participate in development by employing static and dynamic scanners (or their combinations) simultaneously. However, this is not mandatory — the scanners can also operate on-premise, without broadcasting your applications or intellectual property beyond the company. In any case, the dynamic scanner should locate and highlight vulnerable points so that either developers can fix the issue in the new version or IT specialists can apply a “patch” to block traffic to the vulnerable area, provided it does not affect the application’s functionality.

The use of DAST in parallel with the development process allows for much faster verification of whether a vulnerability exists at the present moment and for assessing if it can be prevented in the future. When choosing a scanner, you must consider the technologies, programming languages, and frameworks used during development. Typically, the larger the development team and the company, the more parameters there are, so testing solutions may be carried out over several months — but the outcome will undoubtedly reduce all associated risks.