Dynamic source code analysis

Roman Dushkov, Security Vision

We have already discussed products and methods of analysing application source code by searching for vulnerabilities in the content and comparing it with the expert knowledge base, and today we are going to look at Dynamic Application Security Testing (DAST). It is performed in already existing platforms after source code compilation and can be combined with the previous methods. This approach allows to make the analysis live and constant, effectively embedded in the development process itself (DevSecOps) and at the same time not disrupting the speed of new product versions, site updates or database migration.

The basis of dynamic analysis is to perform attacks on the application and search for vulnerabilities, which can be performed without special products. This approach is quite common: many companies announce rewards for found vulnerabilities, thus involving white hat hackers in ensuring their own security. All you need to do is to have your service (for example, a website for online banking) in the public domain or simply give out licences for your software to those who are interested. The process itself can be called black box testing (it is so called because there is no access to the source code and the application is used in ‘as is’ mode). It is up to the users to guess what is inside and how to use it. This process is called bounty hunting and is similar to a treasure hunt without a map or pokemon hunting. By the way, in 2022, Google paid out $12 million in Bug Bounty programmes (the largest payout was $605,000).

Despite the popularity and availability of this method, automated systems that ‘attack’ an application without human involvement have also become in demand in the market.

Fig. 1 - Mechanisms of dynamic code analysis

DAST tools don't care where in your architecture changes have occurred. Another feature of DAST is that it is the only security testing method that does not depend on the programming language. DAST does not look at source code, bytecode, or assembly code; it simply tests the finished product. The basic DAST module is present in open-source and commercial vulnerability analysis solutions, and more advanced mechanisms exist in w3af or sqlmap. The work of such tools is similar to checking gas pipes for leaks, only instead of soapy solution and pipes there are artificial attacks and your application.

If you are lucky enough to find a security issue, you can add specific use cases to your test suite. It's something like building a recycling plant where the entire stream is sorted: metal and plastic are sent for recycling, glass bottles are returned to beverage production, and some of the rubbish is incinerated. In this way, the workload can be shared between the automated system and the testing and quality department.

Moreover, some DAST solutions allow not only to detect vulnerabilities by launching dummy attacks on the application, but also to organise effective protection on the fly. This process is called patching and is somewhat similar to blocking a road during repairs or when a motorcade passes by. A vulnerability is found (in our example it is a certain road) and must be temporarily closed until the vulnerability is fixed. The vulnerability can be closed manually and automatically by starting a new process where a patch is placed in the vulnerable location until an updated version of the application is released. There are vendors who combine several products by combining DAST with a patch (e.g., WAF), but if you want, you can set up and automate this process yourself using tools for integrating ‘disparate’ products.

You can start code verification using free solutions, one of which is OWASP ZAP (Zed Attack Proxy). The product has extensions for various CI/CD tools. Its functionality is not very extensive and deep, but it can be added and improved if you involve your own resources or partners Using commercial tools will allow you to modify and simplify the verification process. It can be divided into several parts:

- Building the application tree, when the scanner clicks on all buttons and opens all possible interfaces, as if the touch screen ‘crawled’ after getting wet in the rain. Only the app does this crawling deliberately to understand all the relationships and opportunities to access the data.

- Cataloguing, which is something like taking an inventory of IT assets in a company. During this process, the system arranges the interfaces by their types to perform a more detailed analysis later on.

- Implementation of an application attack, when DAST, depending on the interface defined earlier, tries to ‘probe’ the system with its attacks. The attacks are usually harmless and pose no real threat (often they don't even make sense, just empty headers), so there should be no damage to the application's performance.

- Analysing what is happening and making decisions, when the scanner highlights all successful attempts to get to the data that should be protected.

Since the analysis takes place on an already deployed system, two approaches have emerged:

1. To avoid damaging the product and its development, it is better to have a separate test bench. Physically it looks like a copy of the application in an isolated environment with which a dynamic scanner works. With this approach you need to think about additional hardware, but it will not be scary to use DAST solutions at first.

2. If the processes are very advanced, development can be conducted in parallel with testing and virtual patching is used, then you can use dynamic testing on a full-fledged application without additional purchases, accounts and support.

If source code is additionally provided with the finished application for dynamic testing, the process can be transformed into Interactive Application Security Testing (IAST). The use of techniques is also effective when publishing source code, when a developer completely uploads his developments to public repositories. It is similar to publishing your own recipes of cocktails and dishes so that the whole world can repeat your success and enjoy your guests at home. This approach will allow a wide global community to participate in the development, to use static scanners, dynamic scanners and their combinations at the same time, but you don't have to do that - scanners can work on-premise, without broadcasting your applications and developments outside the company. In any case, the dynamic scanner should find and highlight vulnerabilities so that the developers of the new version can fix the problem or IT specialists can put a ‘patch’ and simply keep traffic away from the vulnerable side (usually they do this if it doesn't affect the functioning of the application).

It is possible to apply DAST in parallel with the development process, it allows you to check if a vulnerability exists now and see if it can be prevented in the future. The scanner should be chosen based on the technologies, languages and frameworks used in development. Usually, the larger the development team and the company as a whole, the more parameters there are, so testing solutions can take months or even years, but the result is sure to mitigate all risks.