Dynamic fuzz testing and vulnerability detection method oriented to API (Application Program Interface)

Abstract

The invention discloses an API-oriented dynamic fuzz testing and vulnerability detection method, and belongs to the technical field of software security testing. The method comprises the following steps: extracting a dependency relationship, an input parameter, an output response and context state data of API calling, generating an initial API dependency graph, dynamically updating by capturing API state change in real time, forming an API state graph, and executing boundary-oriented variation based on parameter constraint characteristics, so as to obtain an API state graph; generating a variation test parameter, calling an API (Application Program Interface) of the variation test parameter to monitor a process memory behavior and response metadata, and generating a multi-dimensional abnormal signal; and performing mode matching on the abnormal signal and the vulnerability feature knowledge base, outputting a vulnerability type label and generating a path tracing report. According to the method, a context state sensing dynamic graph modeling technology is adopted, and a boundary-oriented intelligent variation strategy and multi-source abnormal behavior collaborative analysis are combined, so that precise vulnerability triggering, intelligent vulnerability judgment and complex scene coverage can be realized.

Description

Technical Field

[0001] This invention relates to the field of software security testing technology, and in particular to a dynamic fuzzing and vulnerability detection method for APIs. Background Technology

[0002] Application Programming Interfaces (APIs) serve as the core interaction channel in modern software systems, and their security directly impacts the stability of business systems. Fuzzing techniques targeting APIs, which inject unconventional inputs to trigger anomalous behavior, have become an important method for vulnerability detection. Existing technologies typically employ static API dependency modeling combined with random parameter mutation strategies, supplemented by system call monitoring, to achieve anomaly capture.

[0003] Current mainstream solutions rely on predefined API call sequence graphs, extracting input parameter structures through syntax parsing and generating random mutation data based on a pre-defined rule base. The anomaly detection layer deploys probes in the operating system kernel to capture system call sequences that deviate from a predefined behavioral baseline, using stack traces to pinpoint the anomaly source. Vulnerability determination then matches error codes or anomaly patterns against a pre-defined signature library.

[0004] The existing technology has three main drawbacks: static dependency graphs cannot detect runtime state changes, resulting in a large number of mutated parameters being invalid due to the lack of state constraints; system-level anomaly monitoring is disconnected from API business context, leading to a high false alarm rate; and vulnerability determination lacks a state consistency verification mechanism, making it difficult to distinguish between real vulnerabilities and environmental fluctuations. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides a dynamic fuzzing and vulnerability detection method for APIs. It employs context-aware dynamic graph modeling technology, combined with boundary-oriented intelligent mutation strategies and multi-source abnormal behavior collaborative analysis, enabling precise vulnerability triggering, intelligent vulnerability determination, and coverage of complex scenarios.

[0006] The above objectives can be achieved through the following approach: A dynamic fuzzing and vulnerability detection method for APIs includes extracting API call dependencies, input parameters, output responses, and context state data to generate an initial API dependency graph; dynamically updating the graph by capturing API state changes in real time to form an API state graph; performing boundary-guided mutation based on parameter constraint features in the graph to generate test parameters carrying boundary overflow and malformation structures; calling the mutated API and monitoring process memory behavior and response metadata to generate multi-dimensional anomaly signals; and performing pattern matching between the anomaly signals and a vulnerability feature knowledge base to output vulnerability type labels and generate a path tracing report.

[0007] Optionally, dynamically updating the initial API dependency graph to form an API state graph includes: parsing the state identifier field in the output response of the API call to obtain key state variables; associating the key state variables with the input parameters of the API call to obtain state-driven parameter constraint rules; adding dynamic state edges to the initial API dependency graph to obtain an enhanced state-aware dependency graph; and forming the API state graph based on the enhanced state-aware dependency graph and the state-driven parameter constraint rules.

[0008] Optionally, the step of associating the key state variables with the input parameters of the API call to obtain state-driven parameter constraint rules includes: performing state-space vectorization encoding on the key state variables to obtain a dynamic state encoding vector; obtaining a parameter permission feature matrix based on the input parameters of the API call; and associating the dynamic state encoding vector with the parameter permission feature matrix to obtain state-driven parameter constraint rules.

[0009] Optionally, the step of performing boundary-guided mutation on the input parameters of the API call based on the API state graph to generate mutation test parameters includes: receiving an anomaly triggering parameter identifier from the anomaly monitoring signal; enhancing the boundary value mutation density of the anomaly triggering parameter identifier to obtain a state-sensitive mutation density; weighting the state-sensitive mutation density with state relevance entropy values ​​based on the API state graph to obtain a dynamic mutation strategy vector; and performing boundary-guided mutation on the input parameters of the API call based on the dynamic mutation strategy vector to generate mutation test parameters.

[0010] Optionally, the step of calling the API carrying the mutation test parameters to generate an abnormal monitoring signal includes: intercepting the non-standard system call sequence and its parameter characteristics to obtain a capture event; calling the API with the mutation test parameters to obtain a snapshot of the target process's runtime environment state and the API endpoint identifier; and binding the capture event with the snapshot of the target process's runtime environment state and the API endpoint identifier to generate an abnormal monitoring signal.

[0011] Optionally, the interception of the unconventional system call sequence and its parameter characteristics to obtain the capture event includes: intercepting the unconventional system call sequence and its parameter characteristics to obtain behavioral baseline deviation data; and performing cross-layer context verification on the behavioral baseline deviation data to obtain the capture event.

