REST API context construction method based on multilevel associated data analysis in public cloud network

Abstract

The invention provides a REST API context construction method based on multilevel associated data analysis in a public cloud network, and belongs to the technical field of computer security. The method comprises the following steps: analyzing an OpenAPI specification document to obtain tree structured data, constructing a dependency edge according to a tree node parameter type, initializing an edge weight according to API interface names to which two nodes connected with the dependency edge belong and parameter names of the nodes, and updating the weight of the dependency edge based on a description attribute of the nodes to obtain a static directed weighted API dependency graph; based on the dependency graph, an exploration request sequence is established for each API, then requests in the sequences are sent in an inverted order, corresponding dependency edge weights are updated according to preorder request responses, and the accurate directed weighted dependency graph is obtained. The API dependency graph generated by the method can guide the fuzzy test stage to effectively generate the API request sequence, the API request is effectively prevented from being filtered or the tested service is prevented from being thrown abnormally, and the code coverage rate, the fuzzy test efficiency and the vulnerability discovery capability of the fuzzy test in the public cloud network are effectively improved.

Description

Technical Field

[0001] This invention relates to the field of computer security, and in particular to a method and system for constructing REST API contexts based on multi-level relational data analysis in public cloud networks. Background Technology

[0002] In recent years, with the rapid development of multimodal network environments in public cloud networks, fuzz testing has gained widespread attention in public cloud network security. Currently, many network services in public cloud networks adopt intelligent cross-domain resource sharing methods. This resource-oriented design decouples modules from different services, greatly facilitating later system functional expansion and module maintenance. In this resource-oriented design architecture, standardized unified interface APIs based on the REST architecture are typically used for interaction. This information or representation is transmitted via HTTP in one of the following formats: JSON (Javascript Object Markup), HTML, XLT, Python, PHP, or plain text. To determine whether vulnerabilities exist in the service under test corresponding to the REST API, researchers often use fuzz testing techniques to send requests for testing. Many original vulnerabilities are relatively simple and can be detected by sending requests to the service under test using the REST API specification combined with a concise mutation strategy.

[0003] As multimodal public cloud network resources become increasingly abundant, code logic becomes more complex, and vulnerabilities hidden within them become more difficult to discover. Triggering such complex vulnerabilities typically requires sending multiple specific API requests consecutively, and the parameters in these requests must meet specific constraints. Current fuzzing methods for REST APIs often employ a black-box strategy, deriving test cases from the API specification. However, API specifications cannot adequately describe the dependencies between APIs and between API parameters. Furthermore, in real-world scenarios, parameter dependencies are often complex and widespread, making it difficult for existing black-box fuzzing methods to generate test cases that satisfy all constraints between input parameters, resulting in low testing efficiency. Many existing methods (such as RESTler and RESTTESTGEN) attempt to construct state graphs during request sending to describe the potential dependencies between APIs and dynamically adjust the state graph based on the responses to the requests. In addition, many works employ attribute-based testing methods, such as QuickREST and RESTest, to automatically parse the specification and obtain the dependencies between parameters. In summary, the key challenge of black-box testing in multimodal public cloud networks lies in how to parse an accurate API dependency graph from the API specification, ensuring that the graph contains rich and accurate data dependencies. Current specification parsing methods are not accurate enough, and the dependencies in the diagram have a large number of false positives, resulting in low code coverage. Correspondingly, it is also difficult to find vulnerabilities in complex scenarios. Summary of the Invention

[0004] To overcome the shortcomings of existing fuzzing techniques in multimodal public cloud networks, this invention proposes a REST API context construction method based on multi-level relational data analysis in public cloud networks. This method constructs an accurate directed weighted dependency graph between APIs, thereby generating vulnerability detection sequences based on the dependency graph during fuzzing to improve code coverage and the probability of vulnerability discovery.

