Static detection method and device for command injection vulnerability

Abstract

The invention discloses a command injection vulnerability static detection method and device, and aims to overcome the defect that potential vulnerabilities exist in injection vulnerability static detection through an existing AST. The method comprises the following steps: analyzing a source code and generating a static single assignment intermediate representation; positioning and analyzing a starting point, an ending point and a security node; tracking and analyzing data streams in the functions and among the functions; vulnerability judgment and report generation; wherein the analysis of the source code comprises the steps of constructing an abstract syntax tree through a compiler on the basis of the source code, forming a data flow path by static single assignment intermediate representation through an SSA converter, and the data flow path comprises a definition-use chain and a use-definition chain of variables, so that an accurate semantic basis is provided for subsequent data flow tracking. According to the method, each language is converted into SSA-IR, so that a black box state presented by items collaborated by different languages in static analysis can be avoided, a data flow path of a variable can be continuously tracked, and the position of a command injection vulnerability can be accurately positioned.

Description

Technical Field

[0001] This invention relates to the field of static analysis vulnerability detection, and more specifically, to a method and apparatus for static detection of command injection vulnerabilities. Background Technology

[0002] With the rapid development of network information technology and the continuous expansion of software system scale, security incidents caused by software security vulnerabilities are emerging one after another. Among them, command injection vulnerabilities, as a very typical and extremely harmful high-risk security vulnerability, have long been a focus of attention in the field of cybersecurity.

[0003] The core attack principle of this vulnerability lies in the fact that, during the interaction between the target application and the underlying operating system, the application fails to rigorously filter, clean, or validate untrusted external source data (user-supplied input) before directly passing it as a parameter to critical functions that execute system commands (such as the `system()` and `exec()` family of functions in C / C++, or `os.system()` in Python). Attackers can exploit this logical flaw by constructing input strings containing specific metacharacters or malicious instructions, inducing the application to parse them as legitimate operating system commands. Once executed successfully, the attacker gains low-level execution privileges on the target system, enabling them to commit serious illegal acts such as stealing sensitive data, damaging system files, and implanting malicious code, posing incalculable risks to the security of the software system and the privacy of user data.

[0004] For the detection of command injection vulnerabilities, existing technical solutions mainly consist of two major technical pillars: dynamic detection and static detection.

[0005] Dynamic detection methods: These methods (such as fuzz testing, dynamic taint analysis, and interactive application security testing) discover vulnerabilities by inputting test vectors and observing the program's behavior during actual execution. While dynamic detection offers advantages such as a lower false positive rate and intuitive, easily verifiable results, its limitations are also significant. First, dynamic detection heavily relies on the completeness of test cases, requiring the actual running of the target program and the construction of a complex execution environment. This often results in insufficient test coverage when dealing with large software applications with numerous logical paths. Second, dynamic detection incurs significant performance overhead and is inefficient, making it difficult to meet the demands for large-scale, automated, and comprehensive detection when facing massive codebases or rapidly iterating development processes.

[0006] Static detection methods, unlike dynamic detection, uncover potential security vulnerabilities by directly analyzing source code or intermediate representations (IR) without actually launching the program. Due to their core advantages such as high test coverage, broad detection scope, and early problem detection, static detection methods have gradually become the mainstream technology for large-scale code vulnerability detection.

[0007] However, in-depth research has revealed that existing static detection methods, especially those based on Abstract Syntax Trees (ASTs) or simple data flow analysis, still suffer from the following key shortcomings in practical applications, severely restricting further improvements in detection accuracy and analysis efficiency: Poor cross-language generalization ability and high maintenance costs: Analysis methods based on ASTs or simple data flows are often deeply coupled to the syntax of specific programming languages. Because the function names, calling conventions, and parameter positions of system command execution functions differ across programming languages ​​(such as Java, C++, Go, PHP, etc.), existing detection tools typically require customized development and manual rule configuration for each specific language environment. This over-reliance on language-specific details leads to a lack of universality in the detection scheme. When faced with complex applications developed using multiple languages, the development difficulty, the complexity of the detection logic, and the subsequent rule maintenance costs all increase significantly.

[0008] Coarse-grained logical modeling leads to a high risk of false negatives: Simple static analysis schemes often focus only on local syntax matching, easily overlooking the complex control flow logic that variables undergo during program propagation. In actual software business logic, external input data often passes through numerous conditional branches, loop structures, and complex function call chains. If detection methods cannot perceive these control flow changes, it becomes difficult to accurately trace the actual propagation path of tainted data within the program. This not only leads to a failure to detect deeply nested vulnerabilities but also easily generates a large number of false negatives, allowing many potential vulnerabilities hidden behind complex logic to escape security monitoring.

[0009] In summary, this application aims to provide a static detection method for command injection vulnerabilities, which, based on an abstract syntax tree, combines intra-procedural and inter-procedural context-sensitive tracing to fully consider the complex control flow and conditional branches that may exist during the transmission of variables in the program, thereby improving detection accuracy and analysis efficiency. Summary of the Invention

[0010] This invention overcomes the shortcomings of existing static detection methods for injection vulnerabilities using abstract syntax trees (ASTs), and provides a static detection method and apparatus for command injection vulnerabilities. Based on the abstract syntax tree, it combines intra-process and inter-process context-sensitive tracing to fully consider the complex control flow and conditional branches that may exist during the transmission of variables in the program, thereby improving detection accuracy and analysis efficiency.