[0012] Optionally, the step of matching the abnormal monitoring signal with a preset vulnerability feature knowledge base to determine the security vulnerability type and generate a vulnerability report includes: extracting the abnormal type feature code from the abnormal monitoring signal, combining it with the context state data associated with the API to generate a multi-dimensional abnormal feature vector; querying the abnormal pattern-vulnerability type mapping table recorded in the vulnerability feature knowledge base based on the multi-dimensional abnormal feature vector to obtain a set of candidate vulnerabilities with weighted probabilities; and performing state consistency verification on the context state data associated with the API based on the set of candidate vulnerabilities with weighted probabilities to determine the security vulnerability type and generate a vulnerability report.

[0013] Optionally, the step of performing state consistency verification on the context state data associated with the API based on the weighted probability candidate vulnerability set, determining the security vulnerability type, and generating a vulnerability report includes: performing state condition topology deconstruction on the weighted probability candidate vulnerability set to obtain a vulnerability state constraint subgraph set; extracting runtime state snapshots and their spatiotemporal location features based on the context state data associated with the API to obtain a state spatiotemporal fingerprint vector; and performing two-factor consistency verification on the vulnerability state constraint subgraph set and the state spatiotemporal fingerprint vector to determine the security vulnerability type and generate a vulnerability report.

[0014] Optionally, the step of performing boundary-guided mutation on the input parameters of the API call based on the dynamic mutation strategy vector to generate mutation test parameters includes: performing mutation operator assignment and boundary offset mapping operations on the dynamic mutation strategy vector to obtain a parameter boundary extension domain; and performing boundary-guided mutation on the input parameters of the API call based on the parameter boundary extension domain to generate mutation test parameters.

[0015] Based on the same inventive concept, this invention also provides a dynamic fuzzing and vulnerability detection system for APIs. The system includes: an API dependency graph construction module, used to extract the dependencies, input parameters, output responses, and associated context state data of API calls to generate an initial API dependency graph; a dynamic graph update module, used to dynamically update the initial API dependency graph to form an API state graph; a boundary-guided mutation module, used to perform boundary-guided mutation on the input parameters of the API calls based on the API state graph to generate mutation test parameters; an abnormal behavior monitoring module, used to call APIs carrying the mutation test parameters to generate abnormal monitoring signals; and a vulnerability intelligent determination module, used to match the abnormal monitoring signals with a preset vulnerability feature knowledge base to determine the type of security vulnerability and generate a vulnerability report.

[0016] Compared with the prior art, the present invention has the following advantages: By constructing a dynamically updated API state graph, state variables are deeply bound to parameter constraint rules, enabling the input variation process of fuzzing to have context awareness capabilities, and significantly improving the accuracy of boundary testing.

[0017] By employing a boundary-oriented mutation strategy and a state entropy weighting mechanism, high-risk parameters and critical state paths are dynamically focused, significantly reducing the number of invalid test cases and optimizing the efficiency of test resource allocation.

[0018] A cross-layer anomaly monitoring system is established, binding system call sequence anomalies to API context state in time and space to effectively filter environmental noise interference and enhance the reliability of vulnerability signal identification. Fourth, a two-factor vulnerability verification mechanism based on state-space fingerprint vectors eliminates misjudgments caused by occasional system anomalies, ensuring that vulnerability reports have high credibility and traceability.

[0019] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating an API-oriented dynamic fuzzing and vulnerability detection method according to an embodiment of the present invention.

[0022] Figure 2 This is a path entropy field modeling diagram according to an embodiment of the present invention.

[0023] Figure 3 This is an extended diagram of the mutation strategy parameters in an embodiment of the present invention.

[0024] Figure 4 This is a baseline monitoring graph of system call behavior in an embodiment of the present invention.

[0025] Figure 5 This is an abnormal feature vector matching matrix diagram according to an embodiment of the present invention.

[0026] Figure 6 This is a boundary-guided variation diagram of an embodiment of the present invention.

[0027] Figure 7This is a schematic diagram of the structure of an API-oriented dynamic fuzzing and vulnerability detection system according to an embodiment of the present invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0029] Reference Figure 1 One embodiment of the present invention proposes a dynamic fuzzing and vulnerability detection method for APIs. It adopts context-aware dynamic graph modeling technology, combined with boundary-oriented intelligent mutation strategy and multi-source abnormal behavior collaborative analysis, which can achieve accurate vulnerability triggering, intelligent vulnerability judgment and complex scenario coverage.

[0030] The method described in this embodiment specifically includes: Extract the dependencies, input parameters, output responses, and context state data associated with the API calls to generate an initial API dependency graph; The initial API dependency graph is dynamically updated to form an API state graph; Based on the API state graph, boundary-guided mutation is performed on the input parameters of the API call to generate mutation test parameters; Call the API carrying the mutation test parameters to generate an anomaly monitoring signal; Based on the abnormal monitoring signals, the system matches them with a preset vulnerability feature knowledge base to determine the type of security vulnerability and generate a vulnerability report.

[0031] Specifically, firstly, a data acquisition probe component is implanted into the target application interface's runtime process. By intercepting network packets or hooking application interface call library functions, the API call request and response data streams are completely captured. The captured raw traffic is then parsed to identify the input parameter key-value pairs, output response data bodies, and transport layer session identifiers. Next, the call chain structure is reconstructed based on the application interface call timing trajectory. First, the association between adjacent call nodes is established. When the request parameters of interface A contain the session token field returned by interface C, node A is determined to depend on node C. Second, implicit call dependencies are identified. When an interface submission operation triggers a system state change value X, the interface needs to verify the validity of state X when accessing state-related resources, thus determining that a dependency exists. The node dependency direction is marked as a directed edge and stored. Next, snapshot data of the system runtime environment during application interface execution is monitored, including but not limited to the content of the session state storage pool, memory allocation records, and database temporary table lock states. Using microsecond-level timestamps as indexes, a precise spatiotemporal binding relationship is established between this environment state snapshot and the application interface call endpoint identifier.

