DAST vs SAST: A Case for Dynamic Application Security Testing

Dynamic Application Security Testing (DAST) is a black-box security testing methodology in which an application is tested from the outside. A tester using DAST examines an application when it is running and tries to hack it just like an attacker would. On the other end of the spectrum is Static Application Security Testing (SAST), which is a white-box testing methodology. A tester using SAST examines the application from the inside, searching its source code for conditions that indicate that a security vulnerability might be present.

Acunetix is a dynamic scanner and we deeply believe in DAST and black-box methodologies. That does not mean that white-box methodologies are to be disregarded. Both methodologies have their strengths and weaknesses and both should be part of every effective security program. This article aims to highlight DAST strengths and how Acunetix is addressing its weaknesses. For more info on SAST, you can consult the OWASP wiki.

Technology Coverage

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

SAST scanners need to not only support the language (PHP, C#/ASP.NET, Java, Python, etc.), but also the web application framework that is used. If your SAST scanner does not support your selected language or framework, you may hit a brick wall when testing your applications.

On the other hand, DAST scanners are, for the most part, technology-independent. This is because DAST scanners interact with an application from the outside and rely on HTTP. It makes them work with any programming languages and frameworks, both off-the-shelf and custom-built ones.

Environment Misconfigurations

The application code is just one building block of a complex array of interconnected web servers, proxies, databases, caches, and so on. Assuming that web security testing should focus only on the code is a naive approach to web security. Misconfigurations expose a large attack surface area.

The DAST approach wins here, too. Since DAST tests are done from the outside, the scanner is in the perfect position to test a web application for hundreds of potential configuration issues.

IAST: Thinking Inside the Box

DAST scanners first crawl a web application before scanning it. This lets the scanner find 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 because the scanner has access to the application code. This means that it knows about all the application inputs, including hidden ones that are not exposed.

To address this issue, a grey-box methodology has been developed. Interactive Application Security Testing (IAST) combines the benefits of black-box and white-box methodologies. Acunetix is one of the first DAST solutions to use this methodology.
.

Acunetix AcuSensor (included as standard in all Acunetix offerings) works by installing a sensor on the back-end of the application that is activated during a DAST scan. The sensor then relays real-time information about the executed code back to the scanner. This also includes hidden inputs, hidden files, and configuration information that the scanner could not obtain using a black-box-only methodology.

OAST: Out-of-band Does not Mean Out-of-sight

It is often believed that DAST scanners can only test for in-band vulnerabilities (perform tests that return an immediate response back to the scanner). This may be the case for the vast majority of DAST scanners but Acunetix has been able to test for out-of-band vulnerabilities for several years.

In 2013, Acunetix introduced AcuMonitor, which was the first commercial offering to support out-of-band vulnerability testing. This category of vulnerability testing is now called Out-of-band Application Security Testing (OAST). OAST technology can be used to detect a variety of out-of-band vulnerabilities such as Blind Cross-site Scripting (BXSS), 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

A false positive is a situation when a test result wrongly indicates that a vulnerability is present when in reality it is not. False positives are a nightmare for every chief information security officer and a common problem of automated security testing, especially in the case of SAST tools. They are not only annoying but they also drastically degrade the usefulness of a tool. You may end up spending more time weeding through false positives than fixing vulnerabilities. It often leads to disabling several security tests just to avoid false positives and creating a false sense of security.

DAST solutions are less prone to reporting false positives than SAST. If the application can execute an arbitrary SQL query at the will of the scanner, there’s no guessing – we know the application is vulnerable to SQLi. The introduction of IAST reduces the false positive rate to nearly zero.

SAST tools also make it harder to reproduce and demonstrate some security issues. DAST tools can provide you with an HTTP request that can be replayed in a manual tool of your choice. This lets you demonstrate and assess the business impact of a vulnerability.

Integrating DAST with SDLC

Many devops believe that DAST tools don’t work well with systems development lifecycle (SDLC) tools such as Issue Trackers and Continuous Integration pipelines. This is not true; DAST tools can be easily and elegantly integrated with popular issue trackers such as Atlassian JIRA, GitHub, and Microsoft TFS.

Furthermore, like any other type of automated testing tools, DAST solutions can be integrated with CI platforms such as Jenkins. With Acunetix, you can even install a Jenkins plugin: builds can pass or fail based on parameters that you set. You can also generate reports right from Jenkins itself. Of course, if you don’t use Jenkins, you can always create your own integration using the Acunetix API.

Take a demo to get a dynamic perspective on your application security.

Frequently asked questions