[0011] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A static detection method for command injection vulnerabilities, characterized by the following steps: S1. Parse the source code and generate a static single-assignment intermediate representation; S2. Locate the starting point, ending point, and safety node of the analysis; S3, Data flow tracing analysis within functions and data flow tracing analysis between functions; S4. Vulnerability Assessment and Report Generation; The parsing of the source code in step S1 includes building an abstract syntax tree based on the source code through a compiler, converting the abstract syntax tree into a static single assignment intermediate representation through a converter, and forming a data flow path from the static single assignment intermediate representation. The data flow path includes the definition-use chain and the use-definition chain of variables.

[0012] This step leverages existing parsers that convert programming languages ​​into abstract syntax trees (ASTs), avoiding reinventing the wheel. The AST provides crucial structural information for SSA-IR, explicitly displaying structural information previously implicit in the source code, making it easier to represent within SSA-IR. Another advantage of using AST to SSA-IR is that AST construction is a prerequisite for compilation into machine code. This process can be integrated into the CD-CI workflow, enabling reuse of workflow and computational resources. Furthermore, the AST preserves complete function names and parameter information, which can be used for subsequent matching of cleanup functions in the knowledge base. Additionally, when an injection vulnerability is discovered, the AST is used to locate the vulnerability within the source code.

[0013] Preferably, in step S2, the analysis start point, end point, and safety node are identified using an analysis location mechanism based on predefined symbols, method names, or knowledge bases. The analysis start point includes function call points or file read inputs from untrusted external inputs, the analysis end point includes function call points that execute system commands, and the safety node includes cleanup functions used to translate input characters.

[0014] Preferably, the predefined rules are described and configured using a declarative language. Configuring these rules through an external knowledge base using a declarative language facilitates management and expansion. Compared to direct hard coding, an external framework allows for easier management and maintenance of predefined rules, and also provides greater flexibility in adjusting detection strategies, such as adding new cleanup functions or modifying matching rules.

[0015] Preferably, the data flow tracing analysis within the function in step S3 includes: marking variables starting from each analysis point as tainted states, performing data flow operations forward using the definition-use chain and the use-def chain, so that each variable inherits the tainted state of the upstream variable, and triggering the audit function to mark the variable as tainted and stop tracing the variable when the tracked variable is passed as a parameter to the cleansing function.

[0016] Preferably, step S3 further includes: chaining calls to tainted data, recursively passing the tainted state of the tainted data to the final result of the chaining calls.

[0017] As a preferred embodiment, the inter-function data flow tracing analysis in step S3 includes: constructing a function call graph based on the function call relationship represented by a static single assignment, traversing the function call graph, binding the actual parameters of the caller and the formal parameters of the callee at the function call boundary, and passing and merging the tainted state and cleansed state of the actual parameters to the initial state of the formal parameters of the callee.

[0018] As a preferred method, the determination of vulnerability severity includes: Find the data flow path corresponding to the injection vulnerability, which can be abstracted as a directed graph, where nodes represent data nodes in the program and directed edges represent the data flow direction; Betweenness centrality analysis and dominance node analysis are performed on the directed graph to obtain high-frequency nodes and dominance nodes; Injection vulnerabilities are scored based on the degree of overlap between their data flow paths and high-frequency nodes, as well as their deviation from the dominant node.

[0019] Preferably, the vulnerability report generated based on the obtained command injection vulnerability includes the vulnerability location corresponding to the source code location, the data flow path from the start point to the end point of the analysis, and the vulnerability severity level.

[0020] Preferably, this also includes setting filtering for vulnerability reports through declarative filters; or, it also includes using software composition analysis tools (SCA tools) to increase the vulnerability severity level when the vulnerability's data flow path passes through a known vulnerable third-party library.

[0021] Preferably, before or after the vulnerability report is generated, a declarative filter can be used to screen the vulnerability detection results. Alternatively, set operations can be used to process multiple data stream analysis results or multiple vulnerability sets. The set operations include finding the intersection, difference, or union of sets to optimize the analysis path or screen the detection results.

[0022] Preferably, before or after the vulnerability report is generated, a declarative filter can be used to screen the vulnerability detection results. Alternatively, set operations can be used to process multiple data stream analysis results or multiple vulnerability sets. The set operations include finding the intersection, difference, or union of sets to optimize the analysis path or screen the detection results.

[0023] As a preferred approach, when a function call to native code is encountered during data flow tracing, the impact of the function call on the tainted state is simulated through the native extension mechanism to achieve cross-function data flow tracing.

[0024] As a preferred approach, call context-sensitive analysis is also implemented by maintaining call stack information to distinguish the data flow state when the same function is triggered at different call points.

[0025] As a preferred option, the vulnerability determination in step S4 also includes introducing path sensitivity verification, using a constraint solver to solve the predicate conditions on the taint flow path to eliminate logically unreachable false vulnerability paths.

[0026] An apparatus for static detection of command injection vulnerabilities based on SSA-IR data stream tracing includes a processor and a memory, the processor being configured to read instructions from the memory to execute the aforementioned method.

[0027] Compared with the prior art, the beneficial effects of the present invention are: (1) Static single assignment intermediate means that a data flow path is formed through the SSA converter. The data flow path includes the definition-use chain and the use-def chain of variables, which provides an accurate semantic basis for subsequent data flow tracing. By converting each language to SSA-IR, the black box state presented in static analysis of projects with different languages ​​can be avoided, and the data flow path of variables can be continuously traced, thereby accurately locating the location of command injection vulnerabilities; (2) By tracing forward by assigning tainted states to variables, command injection vulnerabilities can be found in a simple way. Attached Figure Description

