There are two primary approaches to web application security testing. Dynamic Application Security Testing (DAST), also called black box testing, imitates an attacker.
The application is tested from the outside with no access to the source code or the web server. Static Application Security Testing (SAST), also called white box testing, imitates a code reviewer. The application source code is analyzed from the inside.
Before we dive deeper into these interesting web application testing and vulnerability scanning technologies, let's take a quick look at what's covered:
Both of these methods have lots of advantages. The DAST approach is very practical and has huge coverage. You can run a black box test on an application written even in the most exotic technology or language. Its coverage is even bigger because detected vulnerabilities can be caused for example by bad configuration and not by mistakes in the source code.
On the other hand, SAST can let you discover some things that are not obvious when seen from the outside. For example, additional URLs or parameters. With white box testing, you also know immediately where the problem is located in the source code so it speeds up fixing.
IAST provides precision web vulnerability scanning
Imagine how effective a security scan can be if you were to join the two methods together! And no, this is not just theory, it actually exists. The merger of these two approaches is called Interactive Application Security Testing (IAST) or gray box testing and is available for example in Acunetix (thanks to its AcuSensor technology).
A gray box testing solution adds hooks around key calls (for example, database calls, system calls, etc.). Those hooks, often called sensors, communicate two ways with the IAST scanner. Hooks do not require access to the source code. The scanner works directly with the interpreter or the application server.
Sensors provide additional information about the calls. In addition, they can provide a full site map from the point of view of the web server. For example, a standalone DAST scanner would not be able to find a URL or a URL parameter that is not linked to or in some way announced by the application. However, with a full site map, the IAST scanner can attempt to test the unannounced URLs/parameters.
Some security flaws may also be caused by bad configuration. This is another activity in which an IAST scanner can excel. Sensors can help to find security errors in interpreter/compiler configuration files and provide the scanner with additional information to attempt attacks based on these configuration properties.
Last but not least, these two methods together can have a significant impact on the reduction of false positives! For example, when you run a time-based blind vulnerability test with a DAST scanner, the scanner may only guess that a time delay is caused by a vulnerability (for example, an SQL server processing a sleep command). When you have a sensor that is monitoring what is going on server-side, you can be one hundred percent sure what causes the time delay.
Using a sensor requires no additional work from developers. The IAST scanner uses clever tricks to intercept calls. When it is working with an interpreter, it listens in on the communication between the interpreter and the web server. It analyzes this communication, finds all the potentially risky calls, and uses even more clever tricks to modify calls on the fly by adding hooks. When it is working with a bytecode compiler, it taps the communication with the application server.
IAST may make developer work even easier. If you use a DAST scanner and find a vulnerability, the developer always needs to go through the source code to identify the location of the security issue. But in some cases, a sensor may be able to pinpoint the root cause of the vulnerability and show you the line of code or give you a stack trace.
Gray box testing looks too good to be true. The only problem is its coverage. Just like SAST scanners, IAST works only with specific programming languages and environments. At the moment, AcuSensor supports PHP, Java, and .NET. However, taking into consideration that according to W3Techs surveys these three technologies together cover 94.4% of the landscape, this should not be much of a concern for most.