[0005] The technical solution of the present invention is as follows: A method for constructing a REST API context based on multi-level relational data analysis in a public cloud network, characterized by the following steps: Step 1: Obtain the OpenAPI specification document used by the public cloud network service under test to describe the REST API, and verify whether the document conforms to the RESTAPI standard. For compliant specification documents, use the code library to read the OpenAPI specification document and parse it into structured data of dictionary type in memory. For non-compliant documents, stop the process directly. Step 2: Read the structured data of the OpenAPI specification information in memory, build a tree structure for each API, represent each field in the API request and response as a node in the tree, and add the field information as an attribute to the node; then initialize a dependency graph between the established tree structure APIs, at which point there is no dependency relationship between nodes of different APIs; Step 3: Obtain historical packets of the public cloud network service under test, parse the request and response data of the historical packets, and obtain the parameter values ​​carried by each API when it is successfully sent in the OpenAPI specification document; compare whether the data type attributes of the nodes in the API dependency graph obtained in Step 2 are consistent with the data type of the corresponding parameters in the historical packets; compare whether the optional attributes of the nodes in the API dependency graph obtained in Step 2 are consistent with the carrying situation of the corresponding parameters in the historical packets; if there is any inconsistency, correct the corresponding attributes of the nodes. Step 4: Traverse each node in the API dependency graph, read its data type attribute, and bind the nodes according to the read data type attribute. Add a directed dependency edge between request nodes and response nodes that belong to different APIs but have the same data type attribute, which means that the response node value connected by the tail of the arrow is reused by the request node connected by the head of the arrow. Step 5: Traverse all dependency edges in the API dependency graph and obtain the parameter name attributes of the nodes connected to both ends of the edge. Use a semantic similarity comparison method to vectorize the interface name and parameter name, and use cosine similarity to measure the semantic proximity between the parameter names at both ends of the dependency edge. After standardization, use it as the initial weight of the dependency edge. If the nodes connected to both ends of the dependency edge also have a description attribute, use entity disambiguation to understand the actual meaning of the description attribute of the parameters at both ends of the dependency edge in the tested public cloud network service. If the two meanings are similar, increase the weight of the dependency edge. If the actual meanings of the two are unrelated, decrease the weight of the dependency edge. If the correlation between the two cannot be determined, keep the original weight unchanged. At this point, a static directed weighted API dependency graph is obtained. Step 6: Dynamic Verification Phase; First, generate an exploration request sequence for each target API based on the static directed weighted API dependency graph: Initialize an empty request sequence, select a target API to add to the request sequence, analyze the parameter dependency of the target API in the static directed weighted API dependency graph, and randomly select an API connected by a dependency edge with a weight greater than a set threshold x as its predecessor API and add it to the request sequence according to the weight of the dependency edge in the graph. Then analyze the parameter dependency of the predecessor API again, and recursively repeat this process until the set sequence length limit N is reached or there are no dependencies. When encountering a circular dependency, move the API that appears repeatedly in the loop to the end of the sequence to prevent an infinite loop. Next, the requests in the sequence are sent in reverse order, and according to the dependency relationship indicated in the dependency graph, the value of the successful response node of the preceding API is used to assign the value of the parameter node of the subsequent API. If the preceding API request fails, the historical message data is used to assign the parameter value of the subsequent API. In step 6, after assigning the value of the successful response node of the preceding API to the parameter node of the following API, if the following request is sent successfully, it is considered that the corresponding dependency relationship exists, that is, the weight of the corresponding dependency edge is increased; if the following request fails to be sent, it is considered that the dependency relationship has not been verified, and the weight of the corresponding dependency edge is reduced. Step 6, after dynamic verification of the API dependency graph, adjusts the weights of each dependency edge based on the response during dynamic execution. At this point, an accurate directed weighted API dependency graph is obtained.

[0006] Furthermore, in step 1, when parsing the OpenAPI specification document, if there is a reference to a custom structure name in the OpenAPI specification document, the corresponding custom structure is written back to the referenced location.

[0007] Furthermore, the field information in step 2 includes the API route to which the parameter belongs, the parameter name, the parameter description, the parameter type, and whether it is optional.

[0008] Furthermore, the data types of the nodes in step 4 include basic data types and custom structure types.