[0028] Figure 1 This is a conversion diagram from source code to AST to ASSIR; Figure 2This is a diagram illustrating the matching principle, including the starting point, ending point, and safety nodes of the matching analysis. Figure 3 This is a schematic diagram of data flow tracing and analysis inside a function; Figure 4 This is a schematic diagram of data flow tracing analysis between functions; Figure 5 This is a diagram illustrating vulnerability assessment based on the pollution attributes of variables. Detailed Implementation

[0029] The present disclosure will be further described below with reference to the accompanying drawings and embodiments.

[0030] It should be particularly noted that all detailed descriptions, specific implementation methods, technical parameters, and related implementation examples presented in this application specification are essentially illustrative, primarily serving as examples to aid explanation, and should not be considered the sole limitation on the substantive content of the invention. The core purpose of providing this content is to offer a more detailed, intuitive, and in-depth explanation of the command injection detection technology concept, core algorithm logic, and inventive points involved in this application, combined with specific application logic and processing scenarios, aiming to assist those skilled in the art in more clearly and completely understanding the specific implementation process of the invention in a real-world environment. The actual scope of protection of this application should be determined by the textual and logical scope defined in the claims; the specific implementation details herein do not constitute any form of limitation or exclusive interpretation of the scope of protection of the claims.

[0031] Meanwhile, unless otherwise explicitly specified, defined, or limited in scope for certain specific terms, technical phrases, or expressions in the textual description of this application, all technical and scientific terms used in this specification and claims shall be given the same meaning generally recognized, known, and accepted by a person skilled in the art within the technical fields of computer software security testing, static program analysis, source code auditing, and vulnerability identification to which this application pertains. This principle of consistency in the understanding of terminology aims to ensure that the technical solutions of this application, in subsequent patent examination, technical implementation, and legal protection processes, possess a high degree of certainty, standardization, and logical rigor based on the general standards and industry practices of the relevant field. It should be noted that the terminology used herein is for describing specific embodiments only and is not intended to limit the exemplary embodiments according to this application. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0032] As those skilled in the art will understand, aspects of the present invention can be implemented as systems, methods, or computer program products executable on local and / or remote computing devices. Therefore, aspects of the present invention can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computing devices on one or more computer-readable media having computer-readable program code implemented thereon. The embodiments described herein can be entirely hardware, entirely software, or include both hardware and software elements. In some embodiments, according to aspects of the present invention, the invention is implemented in software, including but not limited to firmware, resident software, microcode, etc.

[0033] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. Other examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any combination thereof. In this document, a computer-readable storage medium can be any tangible medium that can contain or store programs used by or in connection with a computing system, apparatus, or device.

[0034] Program code implemented on a computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, and any combination thereof. Computer program code used to perform operations of aspects of this invention can be written in any combination of one or more programming languages, including but not limited to any general-purpose programming language (e.g., PHP, Java, C++, etc.) and / or domain-specific programming languages ​​(e.g., HTML, SQL, etc.), blockchain-specific programming languages ​​(e.g., Solidity, Rust, Java, Python, etc.). The program code can be executed entirely on the user's computer / mobile device, partially on the user's computer / mobile device, as standalone software, partially on the user's computer / mobile device and partially on a remote computer / mobile device, entirely on a remote computer or server, and / or using a blockchain. Remote computers can be connected to the user's computer via any type of network (e.g., a local area network (LAN), a wide area network (WAN), a connection to an external computer (e.g., via the Internet using an Internet service provider), etc.).

[0035] Aspects of the invention are described below with reference to flowchart illustrations and / or block diagrams of methods, systems, and computer program products according to embodiments of the invention. Note that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions.

[0036] Computer program instructions may also be loaded onto a computer, mobile device, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on any computing system to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide a process for implementing the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0037] Computer-readable signal media may include propagated data signals (e.g., a portion of baseband, carrier wave, etc.) containing computer-readable program code. Such propagated signals may take any of a variety of forms, including but not limited to electromagnetic, optical, or any combination thereof. A computer-readable signal medium may be any computer-readable medium that is not a computer-readable storage medium and may communicate, propagate, or transmit programs for use by or in conjunction with a computing system, apparatus, or device.

[0038] Network adapters can also be coupled to a system to enable data processing systems to connect to other data processing systems, remote printers, storage devices, blockchains, etc., via an intermediary private or public network. Modems, cable modems, and Ethernet cards are just a few of the types of network adapters currently available.

[0039] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function, and in some alternative implementations of the invention, the functions indicated in the blocks may occur in a different order than those shown in the figures. For example, depending on the functionality of a particular embodiment, two blocks shown consecutively may actually execute substantially simultaneously, sometimes in reverse order, or in any other order.

[0040] Example: like Figure 1 As shown, a static method for detecting command injection vulnerabilities is based on Static Single Assignment Intermediate Representation (SSA-IR). This step involves constructing an Abstract Syntax Tree (AST) of the source code using a compiler, and then converting the AST into a Static Single Assignment Intermediate Representation (SSA-IR) using a converter.

[0041] The compiler first performs lexical analysis, taking the original source code text as input and traversing the source code character by character. According to the lexical rules of the target programming language, it segments consecutive characters into indivisible semantic units (Tokens). Redundant characters without semantic meaning (such as spaces, newlines, and comments) are automatically ignored, retaining only tokens with actual meaning. Finally, unrecognized characters are discarded. This provides "standardized semantic building blocks" for syntax analysis—Tokens are the smallest semantic units of code. Syntax analysis no longer needs to deal with messy characters; it only needs to verify and construct structures based on the Token sequence, significantly reducing the complexity of syntax analysis.