[0032] Finally, initialize the directed graph data structure. Create application interface endpoints as graph nodes, with node attributes containing input parameter metadata features and output response templates; create directed edges between nodes to represent dependencies, with edge attributes carrying state constraint expressions; and attach a snapshot fingerprint digest of the associated context state to each node. The final output structure is the initial API dependency graph.

[0033] Optionally, dynamically updating the initial API dependency graph to form an API state graph includes: The status identifier field in the output response of the API call is parsed to obtain key status variables; By associating the key state variables with the input parameters of the API call, state-driven parameter constraint rules are obtained; Add dynamic state edges to the initial API dependency graph to obtain an enhanced state-aware dependency graph; Based on the enhanced state-aware dependency graph and combined with the state-driven parameter constraint rules, an API state graph is formed.

[0034] Specifically, firstly, the status identifier field is extracted from the API call's output response. This field contains status information, such as HTTP status codes or specific key-value pairs in the returned data. Its value is identified using a parsing function to obtain key status variables, which represent the status information generated after the current API operation. Next, the key status variables are transformed using state-space vectorization encoding. This involves using an encoding model to process categorical or numerical status data, outputting a one-dimensional dynamic status encoding vector, where each dimension represents a feature of the status variable. Simultaneously, feature extraction is performed on the API call's input parameters to generate a parameter permission feature matrix. This matrix is ​​two-dimensional, with rows corresponding to each input parameter and columns containing features such as the parameter's numerical range and type. Then, the dynamic status encoding vector and the parameter permission feature matrix are correlated. Vector-matrix multiplication is used to calculate the correlation value, which is then normalized to a constraint probability value. The formula is: , That is, the constraint probability value, a vector. This represents a dynamic state encoding vector, obtained by processing key state variables through an encoding model. Represents the transpose of a matrix; The parameter permission feature matrix is ​​obtained by extracting features from the input parameters (e.g., using min-max normalization to scale the parameter values ​​to the [0,1] interval). Representing vectors The paradigm; Representation matrix The paradigm is used; after the multiplication result is normalized and computed using the paradigm, a set of state-driven parameter constraint rules is generated. Subsequently, the initial API dependency graph structure is expanded, where nodes represent API endpoints and their dependencies, and edges represent the call order. Dynamic state edges are added to connect state variable nodes to input parameter nodes, forming an enhanced state-aware dependency graph. Finally, the state-driven parameter constraint rules are integrated into this graph, for example, by storing the rules as edge weights or additional attributes, thus completing the construction of the API state graph.