[0009] Furthermore, the entity disambiguation method in step 5 is based on analyzing the OpenAPI specification for public cloud network resource services and understanding the writing pattern of the description field. Specifically, it involves loading a language model using a natural language processing toolkit, then extracting entity features from the description attribute field of the nodes at both ends of the dependency edge, including part-of-speech, modification relations, belonging components, and subordinate relations. A comparative analysis is then performed on the two sentences, including generating two grammatical dependency graphs and inputting them into a graph neural network. The contextual relationships of the nodes in the grammatical dependency graphs are extracted and the results are presented as two vectors. Finally, a multilayer perceptron is used to determine the probability that the two vectors belong to the same entity in the current public cloud network service being tested. A hyperparameter c is set to represent the critical threshold for the two to belong to the same entity. When the probability is greater than c, the two nodes are considered to belong to the same entity; when the probability is less than or equal to c, the two nodes are considered to belong to different entities.

[0010] The beneficial effects of this invention are: This invention provides a method for constructing REST API contexts in public cloud networks based on multi-level relational data analysis. It parses the OpenAPI specification document to obtain tree-structured data, constructs dependency edges based on the basic data types of tree node parameters and custom structure types, assigns initial weights to the dependency edges using cosine similarity based on the API interface names of the two nodes connected by the dependency edges and the parameter name attributes of the nodes, and then updates the weights of the dependency edges between nodes using entity disambiguation based on the node description attribute, resulting in a static directed weighted API dependency graph. Based on the static directed weighted API dependency graph, an exploration request sequence is established for each API; then, requests in the sequence are sent in reverse order, prioritizing the use of data from the responses of previous requests to assign values ​​to the parameters of the current request; if the previous request fails, historical message data is used to assign values ​​to the parameters of the current request; finally, the weights of the corresponding dependency edges are updated based on the response of the current request, thus obtaining an accurate directed weighted dependency graph. This invention, based on multi-level relational data analysis and combined with the resource-oriented characteristics of REST APIs in multimodal cloud networks, obtains accurate dependency relationships between APIs. Based on the dependencies between APIs, API request sequences can be effectively generated during the fuzzing phase, avoiding requests being filtered or exceptions being thrown by the service under test, thereby improving code coverage, fuzzing efficiency, and vulnerability discovery capabilities in public cloud networks. Attached Figure Description

[0011] Figure 1 This is a flowchart of the REST API context construction method based on multi-level relational data analysis according to the present invention.

[0012] Figure 2 This is a system architecture diagram of the REST API context construction method based on multi-level relational data analysis of the present invention.

[0013] Figure 3 This is a tree structure diagram of the original API specification information given in an embodiment of the present invention.

[0014] Figure 4 This is an initialization API dependency graph provided in an embodiment of the present invention.

[0015] Figure 5 This is a static API directed weighted dependency graph provided in an embodiment of the present invention.

[0016] Figure 6 This is an example diagram illustrating the establishment of an exploration request sequence for a target API, as provided in an embodiment of the present invention. Detailed Implementation

[0017] The following detailed implementation process, in conjunction with the above-mentioned accompanying drawings, further describes the present invention through embodiments, but does not limit the scope of the present invention in any way.

[0018] This embodiment provides a method and system for constructing REST API contexts based on multi-level relational data analysis in a public cloud network.

[0019] The flowchart of the method of the present invention is as follows Figure 1 As shown, the main implementation process includes the following detailed steps: Step 1: Obtain the OpenAPI specification document used by the public cloud service under test to describe the REST API. Typically, this OpenAPI specification document needs to conform to the Swagger 1.0 / 2.0 or OpenAPI 3.0 standard. These documents are usually in JSON or YAML format. This embodiment uses the prance library to verify whether the specification document conforms to the REST API standard. For specification documents that do not conform to the RAST API standard, the process stops immediately, and subsequent steps are not performed; for specification documents that conform to the RAST API standard, subsequent steps continue. Next, the openapi-spec-validator codebase is used to read the OpenAPI specification and parse it into structured data. At this point, the API specification information exists in memory as a dictionary. Since the OpenAPI specification document usually contains a "$ref" field indicating the name of the referenced custom struct, after parsing the OpenAPI specification document, the custom struct corresponding to the "$ref" reference needs to be written back to the referenced location.