[0042] After lexical analysis, the token sequence undergoes further syntactic analysis: the combination of token sequences is verified for legality according to the syntax rules of the programming language. In some embodiments, these syntax rules include BNF (Browser-Nine Functions) definitions. If the token sequence conforms to the syntax rules, the linear token sequence is reorganized into a hierarchical tree data structure (AST)—each node of the tree corresponds to a syntactic structure of the code (such as a program root node, variable declaration node, expression node, literal node, etc.). If the token sequence does not conform to the syntax rules (e.g., missing semicolons, misspelled keywords, incomplete expression structure), an exception is thrown. The AST is a "structured semantic representation" of the source code, allowing computers to easily understand the logic of the code by traversing the AST.

[0043] After converting the source code into an AST, it is then converted into an SSA-IR using a converter. SSA-IR is the core intermediate representation between the front end (AST) and the back end (target code generation) of the compiler. Its core feature is that each variable is assigned a value only once, which makes code optimization extremely efficient.

[0044] First, a Control Flow Graph (CFG) is constructed to transform the Abstract Syntax Tree (AST) into an Execution Flow Graph. The AST is traversed, merging consecutive statements without jumps into "Basic Blocks"—the smallest unit of execution, satisfying "one entry point, one exit point," with no internal jump logic. Control flow nodes in the AST are identified, establishing "predecessor / successor" relationships for each Basic Block. Directed edges connect different Basic Blocks, forming the CFG. This transforms the "static syntax tree" into a "dynamic execution flow graph," fully preserving the program's execution path and branching logic. The execution context of each statement is clearly defined, providing the execution context for subsequent SSA transformations—the "single assignment" constraint of SSA requires determining the assignment / usage range of variables based on the execution path; the CFG is the foundation for all SSA transformation steps.

[0045] Next, variable renaming is performed with the goal of ensuring that "each variable is assigned only once": This involves traversing each basic block of the CFG, tracking all variable assignment operations, assigning a unique version number to each assignment of the same variable, and updating all references to that variable: making each reference point to the "most recent assignment version on the execution path," and converting ordinary IR to SSA form. This is a prerequisite for all subsequent optimizations. The single assignment feature allows the compiler to quickly track the source and destination of variables, significantly reducing the complexity of data flow analysis.

[0046] Next, the φ function is generated for control flow merging. When multiple basic blocks in the CFG (such as two branches of an if statement) converge into the same "merge block," variables may have multiple versions. The φ function is needed to solve the problem of "which version to use": it identifies the "merge point" in the CFG and then inserts the φ function (a pseudo-operation, handled at compile time, with no runtime overhead) at the beginning of the merge block. The parameters of the φ function correspond to the variable version in each preceding block. Based on the execution path, it selects the corresponding variable version from the preceding block, resolving variable version conflicts during control flow merging and ensuring that SSA constraints still hold in branching scenarios. The φ function is the "core patch" for SSA to handle branching logic, ensuring that variables can find a unique definition version regardless of the execution path the program follows, maintaining the integrity of the data flow.

[0047] Then, maintain the data flow to ensure the semantic correctness of SSA-IR. Perform validation and refine the data flow associations: Reverse update the AST / CFG nodes: replace all variable references with the final version number, construct the definition-use chain (DU chain), and verify that there are no "references to undefined variable versions" or "defined but unused variable versions," thus establishing a "variable version" system. Execution path A precise mapping of "reference location" generates a defined-use chain.

[0048] Finally, SSA-IR optimization is performed, which uses the compiler to perform targeted optimizations, including removing versions of variables that have never been used since their definition, directly replacing constant assignments with reference points, moving calculations that do not change inside loops to outside loops to avoid duplicate calculations, and removing duplicate assignments or calculations. This simplifies the optimization logic and allows the compiler to efficiently perform analysis and optimizations that are difficult to achieve with traditional IR.

[0049] Having obtained the definition-use chain through the aforementioned steps, we now need to obtain the corresponding use-definition chain to prepare for subsequent work: In the aforementioned AST to SSA-IR process, we obtain the definition-use chain (DU), associate it with the control flow graph (CFG), and retain the basic block and execution path information to which each definition / use point belongs. The definition point includes the variable name and code location. The use point list includes the variable usage location and usage scenario. This provides a "structured data source" for the reverse mapping, ensuring that subsequent transformations have unified and traceable basic data, avoiding omissions or incorrect mappings.

[0050] Based on the aforementioned DU chain, a reverse UD chain is constructed using the definition chain. This involves initializing an empty UD chain structure, traversing each DU chain, creating any DU chains not already in the UD chain, and appending any existing DU chains to their corresponding lists. This transforms the unidirectional association of DU chains into the reverse association of UD chains, satisfying the compiler's core requirement of analyzing "where a variable at a certain usage point comes from."

[0051] This step leverages existing parsers that convert programming languages ​​into abstract syntax trees (ASTs), avoiding reinventing the wheel. The AST provides crucial structural information for SSA-IR, explicitly displaying structural information previously implicit in the source code, making it easier to represent within SSA-IR. Another advantage of using AST to SSA-IR is that AST construction is a prerequisite for compilation into machine code. This process can be integrated into the CD-CI workflow, enabling reuse of workflow and computational resources. Furthermore, the AST preserves complete function names and parameter information, which can be used for subsequent matching of cleanup functions in the knowledge base. Additionally, when an injection vulnerability is discovered, the AST is used to locate the vulnerability within the source code.