[0035] For example, in a real API testing environment, suppose the goal is to detect a user login API ( Its output response includes a status identifier field, such as... Parse this field to extract key state variables. (Assigned value) )and (Assigned the value "abc123"); Through state-space vectorization encoding, discrete values ​​are mapped to dynamic state encoding vectors, for example [ The code 0.9 indicates the strength of the success status. Additionally, the input parameters for the API call include... and After extracting features, a parameter permission feature matrix is ​​generated, such as [ Features: Type string length range 5-15, Features: Type string range length 8-20]. Then, associated vectors and matrices are used to calculate similarity scores and output state-driven parameter constraints as rules, such as: input... The length constraint must be satisfied upon successful state completion. This is then present in the initial API dependency graph. Nodes and their dependencies, adding dynamic state edges to connect state variables Node to Input Nodes, with a weight set to 0.8, form an enhanced state-aware dependency graph; finally, the rule set is integrated to form an API state graph. This state graph is then used by the boundary-guided mutation module to generate mutation test parameters.

[0036] Optionally, the association of the key state variables with the input parameters of the API call to obtain state-driven parameter constraint rules includes: The key state variables are state-space vectorized to obtain dynamic state encoding vectors; Based on the input parameters of the API call, a parameter permission feature matrix is ​​obtained; By associating the dynamic state encoding vector with the parameter permission feature matrix, state-driven parameter constraint rules are obtained.

[0037] Specifically, key state variables are parsed from the status identifier fields in the API call output response. This involves scanning the response data format, identifying predefined status marker field names, extracting corresponding field values, and then performing data normalization, including filtering invalid characters and null values, retaining numerical values ​​or character sequences reflecting core system state changes as key state variables. Key state variables refer to system state indicators that directly affect subsequent API behavior, such as session token validity or resource access permission levels. State-space vectorization encoding is performed on the key state variables, using one-hot encoding or numerical normalization to map discrete state values ​​into mathematical vectors with dimensions equal to the total number of state categories, resulting in a dynamic state encoding vector. The dimension of this vector is determined by the actual number of system state types. Parameter description features are extracted from the API call input parameter set, including parameter data type definitions, boundary value ranges, and permission level labels, constructing a parameter permission feature matrix with rows equal to the number of parameters and columns equal to the feature dimension. Association operations are implemented through mathematical operations, specifically multiplying the dynamic state encoding vector by the parameter permission feature matrix to calculate the state-driven parameter constraint rules, the formula of which is: , in This represents a dynamic state encoding vector, generated from state variables using a standardized encoder. The parameter permission feature matrix is ​​generated by the parameter metadata parser. The output is a set of state-driven parameter constraint rules in the form of a real number matrix, where each element represents the legal range of parameter values ​​or the strength of operation permissions under a specific state.

[0038] For example, in a bank transfer API system, the withdrawal operation API output response parses out the key state variable "account balance status", which is then converted into a dynamic state encoding vector through one-hot encoding. When the account balance is sufficient, =[1,0]; when the balance is insufficient =[0,1]. Transfer amount input parameter Feature extraction revealed that the parameter's value ranged from 0 to 10000 yuan, indicating a highly sensitive permission level. A parameter permission feature matrix was constructed. =[[0.9,0.6]] (The first column represents the weight of the value range, and the second column represents the sensitivity weight). Constraint rules are generated using the correlation formula: When the balance is sufficient... =[0.9,0.6] indicates that high-amount transfers are allowed; if the balance is insufficient... =[0,0] forms a zero-permission constraint. This rule is embedded into the API state graph to achieve dynamic control over transfer parameters due to state changes.

[0039] Optionally, the step of performing boundary-guided mutation on the input parameters of the API call based on the API state graph to generate mutation test parameters includes: Receive the abnormal trigger parameter identifier from the abnormal monitoring signal; The boundary value variation density of the anomaly triggering parameter identifier is enhanced to obtain the state-sensitive variation density; Based on the API state map, the state-sensitive mutation density is weighted by the state correlation entropy value to obtain the dynamic mutation strategy vector. Based on the dynamic mutation strategy vector, boundary-guided mutation is performed on the input parameters of the API call to generate mutation test parameters.

[0040] Specifically, the mutation strategy parameter expansion is shown in the figure. It receives an anomaly trigger parameter identifier field extracted from the anomaly monitoring signal. This field records the name and location information of the input parameter that caused the system anomaly, obtained by parsing the anomaly source field marked in the signal data packet. Based on this identifier, the input parameter field of the target application interface is located, and a boundary value mutation density enhancement operation is performed, increasing the base mutation intensity by a factor of [missing information]. Increasing the value from the default value of 1 to 2 to 3 times yields the state-sensitive mutation density. Among them, the basic variation intensity multiple. The system pre-sets a boost when a parameter is marked as an anomaly trigger. Based on a pre-built application interface state graph, which includes connection strength data between state nodes and the probability distribution of state transition paths, a state entropy field modeling operation is performed on the graph, calculating the Shannon entropy value for each state node. The calculation formula is: , in This represents the total number of next states reachable from the current state, obtained by counting the frequency of each state transition in the historical application interface call records; This indicates a transition from the current state to the [nth state]. The probability of the next state is obtained by normalizing the frequency data. Simultaneously, path association analysis is performed to calculate the cumulative entropy along the path from the initial state to the current state. Path entropy field modeling, such as Figure 2 As shown. This incorporates the centrality weights of the state nodes. The dynamic entropy field weight model is constructed by calculating the connectivity ratio of nodes in the graph using graph theory algorithms. , in and The preset weighting coefficients are set to values ​​of 0.6 and 0.4 respectively. (Use...) State-sensitive variation density Perform entropy-weighted calculations to obtain the dynamic mutation strategy vector. : , The constant 1 is used to avoid zero-weight scenarios. Finally, according to Value-based boundary-guided mutation: For numerical input parameters, at the original boundary... Interval Value expansion variation range to , This is the boundary tolerance baseline value; for character parameters, it is based on... The test data is generated by doubling the string length limit, and the set of mutation test parameters is output. The mutation strategy parameters are expanded as follows: Figure 3 As shown.

[0041] For example, when testing the shopping cart checkout interface of an e-commerce platform, the historical monitoring signal display parameters... This triggers a numerical underflow exception. Base variation strength factor Increasing from 1 to 3.0 yields the state-sensitive variation density. =3.0. In the current application interface state graph, the settlement node has three reachable next states. Historical call statistics show that the state transition probability distribution is 0.6 to the product selection state, 0.3 to the payment processing state, and 0.1 to the order completion state. Calculate the entropy value. =-(0.6× +0.3× +0.1× The cumulative path entropy from the initial product selection state to the settlement state is approximately 1.295. =2.8, the centrality weight of this node =0.9, thus obtaining the dynamic entropy field weight. =0.6×2.8+0.4×0.9=2.04. Calculate the dynamic mutation strategy vector. =3.0×(1+2.04)=9.12. Based on this strategy: the original boundary of the amount parameter [-100, 10000] is expanded to [-100-9.12×2000, 10000+9.12×2000]=[-18340, 28240] to generate an out-of-bounds test value; the upper limit of the product name field length is increased from 50 characters... The value was doubled to 456 characters, generating an excessively long string. When the input price value was -18000 yuan, an integer underflow vulnerability was triggered, precisely exposing the flaw in the money calculation.

[0042] Optionally, the step of calling the API carrying the mutation test parameters to generate anomaly monitoring signals includes: Intercepting unconventional system call sequences and their parameter characteristics yields captured events; Call the API of the mutation test parameters to obtain a snapshot of the target process's runtime environment state and API endpoint identifier; The captured event is bound to the runtime environment state snapshot and API endpoint identifier of the target process to generate an abnormal monitoring signal.

[0043] Specifically, baseline monitoring of system call behavior, such as Figure 4 As shown, during the execution of API calls carrying mutation test parameters, a monitoring component deployed at the operating system kernel layer intercepts the system call sequence in real time. This monitoring component is implemented using extended Berkeley packet filtering technology, with a detection program mounted at the system call entry point. An abnormal system call sequence is defined to meet two conditions simultaneously: the system call type code does not appear in the top 95% of historical normal call frequency statistics, or the parameter value exceeds three standard deviations of a predefined security boundary threshold. Interception of operation calls. Register to obtain system call type identifier Analysis The original parameter values ​​stored in the register are used to generate a decimal parameter feature vector. Read The register records the integer value of the error status as the return value signature. . System call feature vector (through splicing) (Construct) Input a pre-trained behavioral baseline model, and the model outputs a behavioral baseline bias score. The calculation formula is: , in The mean vector of the baseline model is generated by calculating the mean through statistical historical calls to feature vectors. Let be the vector magnitude. When When the threshold is >0.85 (determined on the validation set using the receiver operation characteristic curve), immediately acquire a snapshot of the target process's runtime environment state: calculate the MD5 hash of the thread stack data, copy the environment variable set, and scan the memory allocation table to record the number of uninitialized pointers. Simultaneously, record the API endpoint identifier (the unique named identifier of the called interface). Calculate the system call timestamp. With status snapshot collection timestamp Absolute time difference: , when In milliseconds (preset clock synchronization tolerance threshold), the captured event feature triplet, environment state snapshot, and API endpoint identifier are bound and encapsulated to generate a structured anomaly monitoring signal.

[0044] For example, when testing the user file deletion interface, a mutated test parameter is injected, setting the filename field to a malicious path. The monitoring component captures system calls at the kernel level. (Type identification number T=87), parameters The path string length feature value is 38 (exceeding three times the safety threshold of 25 standard deviations). The baseline model calculates the bias score. =0.91. Synchronously obtain runtime environment state snapshot: thread stack MD5 hash value Environment variables display current permissions An illegal pointer address was detected in the memory. Timestamp verification confirmed. Milliseconds. Binding to generate exception monitoring signals: Record system call types. (87), Parameter characteristic value 38, Return code -13 (Permission error), Associated interface identifier The system stores environment variable sets and memory fingerprints. This signal triggered the vulnerability assessment process, confirming a path traversal vulnerability, demonstrating that an attacker could access sensitive system files through unauthorized parameters.

[0045] Optionally, the interception of the unconventional system call sequence and its parameter characteristics to obtain the captured event includes: By intercepting unconventional system call sequences and their parameter characteristics, behavioral baseline deviation data can be obtained. Cross-layer context verification is performed on the behavioral baseline deviation data to obtain the captured event.

[0046] Specifically, during API calls carrying mutation test parameters, a monitoring component deployed at the operating system kernel level intercepts system call requests in real time. This component employs extended Berkeley packet filtering technology to intercept unusual system call sequences that meet either of the following conditions: the call type does not appear in the historical high-frequency call set, or the parameter feature value exceeds three standard deviations of a preset legal parameter range. Triple features are extracted for each call event: , System call type number The raw encoded value is obtained by querying the system call mapping table in the operating system kernel header file; parameter feature vector. This is generated by reading the raw hexadecimal data from the register and converting it into a decimal numerical array; the return value is a feature code. Record the integer values ​​of the error codes returned by system calls. Input the triples into a pre-trained deep neural network anomaly detector (training data contains millions of normal call records), and output the behavior bias score. .like (threshold) (determined through the receiver operation characteristic curve in the validation set), then the cross-layer verification mechanism is initiated: real-time snapshot of the API runtime context state is collected. It includes the MD5 hash of the thread call stack, a copy of the environment variables, and the fingerprint of the memory allocation table; it calculates the timestamp of the system call. With status acquisition timestamp The absolute difference: , when When the clock synchronization tolerance threshold is reached, the spatiotemporal correlation is determined to be valid, and a captured event entity is generated. Finally, this event is correlated with the mutation parameters. API endpoint identifier Context snapshot Encapsulated as a structured anomaly monitoring signal.

[0047] For example, when testing the user permission modification interface, a mutated parameter is injected to change the target user's role field to a system administrator identifier. This triggers a user group management call during system execution. The monitoring component detected the call type. =116 is not included in the historical baseline high-frequency set. Parameter vector If the value contains an unauthorized administrator ID encoding, an error code will be returned. =−1 indicates no permission to operate. The anomaly detection model outputs a deviation score. =0.94. Simultaneously, the context acquisition probe captures a state snapshot. The current thread has a normal user privilege level, and an abnormal jump instruction address was detected in memory. Timestamp verification confirmed. When the microsecond is less than the threshold, after generating the capture event, bind signal elements: record the system call type and parameter characteristic values, associate the interface identifier, and save the state snapshot memory fingerprint. This stores the malicious role identifier in the mutation parameters. This signal triggers a vulnerability rule base search, accurately identifying it as a high-risk vertical privilege escalation vulnerability.

[0048] Optionally, the step of matching the abnormal monitoring signal with a preset vulnerability feature knowledge base to determine the type of security vulnerability and generate a vulnerability report includes: Extract the anomaly type feature code from the anomaly monitoring signal, and combine it with the context state data associated with the API to generate a multi-dimensional anomaly feature vector; Based on the multi-dimensional anomaly feature vector, query the anomaly pattern-vulnerability type mapping table recorded in the vulnerability feature knowledge base to obtain a set of candidate vulnerabilities with weighted probabilities. Based on the weighted probability candidate vulnerability set, the context state data associated with the API is verified for consistency, the security vulnerability type is determined, and a vulnerability report is generated.

[0049] Specifically, the anomaly feature vector matching matrix is ​​as follows: Figure 5 As shown, anomaly type feature codes are extracted from abnormal monitoring signals. These feature codes are obtained by quantizing system call feature triples. Specifically, the system call type number T is converted into an integer type code, the parameter feature vector P is formed by combining the standard deviation and mean of each parameter value, and the return value feature code R retains its original integer value. Simultaneously, the context state data packet associated with the API is obtained, including the thread execution stack MD5 hash value converted into a 64-bit integer feature item, the environment variable set generated into a bitmap feature vector through a Bloom filter, and numerical indicators such as the number of uninitialized pointers and stack offset extracted from the memory pool state. After normalizing these feature items, they are concatenated according to a fixed dimension to form a multi-dimensional anomaly feature vector. Perform vector similarity matching calculation in the anomaly pattern-vulnerability type mapping table of the preset vulnerability feature knowledge base: in For the currently generated multi-dimensional anomaly feature vector, For the predefined abnormal pattern feature vectors in the knowledge base, express The length of the mold, express The similarity S exceeds a set threshold of 0.75. When the similarity S exceeds this threshold, the vulnerability type is included in the candidate vulnerability set. The similarity value is then transformed using the Softmax function to obtain the weighted probability. Then, state consistency verification is performed: the state constraint vector corresponding to each vulnerability type is parsed from the candidate vulnerability set. (Predefined in the knowledge base), runtime state vector parsed from the current context state data. Perform inner product calculation for consistency score : , They represent The modulus length will be used to assign weighted probabilities to each candidate vulnerability. With consistency score The scores are multiplied to obtain the final score, and the vulnerability type corresponding to the highest score is selected to generate a report. The report includes the vulnerability type name, triggering parameters, and a chain of evidence to verify state consistency.

[0050] For example, when testing the payment interface of an e-commerce website, injecting mutated parameters containing SQL metacharacters triggered an exception event. The system call characteristics were extracted from the exception monitoring signals: Encoding for database connection calls, This indicates the discrete characteristics of abnormal parameter values. Record SQL syntax error codes. Context state data parsing: thread stack hash conversion feature value 0x89ab, environment variable bitmap vector [1,0,1,1], memory state containing 3 uninitialized pointers. Construct a multi-dimensional anomaly feature vector [0.42,0.12,3.45,1064,0.89,1,0.8,3]. Query the vulnerability knowledge base and match the SQL injection vulnerability pattern vector [0.41,0.11,3.5,1064,0.88,1,0.7, 3], with a similarity score of 0.92; the buffer overflow vulnerability matching score is 0.65. After forming a candidate set, perform state verification: the dot product of the current runtime state vector [1,0.8,3] and the SQL injection state constraint vector [1,0.8,3] yields a consistency score of 0.99, and the weighted score of 0.92 × 0.99 = 0.9108 is significantly higher than other candidates. The vulnerability report was ultimately generated and identified as an SQL injection vulnerability, recording the characteristics of the triggering parameters and evidence of the memory state.

[0051] Optionally, the step of verifying the consistency of the context state data associated with the API based on the weighted probability candidate vulnerability set, determining the security vulnerability type, and generating a vulnerability report includes: The state condition topology of the weighted probability candidate vulnerability set is deconstructed to obtain a vulnerability state constraint subgraph set; Based on the context state data associated with the API, a runtime state snapshot and its spatiotemporal positioning features are extracted to obtain a state spatiotemporal fingerprint vector. The vulnerability state constraint subgraph and the state spatiotemporal fingerprint vector are subjected to two-factor consistency verification to determine the security vulnerability type and generate a vulnerability report.

[0052] Specifically, a state condition topology deconstruction operation is performed on the candidate vulnerability set, which contains vulnerability type identifiers and corresponding weight probability values. State constraint graphs for each vulnerability type are retrieved from a pre-defined vulnerability feature knowledge base. This graph is a directed graph data structure, where nodes represent state constraints (e.g., resource lock status is true or memory address range is limited), and edges represent logical dependencies between conditions. A depth-first search algorithm is used to traverse the strongly connected components of the constraint graph, generating a vulnerability state constraint subgraph set. Simultaneously, based on API runtime context state data, a state snapshot sequence within a fixed time window is extracted: the cyclic redundancy check (CRC) code of the thread execution stack is collected as a spatial location feature, and the Coordinated Universal Time (UTC) timestamp generated from the state snapshot and the processor's cycle counter value constitute the temporal location feature. The spatial features are mapped to 64-bit integers using a hash function, and the temporal features are converted to relative time offsets after millisecond-level timestamp alignment, concatenating them to form a state spatiotemporal fingerprint vector. A two-factor consistency verification is performed: the first factor is the node matching degree calculation, which verifies whether the spatial features in the state spatiotemporal fingerprint vector satisfy the state conditions defined by the nodes in the vulnerability state constraint subgraph. The matching degree calculation formula is: , in This indicates the number of fingerprint vectors that satisfy the conditions of the constraint subgraph nodes. The total number of nodes in the constrained subgraph. The second factor is the temporal relationship compliance calculation, with the formula: , in The absolute value of the maximum allowable delay difference defined between the state snapshot time offset and the edge of the constraint subgraph. This is the time decay constant (default value is 1000 milliseconds). Final consistency score. Obtained through factor product: , when If the vulnerability type is determined to be consistent with the state evidence, the highest-scoring vulnerability type is selected to generate a vulnerability report containing state constraint compliance evidence.

[0053] For example, when detecting a file upload interface, the candidate vulnerability set includes an XXE injection vulnerability (weight 0.85) and a path traversal vulnerability (weight 0.72). The topology deconstruction operation retrieves the knowledge base: the XXE vulnerability constraint subgraph contains 3 state nodes (XML parser flag is true, external entity reference permission status is true, file system read / write permissions are false). A runtime state snapshot captures the spatial feature CRC=0xA83D, with a timestamp sequence [0ms, 12ms, 25ms]. A state spatiotemporal fingerprint vector is constructed [0xA83D, 0, 12, 25]. First factor calculation: the vector space feature verifies that the XML parser flag is true (constraint node 1), the entity reference status is true (node ​​2), and the file permissions are false (node ​​3). Second factor calculation: The maximum time delay difference defined by the constraint subgraph edge is 8 milliseconds, and the actual time offset is |12-0|=12 milliseconds. =4 milliseconds, . Consistency score The path traversal vulnerability was verified. The vulnerability was ultimately identified as an XXE injection vulnerability. The report included state matching evidence: XML parsing state flag address 0x7F2B and timestamp sequence calibration records.

[0054] Optionally, the step of performing boundary-guided mutation on the input parameters of the API call based on the dynamic mutation strategy vector to generate mutation test parameters includes: The dynamic mutation strategy vector is subjected to mutation operator assignment and boundary offset mapping operations to obtain the parameter boundary extension domain; Based on the parameter boundary extension domain, boundary-guided mutation is performed on the input parameters of the API call to generate mutation test parameters.

[0055] Specifically, boundary-oriented mutations such as Figure 6As shown, the dynamic mutation strategy vector is a numerical vector output after entropy weighting. The dimension of this vector equals the number of input parameters from the application programming interface (API), and each element represents the strength of the mutation strategy for the corresponding parameter. This vector is obtained by weighting the state relevance entropy values, where the element values ​​are selected based on the parameter type definition to select the mutation rule generator. The parameter type is defined as a pre-parsed parameter metadata tag, including numerical parameters representing input parameters with continuous value ranges, and character parameters representing text string input parameters. A mutation operator allocation operation is performed, that is, assigning corresponding mutation rule generator modules to different parameter types: boundary value mutation operators are selected for numerical parameters, and this module generates numerical range mutation data; length-oriented mutation operators are selected for character parameters, and this module generates string length mutation data. The mutation rule generator is a predefined function module of the system, and each module specifies the mutation logic for a specific parameter type. A boundary offset mapping operation is performed to convert the element values ​​of the dynamic mutation strategy vector into parameter boundary extension domains, implemented using a mapping function, the formula of which is: , in It represents the parameter boundary extension domain, which is a scalar or vector, with the dimension corresponding to the number of input parameters, reflecting the boundary offset of each parameter; The element values ​​of the corresponding parameters in the dynamic mutation strategy vector are obtained through entropy weighting. This represents the boundary tolerance baseline value. The system presets a fixed constant; for numerical parameters, this is set to a numerical unit baseline (e.g., 2000 units), and for character parameters, it's set to a character length baseline (e.g., 50 units). Boundary-guided mutation is performed based on the parameter boundary extension domain, meaning the mutation range is expanded from the original valid boundaries of the input parameters. For numerical parameters, the new lower limit for boundary-guided mutation calculation is the original minimum boundary value minus... The new upper limit is the original maximum boundary value plus... Then, test values ​​are generated by randomly sampling in the new interval; for character parameters, the boundary-guided mutation calculation calculates the new upper limit of the length as the original maximum character length plus... It generates a sequence of test strings of equal or variable length based on the character type; finally, it gathers all mutation results to form a set of mutation test parameters and outputs them to the subsequent application interface call module.

[0056] For example, when testing the file deletion application interface, the input parameters include filename length (character type, original maximum length 100 characters) and file size threshold (numeric type, original boundary [0, 5000] units). Assume the filename parameter element values ​​in the dynamic mutation strategy vector are... =2.5, file size parameter element value =1.8; System preset character-type boundary tolerance baseline value =20 units, numerical boundary tolerance baseline value =1000 units. Perform boundary offset mapping operation to calculate the parameter boundary extension domain of the filename. =2.5 × 20 = 50 characters, file size parameter bounding field. =1.8 × 1000 = 1800 units. Based on this, a boundary-guided mutation is performed, expanding the original maximum filename length of 100 characters to 100 + 50 = 150 characters, generating a test string of length 150 characters. For example, a malicious path sequence with an original file size boundary [0, 5000] units is expanded to [0-1800, 5000 + 1800] = [-1800, 6800] units, generating test values ​​-1500 and 6500. After injecting this mutation test parameter, calling the file deletion interface triggers an unauthorized access vulnerability, confirming the method's effectiveness in detecting path traversal defects.

[0057] Based on the same inventive concept, such as Figure 7 As shown, the present invention also provides a dynamic fuzzing and vulnerability detection system for APIs, the system comprising: The API dependency graph building module is used to extract the dependencies, input parameters, output responses, and context state data associated with API calls to generate an initial API dependency graph. The dynamic graph update module is used to dynamically update the initial API dependency graph to form an API state graph. The boundary-guided mutation module is used to perform boundary-guided mutation on the input parameters of the API call based on the API state graph, and generate mutation test parameters; The abnormal behavior monitoring module is used to call the API carrying the mutation test parameters to generate abnormal monitoring signals; The vulnerability intelligent determination module is used to match the abnormal monitoring signals with a preset vulnerability feature knowledge base to determine the type of security vulnerability and generate a vulnerability report.

[0058] It should be noted that the electrical connections between the various units described above do not necessarily represent direct or indirect connections. Any indirect connection method can be applied to the embodiments of the present invention as long as it achieves the purpose of the present invention. The above descriptions are merely exemplary embodiments of the present invention and should not be construed as limiting the scope of the present invention.

[0059] All equivalent changes and modifications made in accordance with the teachings of this invention are still within the scope of this invention. Those skilled in the art will readily conceive of other embodiments of this invention upon considering the specification and the disclosure of practical truth. This application is intended to cover any variations, uses, or adaptations of this invention that follow the general principles of this invention and include common knowledge or conventional techniques in the art not described herein.

Claims

1. A dynamic fuzzing and vulnerability detection method for APIs, characterized in that, The method includes: Extract the dependencies, input parameters, output responses, and context state data associated with the API calls to generate an initial API dependency graph; The initial API dependency graph is dynamically updated to form an API state graph; Based on the API state graph, boundary-guided mutation is performed on the input parameters of the API call to generate mutation test parameters; Call the API carrying the mutation test parameters to generate an anomaly monitoring signal; Based on the abnormal monitoring signals, the system matches them with a preset vulnerability feature knowledge base to determine the type of security vulnerability and generate a vulnerability report.

2. The dynamic fuzzing and vulnerability detection method for APIs according to claim 1, characterized in that, The step of dynamically updating the initial API dependency graph to form an API state graph includes: The status identifier field in the output response of the API call is parsed to obtain key status variables; By associating the key state variables with the input parameters of the API call, state-driven parameter constraint rules are obtained; Add dynamic state edges to the initial API dependency graph to obtain an enhanced state-aware dependency graph; Based on the enhanced state-aware dependency graph and combined with the state-driven parameter constraint rules, an API state graph is formed.

3. The dynamic fuzzing and vulnerability detection method for APIs according to claim 2, characterized in that, The association between the key state variables and the input parameters of the API call to obtain state-driven parameter constraint rules includes: The key state variables are state-space vectorized to obtain dynamic state encoding vectors; Based on the input parameters of the API call, a parameter permission feature matrix is ​​obtained; By associating the dynamic state encoding vector with the parameter permission feature matrix, state-driven parameter constraint rules are obtained.

4. The dynamic fuzzing and vulnerability detection method for APIs according to claim 1, characterized in that, The step of performing boundary-guided mutation on the input parameters of the API call based on the API state graph to generate mutation test parameters includes: Receive the abnormal trigger parameter identifier from the abnormal monitoring signal; The boundary value variation density of the anomaly triggering parameter identifier is enhanced to obtain the state-sensitive variation density; Based on the API state map, the state-sensitive mutation density is weighted by the state correlation entropy value to obtain the dynamic mutation strategy vector. Based on the dynamic mutation strategy vector, boundary-guided mutation is performed on the input parameters of the API call to generate mutation test parameters.

5. The dynamic fuzzing and vulnerability detection method for APIs according to claim 1, characterized in that, The step of calling the API carrying the mutation test parameters to generate anomaly monitoring signals includes: Intercepting unconventional system call sequences and their parameter characteristics yields captured events; Call the API of the mutation test parameters to obtain a snapshot of the target process's runtime environment state and API endpoint identifier; The captured event is bound to the runtime environment state snapshot and API endpoint identifier of the target process to generate an abnormal monitoring signal.

6. The dynamic fuzzing and vulnerability detection method for APIs according to claim 5, characterized in that, The interception of unconventional system call sequences and their parameter characteristics yields the following captured events: By intercepting unconventional system call sequences and their parameter characteristics, behavioral baseline deviation data can be obtained. Cross-layer context verification is performed on the behavioral baseline deviation data to obtain the captured event.

7. The dynamic fuzzing and vulnerability detection method for APIs according to claim 1, characterized in that, The step of matching the abnormal monitoring signal with a preset vulnerability feature knowledge base to determine the type of security vulnerability and generate a vulnerability report includes: Extract the anomaly type feature code from the anomaly monitoring signal, and combine it with the context state data associated with the API to generate a multi-dimensional anomaly feature vector; Based on the multi-dimensional anomaly feature vector, query the anomaly pattern-vulnerability type mapping table recorded in the vulnerability feature knowledge base to obtain a set of candidate vulnerabilities with weighted probabilities. Based on the weighted probability candidate vulnerability set, the context state data associated with the API is verified for consistency, the security vulnerability type is determined, and a vulnerability report is generated.

8. The dynamic fuzzing and vulnerability detection method for APIs according to claim 7, characterized in that, The process of verifying the consistency of the context state data associated with the API based on the weighted probability candidate vulnerability set, determining the security vulnerability type, and generating a vulnerability report includes: The state condition topology of the weighted probability candidate vulnerability set is deconstructed to obtain a vulnerability state constraint subgraph set; Based on the context state data associated with the API, a runtime state snapshot and its spatiotemporal positioning features are extracted to obtain a state spatiotemporal fingerprint vector. The vulnerability state constraint subgraph and the state spatiotemporal fingerprint vector are subjected to two-factor consistency verification to determine the security vulnerability type and generate a vulnerability report.

9. The dynamic fuzzing and vulnerability detection method for APIs according to claim 4, characterized in that, The step of performing boundary-guided mutation on the input parameters of the API call based on the dynamic mutation strategy vector to generate mutation test parameters includes: The dynamic mutation strategy vector is subjected to mutation operator assignment and boundary offset mapping operations to obtain the parameter boundary extension domain; Based on the parameter boundary extension domain, boundary-guided mutation is performed on the input parameters of the API call to generate mutation test parameters.

10. An API-oriented dynamic fuzzing and vulnerability detection system, applied to the API-oriented dynamic fuzzing and vulnerability detection method as described in any one of claims 1-9, characterized in that, The system includes: The API dependency graph building module is used to extract the dependencies, input parameters, output responses, and context state data associated with API calls to generate an initial API dependency graph. The dynamic graph update module is used to dynamically update the initial API dependency graph to form an API state graph. The boundary-guided mutation module is used to perform boundary-guided mutation on the input parameters of the API call based on the API state graph, and generate mutation test parameters; The abnormal behavior monitoring module is used to call the API carrying the mutation test parameters to generate abnormal monitoring signals; The vulnerability intelligent determination module is used to match the abnormal monitoring signals with a preset vulnerability feature knowledge base to determine the type of security vulnerability and generate a vulnerability report.

Images