[0020] Step 2: Read the structured data of the OpenAPI specification information in memory, and build a tree structure for each API. Each field in the API structured data represents a node in the tree, and the field information is added as an attribute to the node, such as the API route to which the parameter belongs, the parameter name, the parameter description, the parameter type, whether it is optional, etc. The basic data types of parameters typically include six types: integer, string, number, boolean, object, and array. Figure 3As shown in the diagram, this is the tree structure of the API / upload-order interface, including two nodes: Request and Response. The Request node includes two nodes: Parameter and Body. The Parameter node includes Authorization and id nodes, corresponding to string and integer parameter fields respectively. The Body node includes price and goods nodes, corresponding to integer and a custom structure GoodsDTO parameter field respectively. The goods node includes name, size, and color nodes, corresponding to string, integer, and string parameter fields respectively. The Response node of the API / upload-order interface includes id, price, and goods nodes, representing integer, integer, and a custom structure GoodsDTO response field respectively. After building the API tree, a dependency graph between APIs is initialized. At this point, the dependency graph already contains basic information about the APIs, their request parameters, and response fields, but there are currently no dependencies between different API nodes. Figure 4 As shown.

[0021] Step 3: In actual production environments, public cloud network services are updated frequently while OpenAPI specification documents are released less frequently. This inconsistency can lead to inaccurate descriptions of APIs in the OpenAPI specification documents, resulting in errors in context construction. To improve robustness, this invention obtains historical messages from public cloud network services, parses the request and response data in these messages, and obtains the parameter values ​​carried by each API when successfully sent in the OpenAPI specification documents. It compares the data type attributes of nodes in the API dependency graph obtained in Step 2 with the data types of corresponding parameter values ​​in the successful historical messages. If they are inconsistent, the data type attributes of nodes in the API tree and API dependency graph are updated using the corresponding parameter data types from the historical messages. Furthermore, it compares the optional attributes of nodes in the API dependency graph obtained in Step 2 with the carrying status of corresponding parameters in the successful historical messages. If a node's optional attribute is False (meaning the parameter must be carried in the request but is not carried in the historical messages), the node's optional attribute is changed to True.

[0022] In an embodiment, such as Figure 3As shown, in the API / update-order tree structure established according to the OpenAPI specification document, the data type attribute of the node id is integer. However, it is easy to see from the historical messages that the data type of the parameter id in the latest public cloud network tested service is string. Therefore, the data type attribute of the updated id node is string.

[0023] Step 4: Parameters of the same type may be reused across different APIs. For example, an integer field value in the response body of API A might be successfully reused as an integer parameter in the request body of API B. Compared to random mutation, this reuse relationship is more likely to yield a valid parameter. This invention associates and binds nodes based on the data type attributes of the nodes in the API dependency graph. A directed dependency edge is added between request and response nodes belonging to different APIs but with the same data type attribute, representing that the response node value connected by the arrow tail can be reused by the parameter node connected by the arrow head.

[0024] In the corresponding embodiments, such as Figure 5 As shown, Figure 5 This diagram illustrates the dependency graph between five APIs: / get-order-price, / get-order-color, / get-all-orders, / update-order, and / get-order-goods. Dashed boxes within each API represent parameter nodes, solid boxes represent response nodes, and directed solid lines between nodes represent dependencies. Taking the string type dependency in the diagram as an example, considering that the data type attribute of the response node `order_id` in API / get-all-orders is string, while the data type attributes of the parameter nodes `id` and `color` in API / update-order are also string, dependency edges are added from the `order_id` node in API / get-all-orders to the `id` and `color` nodes in API / update-order, respectively.

[0025] Beyond basic data types, OpenAPI extensively includes custom parameter types. These custom structs are referenced via "$ref" and exhibit strong specificity, allowing dependency edges to be built between nodes with the same custom struct data type attribute. Based on actual usage of public cloud network tested services, these highly specific parameters tend to have a higher probability of reuse. Therefore, all nodes in the API dependency graph can be traversed to read their data type attributes. For request and response nodes referencing the same custom struct via "$ref" between different APIs, a dependency edge can be added between them, further refining the API dependency graph.

[0026] In this embodiment, as Figure 5 As shown, the custom structure GoodsDTO is referenced in the response node of API / get-order-goods and also in the parameter node of API / update-order. Therefore, a dependency edge can be added from the response node of API / get-order-goods to the corresponding parameter node of API / update-order.

[0027] Step 5: Traverse all dependency edges in the API dependency graph and obtain the parameter name attributes of the nodes connected to both ends of the edge. Generally speaking, the more similar the parameter names of the two nodes connected by a dependency edge, the greater the probability of successfully reusing the dependency value. This invention uses the natural language processing tool Word2Vec to vectorize the API interface name to which the node belongs and the parameter name of the node, and uses the cosine similarity method implemented based on the sklearn.metrics library to measure the semantic proximity between the nodes at both ends of the dependency edge, and uses the standardized proximity value as the initial weight of the dependency edge. For nodes with high proximity, the initial weight of the dependency edge is also high, indicating a high probability of reuse; for nodes with low proximity, the initial weight of the dependency edge is also low, indicating a low probability of reuse. In this embodiment, as shown... Figure 5 As shown, the order_id node of / get-all-orders is more adjacent to the id node of / update-order, with an initial weight of 0.8, while the order_id node of / get-all-orders is less adjacent to the color node of / update-order, with an initial weight of 0.5.

[0028] Some nodes in the API tree have a description attribute, which is usually optional in the OpenAPI specification. If both ends of a dependency edge have a description attribute, entity disambiguation is used to understand the meaning of the description attribute of the parameters at both ends of the dependency edge in the tested public cloud service. If the meanings are similar, the weight of the dependency edge is increased; if the meanings are unrelated, the weight of the dependency edge is decreased; if the relevance cannot be determined, the weight remains unchanged. Specifically, the entity disambiguation method first uses the spaCy library to load the language model, and then extracts entity features from the description attribute of the nodes at both ends of the dependency edge, including parts of speech, modification relationships, belonging components, and subordination relationships. The two sentences are compared and analyzed, including generating two grammatical dependency graphs for the two sentences and inputting them into a graph neural network. The contextual relationships of the nodes in the grammatical dependency graphs are extracted and the results are presented as two vectors. Finally, a multilayer perceptron is used to determine the probability that the two vectors belong to the same entity in the current public cloud network service being tested. The hyperparameter c is set to represent the critical threshold that the two belong to the same entity. When the probability is greater than c, the two nodes are considered to belong to the same entity; when the probability is less than or equal to c, the two nodes are considered to belong to different entities. The parameter names of two sentences belonging to different entities may be similar, but the description statements can distinguish the two. Further, the entity disambiguation process consists of the following steps: (1) Loading the language model using the spaCy code library; (2) Using spaCy to further divide the two description statements into two lists composed of tokens; (3) For each token, it is initialized as a node. The node has many attributes, including the original text, lexicon, part of speech, whether it is a stop word, whether it is a number, whether it is a punctuation mark, etc. (4) Analyze the head attribute of each node. The head attribute represents the parent node of the node. Then add an edge from the current node to its parent node. (5) Analyze the dep attribute of each node. Extract the relationship between each node and its parent node and label it on the edge. Common relationships include nsubj, dobj, ROOT, det, amod, prep, attr, aux, etc. (6) Steps (3)-(5) are applied to a single token list. Therefore, two syntactic dependency graphs will be obtained after completion. Input the two syntactic dependency graphs into a graph neural network built based on the torch_geometric.nn.GCNConv library. Extract the node context relationship in the syntactic dependency graph and present the result as two vectors. (7) Input the two vectors into a three-layer multilayer perceptron and use the LeakyReLU activation function in it. Finally, normalize the result to obtain the probability that the two nodes belong to the same entity.(8) Compare the probability with the hyperparameter c. When the probability is greater than c, the two nodes are considered to belong to the same entity; when the probability is less than or equal to c, the two nodes are considered to belong to different entities.