[0052] Static single assignment intermediates represent data flow paths formed through the SSA converter. These paths include the definition-use chain and the use-def chain, providing a precise semantic foundation for subsequent data flow tracing. By converting all languages ​​to SSA-IR, the black-box state presented in static analysis of projects collaborating on different languages ​​can be avoided. Continuous tracing of variable data flow paths enables accurate location of command injection vulnerabilities.

[0053] Next reference Figure 2 For SSA-IR, the starting point, ending point, and safety node of the analysis are located. The starting point, ending point, and safety node are identified using an analysis location mechanism based on predefined symbols, method names, or knowledge bases. The starting point includes function call points or file read inputs from untrusted external inputs. The ending point includes function call points that execute system commands. The safety node includes sanitization functions used to translate input characters.

[0054] SSA-IR is traversed using several Basic Blocks, with a coarse-grained screening process at the basic block level: a fast traversal of the SSA-IR control flow graph (CFG, with basic blocks as nodes) narrows the search scope. For example, a greedy algorithm is first used to locate basic blocks containing "file read functions, system command execution functions, and cleanup functions," and then precise matching is performed within each block, significantly improving search efficiency. Each basic block consists of several atomic SSA-IR instructions, which is the smallest operational granularity of SSA-IR and the final granularity for precise location of source / sink / cleanup functions. All marking and identification operations ultimately fall on specific individual SSA-IR instructions. After the initial screening, predefined symbols / method names are matched at the granularity of individual SSA-IR instructions. For input files, context detection is performed, analyzing file paths and metadata-related assignment / operation instructions to determine if they are untrusted external inputs. Finally, tainted source points / vulnerability sinks / secure nodes are marked. The knowledge base is configured using a declarative language through an external framework for easy management and expansion. Compared to hard-coding directly in the code, external frameworks make it easier to manage and maintain predefined rules, and also allow for more flexible adjustments to detection strategies, such as adding new cleanup functions or modifying matching rules.

[0055] Specifically, the starting point of the analysis includes tainted sources matched by predefined criteria. These sources are usually external untrusted data entry points such as user input interfaces and network data reception (e.g., $_GET['user'], HttpServletRequest.getParameter()). In some embodiments, for file read operations, a "file filtering mechanism" is used to analyze the context (such as whether the file path is user-controllable, whether the file is a configuration file, etc.) to determine whether the input should be considered a taint.

[0056] The analysis endpoints include vulnerability sinks that are matched through predefined definitions, such as sensitive operation points like command execution functions and system call interfaces (e.g., system(), Runtime.exec(), ProcessBuilder.start()). Security nodes include cleanup functions with pre-configured function names for translating input characters, such as HTML escaping and SQL parameterization.

[0057] The pre-configuration is based on a predefined "cleanup function knowledge base" that matches functions that can perform secure input processing (such as the escape function escapeshellarg(), the encoding function encodeURIComponent(), and the verification function filter_var()).

[0058] Next reference Figure 3The function internals data flow tracing and analysis. This step also implicitly involves object-oriented processing of variables, binding them with states for determining contamination or cleanliness. This allows for accurate determination of whether a variable is tainted or clean data by propagating and merging these state values ​​during the data flow tracing process.

[0059] Specifically, starting from the taint source, the propagation path of tainted data is traced forward along the UD chain and DU chain, marking the variable as tainted and propagating it to all subsequent variables using that variable. When the traced variable is passed as a parameter to the cleanup function, triggering the audit function, the variable is marked as cleaned and tracing of that variable stops. In some embodiments, the cleanup function and the variable entering the cleanup function's entry point are both variables entering the audit function. The cleanup function's function is executed sequentially, switching the variable from tainted to clean state. Subsequent variables of the variable that have passed through the cleanup function inherit the state of the previous variable and stop further tracing of that data. Downstream variables of this variable inherit this variable, and their states are synchronously modified to clean state.

[0060] It should be pointed out that, Figure 3 The terms "subsequent variable 1", "subsequent variable 2", and "subsequent variable 3" are used for comprehension only and not for actual states. As can be seen, subsequent variables 1 and 2 are located between the analysis starting point and the cleansing function. Furthermore, since this diagram uses the function's entry point as an example, in actual engineering environments, the function's entry point is often passed into the function through upstream variables.

[0061] To avoid losing track of variables due to chained calls, expressions are processed recursively to pass the taint state of tainted data to the final result of the chained calls, ensuring the correct transmission of taint states in complex expressions. In this embodiment, during the chained call, `self` is called, and in this process, the taint state is bound to `self`, thereby... In some embodiments, when a function call to native code (such as a C / C++ extension) is traced, continuous tracing across language boundaries is achieved by simulating the effect of that function on the data state (e.g., predefining certain native functions as propagation or cleansing functions).

[0062] This can enhance the practicality and analytical coverage in real-world complex projects, while also increasing the confidence of the detection method in this application and reducing the risk of variable detection escape.

[0063] refer to Figure 4This method performs data flow tracing analysis between functions. The AST to SSA-IR method enables clear function call relationships in the static single-assignment intermediate representation. These relationships are established by analyzing function call instructions, function declarations, and function references within the static single-assignment intermediate representation, including various call patterns such as direct calls, indirect calls, and virtual function calls. Based on these relationships, a function call graph is constructed. This graph is a non-cyclic directed graph structure where nodes represent functions and edges represent call relationships between functions. A complete call relationship network is built by analyzing all function call points throughout the program. The function call graph is traversed, and at function call boundaries, the actual parameters of the caller and the formal parameters of the callee are bound. The tainted and cleansed states of the actual parameters are passed and merged into the initial state of the formal parameters of the callee, achieving cross-function boundary data flow tracing. Through the construction and traversal of the function call graph, cross-function data flow tracing across the entire program can be achieved, ensuring the correct transmission of tainted states at function call boundaries, avoiding the loss of tainted states due to function calls, and improving the coverage and accuracy of command injection vulnerability detection. Specifically, when tainted data is passed through function parameters, the system can accurately track the propagation path of tainted states between functions and identify potential vulnerability propagation chains across function boundaries.

[0064] In some embodiments, the source code also involves function calls to native code. Since native code (such as Linux syscalls or Windows APIs) is unavailable, it's impossible to determine whether a function has cleaned the data upon entry. Therefore, this application employs a native extension mechanism. This mechanism establishes a behavioral model for each native function, describes its behavior using an external, predefined knowledge base, and sets taint propagation rules. The process involves identifying native functions, extracting contextual information, simulating the data flow according to knowledge base rules, and updating the taint status of variables. It is worth noting that there is no sequential relationship between data flow tracing analysis inside a function and data flow tracing analysis between functions. Instead, they are tainted state propagation based on the forward propagation of data flow. It is necessary to combine the two for judgment. There may be multiple internal functions inside a function. In this case, a comprehensive analysis should be performed by combining data flow tracing analysis inside the function and data flow tracing analysis between functions.

[0065] In some embodiments, call context-sensitive analysis is also implemented by maintaining call stack information to distinguish the data flow state when the same function is triggered at different call points. Its core function is to distinguish the behavioral differences of the same function under different call scenarios, thereby significantly improving analysis accuracy and reducing false positives and false negatives.

[0066] The principle behind this approach is to create an independent analysis context for each function call based on the call stack. The call stack not only records the order of function calls but also includes the specific location of the call point, parameter states, and the complete history of the call chain. When the analyzer encounters a function call, it generates a unique context identifier based on the current call stack. This identifier comprehensively considers the call path, parameter characteristics, and environment state. For the same function, different call contexts are treated as different analysis instances, each with its own independent state space. In traditional context-insensitive analysis, all calls to a function are treated equally. If the function processes polluted data in a certain path, then all places that call the function may be incorrectly marked as risky. Context-sensitive analysis, however, can accurately identify true vulnerabilities that only appear under specific call paths. Some security vulnerabilities only manifest in specific call sequences. For example, a function may only have a security risk when called by a specific module with a specific combination of parameters.

[0067] Context-sensitive analysis, through complete call chain tracing, can uncover vulnerabilities hidden within complex call relationships—vulnerabilities easily missed in traditional flattened analysis. By recording the complete call context, analysis tools can not only report the existence of vulnerabilities but also pinpoint the specific call path and environmental conditions in which they occur. This allows developers to understand the full context in which the vulnerability arises, enabling more targeted remediation. Remediation measures can be precisely applied to specific call contexts, rather than blindly adding security measures at all call points, improving security while avoiding unnecessary performance overhead.

[0068] Complex patterns such as recursive calls, callback functions, and polymorphism commonly found in modern software pose significant challenges to traditional static analysis. Context-sensitive analysis, by maintaining call stack information, can correctly handle recursion depth, callback chains, and polymorphic dispatch. For example, for recursive functions, different recursion depths are treated as different contexts, and the analyzer can track the state changes of data during the recursion process.

[0069] Step S4: Vulnerability assessment and report generation.

[0070] like Figure 5As shown, each circle represents a node, solid lines represent nodes in a contaminated state, and dashed lines represent nodes in a cleaned state. Only the data flow within the search box needs to be examined to determine the data flow path containing the vulnerability. The vulnerability determination process includes, based on the aforementioned forward tracing and marking the tainted states of variables in cleaned and contaminated states, traversing each data flow path that passes through the endpoint, and finding the data flow path containing the contaminated variable. Specifically, taking the endpoint, i.e., the vulnerability sink (i.e., the sensitive operation point of the command execution function), as the root node, in this embodiment, we can simply search its state to determine whether it passes through a safe node without tracing up the data flow path to the safe node, finding the data flow path that has not been processed by the cleaned function, and thus marking it as a command injection vulnerability. Since states have already been set for each variable to represent its clean or contaminated state, variables in a cleaned state can be directly filtered out, and the data flow path corresponding to the contaminated variable can be directly searched, thus saving a significant amount of logical judgment.

[0071] In some embodiments, the vulnerability determination in step S4 further includes introducing path sensitivity verification, using a constraint solver to solve the predicate conditions on the tainted flow path to eliminate logically unreachable false vulnerability paths. Its core purpose is to identify and eliminate those logically unexecutable false vulnerability paths, thereby significantly reducing the false positive rate.

[0072] During program execution, the actual data flow path is often constrained by various conditional branches. Traditional static analysis, when tracing tainted data, may find a data flow path from the taint source to the vulnerability sink, but this path may never be executed at runtime because certain conditions can never be met. For example, a path might require a variable to simultaneously satisfy the conditions of being greater than 10 and less than 5, which is logically impossible. Ignoring these constraints will generate a large number of false vulnerability reports, causing developers and security personnel to waste time reviewing security issues that do not exist at all.

[0073] To address this issue, path sensitivity verification is introduced into the vulnerability assessment process. Once the analyzer identifies a potential vulnerable path, it collects all relevant predicate conditions along that path, including logical expressions at branch points such as if statements, loop conditions, and assertions. Simultaneously, the analyzer records variable assignments and state changes along the path. All this information is combined into a complete logical constraint formula that expresses all the conditions required to execute this path.

