Interactive Application Security Testing (IAST)

IAST is a new application security testing technique that has become popular in recent years and is recognized by Gartner as one of the top 10 technologies in the cybersecurity field. IAST works to constantly monitor and collect the traffic or codes inside when the application is running, and transfer them to the security analysis engine to identify the vulnerability characteristics in the process of code execution. Based on the collected data traffic and codes, IAST runs tests similar to DAST and SAST, with an extra-high vulnerability detection rate and an extra-low false alarm rate, so that it can locate API interfaces and code snippets.

Common effective IAST technologies are implemented by insertion. ISAT inserts a probe on middleware where codes are running to identify and determine security risks and find problems directly from the running codes. In this way, IAST enables automatic identification and diagnosis of software vulnerabilities in applications and on APIs.

Deployed in the middleware of a service, an IAST probe can obtain more information, so it may be a combination of SAST and DAST in some sense, including but not limited to codes/traffic analysis, mainly in the following aspects:

(1) Code

IAST can access all source codes and binary codes deployed together with the application. The code probe performs binary static analysis on each line of code in the application, including libraries and frameworks;

(2) HTTP Traffic

HTTP traffic collection refers to the process of collecting HTTP/HTTPS request traffic during application testing. The collection can execute through the proxy layer or the server agent. The collected traffic is valid data with authorization information submitted by the tester. It can minimize invalid scans that occur frequently due to permissions of test targets or multi-step problems. Meanwhile, traffic collection omits the crawler function so as to avoid scan omissions due to failure to crawl test targets.

(3) Libraries and Frameworks

IAST can check every library and framework deployed, to analyze how applications and APIs use them. IAST can not only evaluate libraries based on common vulnerabilities and exposures (CVE) but also identify unknown vulnerabilities that are partially or completely hidden in libraries. What counts is that IAST knows exactly what parts are truly called by the application and filters the library-related vulnerabilities that have never been called.

(4) Application State

IAST checks the application state when the application is running. For example, IAST identifies vulnerabilities by checking the parameters used when calling a security method, such as passing a “DES” parameter to an encrypted password constructor function;

(5) Data Flow

IAST tracks untrusted input data from the moment it enters the application. This is the key to identifying the vital vulnerability type—injection vulnerability. This technique, sometimes called “taint tracking”, tracks the mobility of real data in the application, and it is very precise.

(6) Control Flow

IAST knows the control flow of the application and can identify vulnerability characteristics in application behaviors. For example, if an application is required to check the access control using service ( ) in each web service, the characteristic will be identified easily.

(7) Back-end Connection

IAST checks all details about back-end connections, such as databases, operating system calls, directories, queues, sockets, emails, and other systems. IAST identifies architectural and security defects depending on the obtained information.

(8) Configuration

IAST accesses the configuration of applications, frameworks, application servers, and platforms, to ensure the correct security configurations. IAST can query the runtime configuration of application components, such as XML parsers. Note that some platforms, such as .NET, are heavily dependent on configurations to maintain security.

Depending on its technical features, IAST can be used in the following scenarios:

Early Detection of Vulnerabilities in the Development and Testing Phases

Based on its characteristics, IAST can be used to identify vulnerabilities found in source codes or APIs as soon as possible during software development and testing so as to fix vulnerabilities in the early phase of the development process. Therefore, IAST is better than traditional static security analysis and dynamic application security testing technologies in terms of detection speed, accuracy, and process flow.

Continuous Detection and Prevention of Vulnerabilities in the Operational Phase

Due to its nature of continuous detection, IAST can identify vulnerabilities that have not been found before, for example, 0 Day vulnerabilities and new vulnerabilities. By inserting probes inside applications, when detecting a threat, IAST can block attacks by customizing emergency response policies, such as terminating user sessions, closing applications, and giving alarms to security personnel.

Some of the current IAST products also have the capability of software composition analysis. By inserting probes inside applications, IAST collects third-party components and dependencies dynamically loaded when the application is running. In this way, it automatically generates a software bill of materials (SBOM) and transfers it to the component vulnerability analysis engine for the detection of component-dependent security risks. This protects the software upstream of the supply chain from being contaminated by an insecure underlying layer.

Fuzzing (Fuzz Testing)

Robustness is an essential indicator for software products. Especially in some critical infrastructure areas, such as healthcare, power, communications, and finance, among others, the failure of software products may lead to catastrophic events or large-scale data leakage, and even personal injury or environmental damages. The unpredictable nature of the failure may also result in some failures such as system information leakage, which will be further used by attackers. Fuzzing is a strong technique to evaluate the robustness and security of software. It essentially inputs unexpected data into the target system to check whether the target system fails, for example, crash, infinite loop, resource leakage or shortage, and unexpected behavior, among others, and gives failure causes and repair suggestions for users.

Fuzzing generally involves three phases: test case generation, test case input, and test result verification.

(1) Test Case Generation

Each unexpected data is a test case. Theoretically, the unexpected data is infinite. Test case generation aims to design the test case that is most likely to trigger a failure in the target system. In essence, a test case should be close to the expected input of the target. The quality of a test case is critical to the effectiveness of fuzzing. Common test case generation technologies include random generation and template-based generation:

Random Generation

It is the simplest and least efficient generation technique. It simply uses random data as test cases. Random fuzzing is generally invalid as the test cases are completely different from valid inputs. The target system checks and quickly declines test cases. In most cases, test cases cannot penetrate into the target codes.

Template-based Generation

It runs variations to create test cases by using valid data as a template. In most cases, template test cases are mostly correct and thus more effective than random test cases. The target software system will process test cases to test the system’s capability of processing unexpected inputs.

(2) Test Case Input

Depending on different target systems or test types, there are different fuzzing types and test case input modes for the fuzzing of network protocols, files, APIs, and user interfaces. For the fuzzing of a network protocol, the end-to-end connection with a network server or client needs to be built to transmit test cases to the receiver. For the fuzzing of a user interface, the operations of the user interface with a mouse or keyboard need to be simulated. Most modern operating systems and programming environments provide a programmatic way to transfer inputs so that test data can be automatically transmitted through software.

(3) Test Result Verification

Failure types typically include crashes, infinite loops, resource leakage or shortage, and unexpected behaviors, which generally can be manually observed, or automatically determined by fuzzing tools.

Fuzzing may be used to detect unknown vulnerabilities in the development and delivery phases of the software supply chain. Source codes may go through fuzz testing to locate and eliminate vulnerabilities as early and fast as possible in the development phase. Fuzzing may also be used to verify the robustness and reliability of software in the delivery and operational phases of the software.

In recent years, as the frequent supply chain security incidents caused by the malicious injection of open-source components and software codes abound here and there, supply chain security testing techniques strive to eliminate security problems in different phases along the software development lifecycle.

Previous posts on software supply chain security: