Web-hosted applications have become commonplace in the digital era. We interact with them multiple times each day as we go about our normal routines, whether we’re doing so via online banking, checking the status of a shipment, or browsing products on Amazon. As with everything on the internet, web applications aren’t inherently secure, however, and cybersecurity experts must continuously assess them using application security testing methods.
Although there are many techniques for application security testing, this article highlights the differences between two popular methods: static application security testing (SAST) and dynamic application security testing (DAST), respectively.
What Is SAST?
Why Is Application Security Testing Necessary?
Web applications are those that run on remote web servers but are delivered via a web interface. When you navigate to a site like PayPal to generate an invoice or Etsy to shop online or Google Drive to edit documents, you’re accessing these applications over the internet. In the background, however, the site contents are retrieved from a web server. The back-end of these web applications relies on code that, if insecure, can be susceptible to exploits like SQL injection and cross-site scripting.
Application security testing involves the use of various methods to analyze a web application and validate it isn’t using any protocols, versions, or code that are known to contain weaknesses. These vulnerabilities lead attackers to perform exploits that allow them to hijack existing user sessions, gain unauthorized administrator access to the front-end application, gain back-end database access to modify or steal sensitive data, and more.
With the prevalence of web applications and the large amount of sensitive data these applications process on a daily basis, it’s more important than ever for organizations to ensure their systems don’t contain any obvious flaws. To do this, all companies must perform some level of application security testing periodically to identify potential issues and ensure they’re resolved.
What Is SAST (Static Application Security Testing)?
SAST is a security testing technique that involves code analysis to identify flaws that can lead to an insecure application. SAST tools test the source code against known application weaknesses including buffer overflow, lack of proper access control mechanisms, weak or outdated components, insufficient logging and monitoring, and more. Although a team can perform SAST against an application at any time, it’s often used throughout the development iterations as part of the continuous integration/continuous development (CI/CD) lifecycle. This helps speed up the development process by avoiding having to go back and fix security issues after the fact. Instead, developers work closely with security staff to ensure the source code is continuously assessed for flaws as new blocks of code and functionality are added.
What Is DAST (Dynamic Application Security Testing)?
Contrary to SAST, DAST is an assessment method that’s performed when the application is running and without access to the source code. Rather than look for flaws in the code itself, DAST sets out to discover security issues in the application’s functionality in real-time. This type of testing is used to discover the same types of vulnerabilities mentioned earlier, but by simulating the actions a malicious actor would use in their exploits.
Since DAST is designed to detect vulnerabilities in a running application, it’s best performed once the development is complete. DAST should also be performed whenever source code is modified to add, remove, or update features.
What Does SAST Look Like in Practice?
To help further describe how each of these assessments works in practice, we can consider a hypothetical application. For simplicity, imagine we’ve developed code for an application that calculates the total of a shopping cart for an e-commerce site. The application must be able to add the cost of the items in the cart to the calculated sales tax amount and an estimated shipping fee to present the total dollar amount. Due to the varied shipping costs depending on geolocation, the user will be required to input their ZIP code on the front-end (typically a text field on a website) so the application can pull in the estimated shipping cost based on their location.
Much of the information needed to calculate the total of the shipping cart is queried from internal sources, like a pricing database and shipping fee list, and external sources, like a ZIP code lookup. The ZIP code, however, is a value that will be entered by a user, opening the application up to the risk of accidental or purposeful malicious input.
With that in mind, a SAST test is run against the source code of this application. The assessment finds a single critical flaw in the code: input validation failure within the user input field. This means the application did not check whether the input was valid and in line with the type of data that should be entered. This type of vulnerability can have serious implications as it would allow an attacker to send malicious code to the back-end web server. The SAST assessment has helped to identify this hole in the source code, and the developer now knows they need to add input validation that defines what characters are allowed (numbers zero through nine) and which aren’t (e.g., letters, symbols, and mathematical operators).
What Does DAST Look Like in Practice?
Once the input validation vulnerability has been resolved and the application is fully developed, the security team performs a DAST assessment against the front-end of the application which, in this case, is the webpage where the cost calculator is running. Remember, DAST tests the application’s security from an outsider’s perspective and therefore does not have access to the infrastructure supporting the application or the source code.
The DAST assessment runs a series of tests to identify whether or not vulnerabilities are present in the front-end that can be exploited to gain unauthorized access to the application. After the scan is completed, the security team reviews the findings and sees that a SQL injection vulnerability is present. SQL injection is a type of attack where a malicious actor can use either a URL or input field to send SQL statements to the back-end database. This is a critical finding as it can result in the exposure, modification, or deletion of sensitive data within a database.
For the purposes of this example, the database at risk is the pricing table. According to our DAST assessment, a malicious actor would be able to send statements to our SQL database to obtain, modify, or delete price data using the URL, which means the developers need to modify the application to ensure URL routes are defined properly and either parameterized APIs or character escaping is in place. Parameterized APIs (short for application programming interface) may sound complex, but it’s essentially taking an allow-or-deny approach to the communication occurring to and from the application. Character escaping is similar to input validation and results in the application ignoring special characters.
With the findings from each type of security test remediated, the security team can run a scan to validate the issues have been resolved and the application is now ready to be placed in production.
What Are the Differences Between SAST and DAST?
As described above, SAST is a testing method employed during development, whereas DAST is performed on fully developed applications. So, how else do these two testing techniques differ?
For one, the tests are performed from two different perspectives. SAST strictly assesses the source code and nothing else, meaning the approach is that of a developer. DAST actively performs actions within the running application in an attempt to exploit known weaknesses, therefore assessing the application security from a malicious actor’s perspective. Considering this, it makes sense that SAST is a white box security test and DAST is a black box test, which refers to whether the tester does or doesn’t have in-depth knowledge of the resource being tested and its surrounding technological environment.
Due to the differences in the types of security tests each run, the outputs are vastly different as well. Since SAST is performed statically and has no knowledge of how the application runs, it’s unable to detect security issues that present themselves during runtime. Similarly, DAST can detect runtime security vulnerabilities, but not source code flaws. This further highlights the fact that SAST and DAST complement one another and are needed to identify security issues both during development and prior to the completed application being released to production.