[0074] Next, the analyzer calls the constraint solver to determine the satisfiability of this logical formula. The constraint solver uses mathematical and logical reasoning techniques to determine if there exists a set of variable assignments that simultaneously satisfies all constraints. If the solver determines that the formula is unsatisfiable—meaning no input allows the program to execute along this path—then this path is logically unreachable, and the corresponding vulnerability report is a false vulnerability, which can be safely removed from the final results. Conversely, if the formula is satisfiable, it means that the path may be executed at runtime, the vulnerability is real, and it should be retained and reported.

[0075] This mechanism significantly enhances the usability of static analysis tools. It not only reduces false positives, allowing security teams to focus more on real threats, but also improves the reliability of vulnerability reports. Furthermore, the introduction of constraint solvers enables the analysis tools to handle more complex program logic, including nonlinear constraints, array and string operations, thus adapting to the increasingly complex conditional judgments in modern software. Finally, path sensitivity verification advances static analysis from a simple syntactic level to a semantic level, achieving analysis results that more closely resemble real program behavior and providing a more robust guarantee for software security.

[0076] Vulnerability reports generated based on command injection vulnerabilities include the vulnerability location corresponding to the source code location, the data flow path from the start to the end of the analysis, and the vulnerability severity level. Specifically, the vulnerability location includes the filename and line number of the specific vulnerability location, allowing developers to quickly pinpoint the code where the vulnerability lies. The data flow path shows the specific path from the tainted source point to the vulnerability sink point, including all variables and function calls using tainted data, helping developers understand the root cause and scope of the vulnerability. The vulnerability severity level is configured using a declarative language through an external framework, based on the location of the analysis start point. Vulnerability severity levels include low, medium, and high, or similar tiered classification methods. The purpose of differentiating vulnerability severity levels is to distinguish the severity of different vulnerabilities, thereby helping developers prioritize more urgent vulnerabilities.

[0077] In some preferred embodiments, declarative filters are also included to set filtering for vulnerability reports, thereby displaying only vulnerability reports that meet the filtering criteria to developers; alternatively, software composition analysis tools (SCA tools) can be used, which are tools used to detect the security and compliance of open-source components in software. When the data flow path of a vulnerability passes through a third-party library with known vulnerabilities, the vulnerability severity level is increased, enhancing the accuracy and usability of the detection. Set operations can also be used to process multiple data flow analysis results or multiple vulnerability sets, including finding the intersection, difference, or union of sets, to optimize the analysis path or filter the detection results.

[0078] In some embodiments, the vulnerability level assessment process includes: The data flow paths obtained from vulnerability reports form a directed graph. These data flow paths are not processed by the cleanup function. The aforementioned data flow paths are presented as directed graphs, abstracting the relationships between data flows. Nodes represent data nodes in the program, such as variables, function parameters, and return values, while directed edges represent data flow directions, such as assignment, parameter passing, and return value passing. A directed graph containing vulnerabilities with the analysis endpoint as its root node is generated.

[0079] Based on this directed graph, we can perform betweenness centrality analysis to calculate the frequency with which each node appears in all shortest paths; high-frequency nodes are the critical nodes. According to engineering experience, injection vulnerabilities often repeatedly exploit a few specific channels. Betweenness centrality analysis can identify the nodes corresponding to these frequently occurring channels, helping engineers deploy appropriate measures at the appropriate nodes to eliminate the batch vulnerabilities associated with those channels.

[0080] Based on this directed graph, dominant node analysis can also be performed. In a control flow graph or data flow graph, if all paths from the analysis start point to the analysis end point pass through a certain node, then that node is a dominant node. By analyzing the dominant nodes of each combination consisting of several data flows, a group of dominant nodes can be obtained.

[0081] By combining the two analyses described above, the data flow corresponding to each vulnerability can be evaluated: a vulnerability path that passes through multiple high betweenness centrality nodes has a wider potential impact and should receive a higher risk score; an abnormal path that bypasses the dominant node may indicate the existence of an unconventional attack surface and requires special attention. Based on the aforementioned ideas, the injected vulnerability data flow is scored, thereby giving higher scores to vulnerabilities that should be prioritized and unconventional vulnerabilities, thus improving system stability.

[0082] Of course, the severity of an injection vulnerability is also related to the length of the data stream. The shorter the data stream path, the more dangerous it is. The length of the data stream in an injection vulnerability is also used to score the severity of the injection vulnerability.

[0083] In some embodiments, the generated report also includes vulnerability pattern evolution analysis: by counting the number of vulnerability data streams and combining them with betweenness centrality analysis, it can be observed whether key risk nodes are spreading or converging. When the number of risk nodes increases with the updates and iterations of the source code, and when the number of vulnerabilities that bypass the dominant node increases, it indicates that the reliability of the source code is gradually decreasing, and vice versa.

[0084] An apparatus for static detection of command injection vulnerabilities based on SSA-IR data flow tracing includes a processor and a memory, wherein the processor is configured to read instructions from the memory to execute the aforementioned method.

[0085] Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the apparatus for static detection of command injection vulnerabilities based on SSA-IR data stream tracing according to embodiments of the present invention. The present invention can also be implemented as a device or apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such programs implementing the present invention can be stored on a computer-readable medium or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0086] A Computer Program Product Implementation (“CPP Implementation” or “CPP”) is a term used in this disclosure to describe any set of one or more storage media (also referred to as “media”) collectively included in a set of one or more storage devices that collectively include machine-readable code corresponding to instructions and / or data for performing computer operations specified in a given CPP.