[0029] In this embodiment, as Figure 5 As shown, the meaning of the order_id node and the description attribute of the id node both represent the order number, and they have the same physical meaning, that is, to increase the weight of the dependent edge, such as from 0.8 to 0.85; the descriptions of order_id and color are the order number and the product color, respectively, and they have different physical meanings, that is, to decrease the weight of the dependent edge from 0.5 to 0.45.

[0030] At this point, a static directed weighted API dependency graph is obtained, such as Figure 5 As shown.

[0031] Step 6: In the dynamic verification phase, based on the static directed weighted API dependency graph, each API is explored iteratively, specifically as follows: Establish an exploration request sequence for the target API. First, initialize an empty request sequence. Select a target API and add it to the request sequence. Analyze the parameter dependencies of the target API in the static directed weighted API dependency graph. Based on the weights of the dependency edges in the graph, randomly select an API connected by a dependency edge whose weight is greater than a set threshold x as its predecessor API and add it to the request sequence. Then, analyze the parameter dependencies of this predecessor API. Recursively repeat this process until the set sequence length limit N is reached or no parameter dependencies exist. If a circular dependency occurs during the recursion, move the APIs that appear repeatedly in the circular dependency to the end of the sequence. For example, if during the exploration, API A depends on API B, API B depends on API C, and API C depends on API A, then move API A to the end of the current request sequence to prevent an infinite loop.

[0032] In this embodiment, as Figure 5As shown, taking the target API / update-order as an example, one process for generating an exploration request sequence is as follows: the parameter node 'goods' of the / update-order interface depends on the response node 'goods' of the / get-order-goods interface; the parameter node 'price' depends on the response node 'price' of the / get-order-price interface; the parameter node 'id' depends on the response node 'order_id' of the / get-all-orders interface; the parameter node 'order_id' of the / get-order-goods interface depends on the response node 'order_id' of the / get-all-orders interface; the parameter node 'order_id' of the / get-order-price interface depends on the response node 'order_id' of the / get-all-orders interface; and the / get-all-orders interface has no parameter dependencies. The final sequence is as follows: (I) / update-order; (II) / get-order-goods; (III) / get-order-price; (Ⅳ) / get-all-orders.

[0033] After generating a request sequence for the target API, the requests in the sequence are sent in reverse order. Following the dependencies indicated in the dependency graph, the response nodes of the preceding APIs are used to assign values ​​to the parameter nodes of the subsequent APIs. Specifically: API requests in the sequence are sent in reverse order. If the preceding API was sent successfully (response code 2XX), the values ​​of the response nodes of the preceding APIs are used to assign values ​​to the corresponding parameter nodes of the subsequent APIs, according to the dependencies indicated in the dependency graph. If the preceding API failed to send (response code 4XX or 5XX), data from historical messages is used to assign values ​​to the corresponding parameters of the subsequent APIs, ensuring that the exploration can continue. For example... Figure 6As shown, first, the ` / get-all-orders` interface is sent, and according to the dependency, the `order_id` in the ` / get-all-orders` response value is used to assign the values ​​of the `order_id` parameter of the ` / get-order-goods` interface, the `order_id` parameter of the ` / get-order-price` interface, and the `id` parameter of the ` / update-order` interface. Then, the ` / get-order-price` interface is sent, and according to the dependency, the `price` in the ` / get-order-price` response value is used to assign the value of the `price` parameter of the ` / update-order` interface. Next, the ` / get-order-goods` interface is sent, and according to the dependency, the `goods` in the ` / get-order-goods` response value is used to assign the value of the `goods` parameter of the ` / update-order` interface. Finally, the ` / update-order` interface is sent.

[0034] The weights in the dependency graph are dynamically updated during the sending of the request sequence. Specifically: if the value of the response node of the preceding API is assigned to the parameter node of the following API, and the following API is sent successfully (response code 2XX), then the dependency relationship is considered to be highly likely, so the weight of the corresponding dependency edge is increased; conversely, if the following API fails to be sent (response code 4XX or 5XX), then the dependency relationship is considered to be less likely, so the weight of the corresponding dependency edge is decreased.

