DAST vs SAST: A Case for Dynamic Application Security Testing

For anyone new to the alphabet soup of application security industry lingo, fear not, it's easy to wrap one's head around. DAST (Dynamic Application Security Testing) is a black-box security testing methodology in which an application is tested from the outside in by examining an application in its running state and trying to attack it just like an attacker would. On the other end of the spectrum, SAST (Static Application Security Testing) is a white-box testing methodology which tests the application from the inside out by examining its source code for conditions that indicate a security vulnerability might be present.

It's probably no surprise that since my company, Acunetix, is a dynamic scanner, we deeply believe in DAST and black-box methodologies - that's not to say that white-box methodologies are to be disregarded (more on that in the Application coverage section of this article). Naturally, proponents of both methodologies exist, and as is the case with anything in information security, neither is a silver bullet, and both have their own strengths - this article aims to highlight DAST's strengths and how we at Acunetix are addressing its weaknesses.

Technology Coverage

One of the most important attributes of any security testing is coverage. In order to assess the security of an application, an automated scanner should be able to accurately interpret an application.

SAST scanners need to not only support the language (PHP, C#/ASP.NET, Java, Python, etc.), but it must also have support for the specific web application framework being used. This means that if your SAST scanner does not have support for a language or framework you are using, you may hit a brick wall when testing your applications.

Things are different with DAST, because DAST scanners are, for the most part, technology independent. This is because DAST scanners interact with an application from the outside-in and rely on HTTP as a "lingua-franca" across a myriad of programming languages, off-the shelf, and even custom-built frameworks.

Application Coverage

Environment Misconfigurations

It may not seem obvious at first, but application code is just one building block of a complex array of interconnected web servers, proxies, databases, caches, and so on. Assuming web security testing should at your code is a naive approach to web security. Misconfigurations expose a swath of attack surface area for attackers, which should unquestionably be part of any automated security testing.

The DAST approach wins here too. Since we're testing applications on the inside out, the scanner is in the perfect position to test the web application for hundreds of potential configuration issues.

Thinking Inside the Box

Of course, good DAST scanners are very good at finding vulnerabilities within application code from the outside-in. DAST scanners first crawl a web application before scanning it. This step finds all exposed inputs on pages within the web application, which are then subsequently tested for a range of vulnerabilities. SAST scanners have an advantage when it comes to code coverage since the scanner has access to the application code, meaning that it knows about all the application's inputs, including hidden inputs that are not exposed.

This is where an evolution of DAST, gray-box testing, comes into play. Yes, you guessed it, there's an acronym for it too - IAST (Interactive Application Security Testing). IAST is a type of automated security testing methodology that combines the benefits from black-box and white-box methodologies. Implementations vary but being one of the first to pioneer this idea, Acunetix AcuSensor (included as standard in all Acunetix offerings) works by installing a sensor on the back-end of the application which is activated during a DAST scan.

The sensor then relays-back information to the scanner in real-time about the code as it is in execution. This also includes hidden inputs, hidden files, and configuration information the scanner could not obtain using a black-box-only methodology.

"Out-of-band" != "Out-of-sight"

It's a commonly touted myth that DAST scanners can only test for in-band vulnerabilities (vulnerability tests that return some response back to the scanner). While this may be the case for the vast majority of DAST scanners, scanners like Acunetix have been testing for out-of band vulnerabilities for some time now.

In 2013, Acunetix introduced AcuMonitor, which was the first commercial offering to support out-of-band vulnerability testing. Fast forward a few years, and now we've got yet another four-letter acronym to describe this category of vulnerability testing - OAST (Out-of-band Application Security Testing).

OAST technology can be used to detect a variety of Out-of-band vulnerabilities from Blind Cross-site Scripting (BXSS) to Out-of-band SQL Injection, (OOB-SQLi), Out-of-band Remote Code Execution, and most interesting within this category - Server-side request Forgery (SSRF) which includes XML External Entity (XXE) vulnerabilities.

False Positives and Result Verification

False positives are the nature of the automated security testing beast. For the uninitiated, a false positive occurs when a test result wrongly indicates that a vulnerability is present (when in reality it is not).

Apart from being incredibly annoying, false positives drastically degrade the usefulness and investment expended in a tool. If you spend more time weeding through false positives than fixing vulnerabilities, things become counter productive very quickly. Unfortunately, this is arguably SAST's Achilles heel.

DAST, in comparison to SAST, is less prone to reporting false positives - if the application can execute an arbitrary SQL query at the scanner's will, there's no guessing - we know it's vulnerable to SQLi. Combine that with the IAST technology described above, and the false positive rate is practically non-existent. Unfortunately, when a tool produces a lot of false positives, it loses its usefulness. This leads to the common knee-jerk reaction of disabling a plethora of security tests just to avoid false positives - there's a term for that, it's called "false sense of security."

The issue doesn't stop there though, unfortunately, SAST tools may make it harder to reproduce and demonstrate security issues. Because of their testing methodology, DAST tools can provide you with an HTTP request that can be re-played in a manual tool of your choice which easily lets you demonstrate and assess the business impact of a vulnerability.

The SDLC Integration Myth

Another common myth is that DAST tools don't play nice with SDLC tools such as Issue Trackers and Continuous Integration pipelines. This is flat-out wrong.

The truth is that DAST tools can easily and elegantly integrate with popular Issue Trackers such as Atlassian JIRA, GitHub, and Microsoft TFS.

Furthermore, like any other type of automated testing, DAST tools can be integrated with CI platforms such as Jenkins. With Acunetix, you can even install a Jenkins plugin that does the heavy lifting for you - builds can pass or fail based on parameters you set, you can generate reports right from Jenkins itself. Of course, you can always 'roll your own' integration via the Acunetix API if Jenkins is not your thing.

Hopefully, this article provided some insight into how DAST tools work and dispelled some myths. We've seen some advantages of DAST tools and also discussed how Acunetix is overcoming traditional DAST blind-spots through AcuSensor (IAST) and AcuMonitor (OAST).