[0087] "Storage device" is any tangible device capable of retaining and storing instructions used by a computer processor. Without limitation, computer-readable storage media can be electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, mechanical storage media, or any suitable combination of the foregoing. Some known types of storage devices that include these media include: magnetic disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), optical disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punched cards or pits / ridges formed in the main surface of the disk), or any suitable combination of the foregoing.

[0088] As used herein, the term computer-readable storage medium should not be construed as storing transient signals in their own form, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, optical pulses through fiber optic cables, or electrical signals transmitted through wires and / or other transmission media. As those skilled in the art will understand, during normal operation of the storage device, such as during access, defragmentation, or garbage collection, data typically moves at some occasional points in time; however, this does not render the storage device transient, as the data is not transient when it is stored.

[0089] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any way. Other variations and modifications may be made without departing from the technical solutions described in the claims.

Claims

1. A static detection method for command injection vulnerabilities, characterized in that, Includes the following steps: S1. Parse the source code and generate a static single-assignment intermediate representation; S2. Locate the starting point, ending point, and safety node of the analysis; S3, Data flow tracing analysis within functions and data flow tracing analysis between functions; S4. Vulnerability assessment and report generation, the report including the vulnerability severity level; The severity level of a vulnerability is determined by: Find the data flow path corresponding to the injection vulnerability, which can be abstracted as a directed graph, where nodes represent data nodes in the program and directed edges represent the data flow direction; Betweenness centrality analysis and dominance node analysis are performed on the directed graph to obtain high-frequency nodes and dominance nodes; Injection vulnerabilities are scored based on the degree of similarity between their data flow paths and high-frequency nodes, as well as their deviation from the dominant node. The parsing of the source code in step S1 includes building an abstract syntax tree based on the source code through a compiler, converting the abstract syntax tree into a static single assignment intermediate representation through a converter, and forming a data flow path from the static single assignment intermediate representation. The data flow path includes the definition-use chain and the use-definition chain of variables.

2. The static detection method for command injection vulnerabilities according to claim 1, characterized in that, In step S2, the analysis start point, end point, and safety node are identified using an analysis location mechanism based on predefined symbols, method names, or knowledge bases. The analysis start point includes function call points or file read inputs from untrusted external inputs, the analysis end point includes function call points that execute system commands, and the safety node includes cleanup functions used to translate input characters.

3. The static detection method for command injection vulnerabilities according to claim 2, characterized in that, The predefined rules are described and configured using a declarative language.

4. The static detection method for command injection vulnerabilities according to claim 1, characterized in that, The data flow tracing analysis within the function in step S3 includes: marking variables starting from each analysis point as tainted states; performing data flow operations forward using the definition-use chain and the use-def chain to make each variable inherit the tainted state of the upstream variable; and triggering the audit function to mark the variable as tainted and stop tracing the variable when the traced variable is passed as a parameter to the cleansing function.

5. A static detection method for command injection vulnerabilities according to claim 4, characterized in that, Step S3 also includes: chaining calls to tainted data, recursively passing the tainted state of the tainted data to the final result of the chaining calls.

6. A static detection method for command injection vulnerabilities according to claim 1, characterized in that, The inter-function data flow tracing analysis in step S3 includes: constructing a function call graph based on the function call relationship represented by a static single assignment, traversing the function call graph, binding the actual parameters of the caller and the formal parameters of the callee at the function call boundary, and passing and merging the tainted state and cleansed state of the actual parameters to the initial state of the formal parameters of the callee.

7. A static detection method for command injection vulnerabilities according to claim 1, characterized in that, The vulnerability determination in step S4 involves traversing each data flow path rooted at the analysis endpoint to find data flow paths that have not been processed by the cleanup function, thereby marking them as command injection vulnerabilities.

8. A static detection method for command injection vulnerabilities according to claim 7, characterized in that, The vulnerability report generated based on the obtained command injection vulnerability includes the vulnerability location corresponding to the source code location and the data flow path from the start point of the analysis to the end point.

9. A static detection method for command injection vulnerabilities according to claim 8, characterized in that, This also includes setting filtering for vulnerability reports through declarative filters; or, in conjunction with Software Configuration Analysis (SCA) tools, increasing the vulnerability severity level when the vulnerability's data flow path passes through a known vulnerable third-party library.

10. A static detection method for command injection vulnerabilities according to claim 8, characterized in that, Before or after a vulnerability report is generated, a declarative filter can be used to screen the vulnerability detection results. Set operations can also be used to process multiple data stream analysis results or multiple vulnerability sets. The set operations include finding the intersection, difference, or union of sets to optimize the analysis path or screen the detection results.

11. A static detection method for command injection vulnerabilities according to claim 4, characterized in that, When a function call to native code is encountered during data flow tracing, the impact of the function call on the tainted state is simulated through the native extension mechanism to achieve cross-function data flow tracing.

12. A static detection method for command injection vulnerabilities according to claim 6, characterized in that, It also implements call context-sensitive analysis by maintaining call stack information to distinguish the data flow state when the same function is triggered at different call points.

13. A static detection method for command injection vulnerabilities according to claim 7, characterized in that, The vulnerability determination in step S4 also includes introducing path sensitivity verification, using a constraint solver to solve the predicate conditions on the tainted flow path to eliminate logically unreachable false vulnerability paths.

14. A static detection device for command injection vulnerabilities, comprising a processor and a memory, characterized in that, The processor is configured to read instructions from the memory to execute the method according to any one of claims 1 to 13.

Images