[0035] After step 6, the API dependency graph has been dynamically verified, and the weights of each dependency edge have been adjusted based on the response during the dynamic execution process, resulting in an accurate directed weighted API dependency graph.

[0036] The above steps illustrate an implementation process of a REST API context construction method based on multi-level relational data analysis.

[0037] A context building system for the method of this invention is implemented using the Python language, such as... Figure 2 As shown, it includes: environment installation module, specification preprocessing module, dependency graph initialization module, static weight adjustment module, and dynamic verification module.

[0038] The environment installation module is responsible for providing necessary code library dependencies for other modules, providing interfaces such as specification document parsing, network requests, and model calls to support the code's runtime environment. The specification preprocessing module is responsible for reading and parsing the OpenAPI documentation, structuring the document data, building the API tree structure, collecting historical messages, and correcting inconsistencies with the OpenAPI specification document based on historical messages. The dependency graph initialization module constructs an initial API dependency graph based on the data type attributes of the parameters and generates initial directed edges. The static weight adjustment module includes adjusting weights based on the API interface name to which the node belongs and the parameter name attribute of the node using cosine similarity, and adjusting weights based on the node description attribute using entity disambiguation. The dynamic verification module generates an exploration request sequence for each target API based on the static directed weighted API dependency graph, sends the requests in the sequence in reverse order, assigns values ​​to the request parameters according to the dependency relationships indicated in the dependency graph, and finally further adjusts the weight information of the dependency edges based on the request response.

[0039] By constructing a system based on the method of this invention, various performance experiments were conducted. Regarding interface coverage experiments, this invention was compared with common tools such as RESTler and RESTTESTGEN. The tested services were three large REST API projects: GitLab, VAmPI, and rbaskets. The interface coverage test results are shown in Table 1.

[0040] Table 1 Interface Coverage Test Results As shown in the table above, the dependency graph-guided fuzzy testing method obtained by this invention based on multi-level association data analysis achieved a high detection rate. On the GitLab project, the interface coverage of this invention is approximately 10% to 20% higher than the comparison tools. On the VAmPI and rbaskets projects, the interface coverage obtained by this invention is significantly higher than or equal to that of the comparison tools.

[0041] In terms of real-world functional testing, fuzz testing guided by this invention reproduced 9 CVE vulnerabilities and discovered 6 new undisclosed CVE vulnerabilities. A detailed list of CVEs is shown in Table 2.

[0042] Table 2 Real-world test results It should be noted that the purpose of disclosing the embodiments is to help further understand the present invention. However, those skilled in the art will understand that various substitutions and modifications are possible without departing from the spirit and scope of the present invention and the appended claims. Therefore, the present invention should not be limited to the content disclosed in the embodiments, and the scope of protection of the present invention is defined by the scope of the claims.

Claims

