Full post available here: https://blog.hackedu.com/sast-vs-dast-vs-iast
In the last twenty years, software applications have changed the way we work or do business. Software and in particular web applications store and handle increasingly more sensitive data. According to Verizon’s 2019 Data Breach Investigations Report, 62% of security incidents target software web applications, while 25% of all security breaches were caused by vulnerabilities in web applications.
Modern development has many challenges — and security is one of the most pressing issues. While secure coding practices and code reviews are essential in ensuring security, these two techniques alone may not keep up with the Agile methodologies used today in software development.
In this article, we will analyze several automated solutions that can help developers and testers to identify vulnerabilities in their code at different stages of the Software Development Lifecycle (SDLC).
Static Application Security Testing (SAST)
Static Application Security Testing (SAST) tools use a white-box testing approach to identify vulnerabilities. White-box testing is where the internals of the application (i.e. source code) are known to the tester. SAST tools are designed to analyze the source code of an application and spot potential issues in the early development stages. In contrast to manual code review, SAST tools can finish their job much quicker. For instance, analyzing 100,000 lines of code would take minutes for a SAST tool, while for a human, it would likely take months.
How SAST Tools Work
The first step is to implement a SAST tool into the build system of the application. This way, the tool can get a comprehensive understanding of the codebase, its configurations & dependencies, as well as the data flow.
The next step is the code analysis. SAST tools achieve this through a series of rules that can (and should) be customized by the developer/tester to accommodate the tested application. Most SAST tools come with built-in rules that can spot input validation errors, path traversals, injections, race conditions, and many others. The quality of the findings mainly depends on how well these rules are customized to suit the application.
SAST tools are great for a number of reasons. As we already mentioned, probably the most significant advantage over manual code review is the ability to analyze a large codebase within a matter of minutes. Also, since these tools are meant to be used early in the SDLC, identifying and fixing vulnerabilities at this stage is cheaper.
Another important advantage is that SAST can reveal the exact location of the vulnerability in code. This is possible because SAST solutions get a semantic understanding of the code, its configuration files, and dependencies. Moreover, SAST can even act as a self-training tool for developers to learn from common mistakes, as they reveal not only the exact location of vulnerability.
SAST tools are a powerful asset for software testing, but they have their limitations. Despite their ability to understand code, SAST solutions can’t detect most of the access control issues as they are logical vulnerabilities. This type of weakness can be identified by other means.
Additionally, if the codebase is large, the chances are that SAST will produce a high number of false positives and false negatives. Hence, interpreting and validating the results still requires the expertise of a trained person.
In order to overcome some of these limitations a different testing approach called DAST can be used.
Dynamic Application Security Testing (DAST)
Dynamic Application Security Testing (DAST) tests the application from a black-box perspective. This means that DAST tools don’t have access to the source code. Instead, they examine a running web application from outside, simulating a real attack just like a penetration test. The goal is to observe how the application reacts to different attack vectors and identify potential vulnerabilities that may be missed by SAST.
How DAST Tools Work
DAST tools try to gather as much information as possible about the target. They crawl the pages and extract all inputs to expand the attack surface. Once this step is done, they start the active scanning phase. The tool sends numerous attack vectors to the previously found endpoints to test for different types of vulnerabilities. Many of the test cases for common vulnerabilities such as SQL Injections, XSS, LFI, SSRF come out of the box, but most DAST tools allow you to create additional attack scenarios.
The last step is to display the results. If the tool suspects it found a vulnerability, it will provide detailed information about the URL, attack vector, vulnerability type, severity, and basic information on how to fix it.
Unlike SAST, DAST tools analyze a running web application and not its source code. Hence, they can identify vulnerabilities that SAST tools cannot. Authentication issues, memory leaks, session issues, and weak ciphers are just a few examples.
Also, this method is not dependent on the technologies used to develop the web application. Since it uses a black-box approach, DAST tools test all web applications in the same way regardless of their underlying programming languages or technologies.
DAST tools analyze both the application and middleware systems such as web servers, databases, and proxies so that they can identify vulnerabilities not just in the web application, but in infrastructure as well.
Just like SAST, DAST tools cannot identify access control issues. Also, DAST tools can indicate the existence of a vulnerability, but since they don’t have access to the source code they cannot pinpoint the exact location in the code. Hence, the developer or tester has the responsibility to identify and fix the faulty code block.
While this approach tends to produce less false positives compared to SAST, fully automated DAST solutions still generate a large number of false positives. After all, automated tools cannot understand the expected behavior of a feature. This is why sometimes DAST makes confirming and prioritizing issues laborious. Luckily, there are many bug tracking platforms that can be integrated with DAST solutions to make this process easier.
Another issue is that during the active scanning phase the tool sends attack payloads that may modify, delete, or corrupt existing application data. For this reason, all tests should be performed in a non-production environment.
Finally, depending on how they are configured, DAST tools may not cover 100% of the application, which means they can miss some vulnerabilities in less-obvious features.
Interactive Application Security Testing (IAST)
Interactive Application Security Testing (IAST) is a hybrid testing approach that promises to solve the main drawbacks of SAST and DAST by combining the best of both. In other words, IAST tools analyze the source code of the web application while it is running to identify more vulnerabilities with a lower rate of false positives.
How IAST Tools Work
IAST tools work by deploying agents and sensors in a running web application. The role of these agents is to continuously monitor and analyze the application’s behavior during manual or automated tests. They can identify information including HTTP traffic, data flow, control flow, infrastructure data, configuration options, or calls to external services. All of this information is passed to an analysis engine which confirms whether a vulnerability exists or if it is a false positive.
There are two types of IAST approaches:
- Active IAST — this approach involves two components: one that generates attack scenarios and the other one which monitors a running web application’s behavior
- Passive IAST — this approach uses a single component, a sensor which oversees the running web application — this tool does not simulate any attacks
IAST solutions combine the best of both SAST and DAST. For instance, they can use data collected by sensors about middleware services (web servers, proxies, load balancers, etc.) and configuration options to check for misconfigurations. This is something that SAST can’t do. On the other hand, IAST tools also analyze the entire codebase of the running application and can show the exact location of a vulnerability, unlike DAST.
The results generated by IAST are much more accurate compared to SAST and DAST tools since IAST uses multiple sources of data to confirm a vulnerability. For example, if a potential SQL Injection vulnerability is detected during code analysis, the tool will access the HTTP request to check if there are any errors or if the behavior of the application can be altered by a SQL Injection payload.
Another advantage is code coverage. IAST solutions can analyze the entire codebase, including open-source libraries and frameworks. Since they know exactly what classes and methods of a library are used by the web application, they can filter out irrelevant public vulnerabilities of a particular library.
Furthermore, IAST tools can be used during different phases of the SDLC, both early, late, or even in production.
Implementing an IAST solution could be much harder than using a SAST or DAST tools. This is because IAST requires the installation of security sensors and agents within the web application. Depending on the IAST tool, the setup process can be complicated and require the assistance of a specialist. Additionally, it is possible to have compatibility issues between the IAST agent and the technologies used to develop the application.
IAST tools analyze the features of a web application that are executed. Therefore, the developer has the responsibility to create tests that cover the entire application.
Lastly, IAST tools are more expensive compared to SAST and DAST tools.
SAST, DAST, and IAST are great tools that can complement each other. Ideally, it would be best to use a combination of tools to ensure better coverage and lower the risk of vulnerabilities in production applications. The SDLC has significantly sped up in the last few years and traditional testing methods cannot keep up with the pace of web development. Using automated testing tools in the early stages can significantly improve security with minimal cost. However, keep in mind that these tools are not meant to be a replacement for all other secure coding practices, but rather are part of a larger application security effort.
Original post available here: https://blog.hackedu.com/sast-vs-dast-vs-iast