1. A method for constructing a REST API context based on multi-level relational data analysis in a public cloud network, characterized in that, Includes the following steps: Step 1: Obtain the OpenAPI specification document used by the public cloud network service under test to describe the REST API, and verify whether the document conforms to the REST API standard. For compliant specification documents, use the code library to read the OpenAPI specification document and parse it into structured data of dictionary type in memory. For non-compliant documents, stop the process directly. Step 2: Read the structured data of the OpenAPI specification information in memory, build a tree structure for each API, represent each field in the API request and response as a node in the tree, and add the field information as an attribute to the node; then initialize a dependency graph between the established tree structure APIs, at which point there is no dependency relationship between nodes of different APIs; Step 3: Obtain historical packets of the public cloud network service under test, parse the request and response data of the historical packets, and obtain the parameter values ​​carried by each API when it is successfully sent in the OpenAPI specification document; compare whether the data type attributes of the nodes in the API dependency graph obtained in Step 2 are consistent with the data type of the corresponding parameters in the historical packets; compare whether the optional attributes of the nodes in the API dependency graph obtained in Step 2 are consistent with the carrying situation of the corresponding parameters in the historical packets; if there is any inconsistency, correct the corresponding attributes of the nodes. Step 4: Traverse each node in the API dependency graph, read its data type attribute, and bind the nodes according to the read data type attribute. Add a directed dependency edge between request nodes and response nodes that belong to different APIs but have the same data type attribute, which means that the response node value connected by the tail of the arrow is reused by the request node connected by the head of the arrow. Step 5: Traverse all dependency edges in the API dependency graph and obtain the parameter name attributes of the nodes connected at both ends of the edge. Use the semantic similarity comparison method to vectorize the interface name and parameter name and use cosine similarity to measure the semantic proximity between the parameter names at both ends of the dependency edge. After standardization, use it as the initial weight of the dependency edge. If both ends of a dependency edge have a description attribute, the entity disambiguation method is used to understand the actual meaning of the description attribute of the parameters at both ends of the dependency edge in the public cloud service under test. If the two meanings are similar, the weight of the dependency edge is increased on the original basis. If the two meanings are unrelated, the weight of the dependency edge is decreased on the original basis. If the correlation between the two cannot be determined, the original weight is maintained. At this time, a static directed weighted API dependency graph is obtained. Step 6: Dynamic Verification Phase First, an exploration request sequence is generated for each target API based on a static directed weighted API dependency graph: an empty request sequence is initialized, a target API is selected and added to the request sequence, the parameter dependency of the target API in the static directed weighted API dependency graph is analyzed, and according to the weight of the dependency edge in the graph, an API connected by a dependency edge with a weight greater than a set threshold x is randomly selected as its predecessor API and added to the request sequence. Then, the parameter dependency of the predecessor API is analyzed again, and this process is recursively repeated until the set sequence length limit N is reached or there are no dependencies. When a circular dependency is encountered, the API that appears repeatedly in the loop is moved to the end of the sequence to prevent an infinite loop. Next, the requests in the sequence are sent in reverse order, and according to the dependency relationship indicated in the dependency graph, the value of the successful response node of the preceding API is used to assign the value of the parameter node of the subsequent API. If the preceding API request fails, the historical message data is used to assign the parameter value of the subsequent API. In step 6, after assigning the value of the successful response node of the preceding API to the parameter node of the following API, if the following request is sent successfully, it is considered that the corresponding dependency relationship exists, that is, the weight of the corresponding dependency edge is increased; if the following request fails to be sent, it is considered that the dependency relationship has not been verified, and the weight of the corresponding dependency edge is reduced. Step 6, after dynamic verification of the API dependency graph, adjusts the weights of each dependency edge based on the response during dynamic execution. At this point, an accurate directed weighted API dependency graph is obtained.

2. The method as described in claim 1, characterized in that, In step 1, the OpenAPI specification document is parsed. When there is a reference to a custom structure name in the OpenAPI specification document, the corresponding custom structure is written back to the referenced location.

3. The method as described in claim 1, characterized in that, The field information in step 2 includes the API route to which the parameter belongs, the parameter name, the parameter description, the parameter type, and whether it is optional.

4. The method as described in claim 1, characterized in that, The data types of the nodes in step 4 include basic data types and custom structure types.

5. The method as described in claim 1, characterized in that, The entity disambiguation method in step 5 is based on analyzing the OpenAPI specification for public cloud network resource services and understanding the writing pattern of the description field. Specifically, it involves loading a language model using a natural language processing tool library, then extracting entity features from the description attribute field of the nodes at both ends of the dependency edge, including part-of-speech, modification relations, belonging components, and subordinate relations. A comparative analysis is then performed on the two sentences, including generating two grammatical dependency graphs and inputting them into a graph neural network. The contextual relationships of the nodes in the grammatical dependency graphs are extracted and the results are presented as two vectors. Finally, a multilayer perceptron is used to determine the probability that the two vectors belong to the same entity in the current public cloud network service being tested. A hyperparameter c is set to represent the critical threshold for the two to belong to the same entity. When the probability is greater than c, the two nodes are considered to belong to the same entity; when the probability is less than or equal to c, the two nodes are considered to belong to different entities.

Images