Security vulnerability detection system based on API (Application Program Interface)

Abstract

The invention provides a security vulnerability detection system based on an API interface, and relates to the technical field of security vulnerability detection.The system firstly analyzes the API interface through an analysis module to obtain calling information, and then analyzes calling of the API interface through a static analysis module and a dynamic analysis module to obtain calling information; according to the method, a calling graph capable of representing calling relations among different APIs is generated, a detection queue is generated according to the calling graph, and test parameters of the APIs are generated according to the calling graph, so that the generation efficiency of the test parameters is improved, the security vulnerability detection efficiency is improved, and finally, the method calling when the APIs process the test parameters is analyzed, so that the security vulnerability detection efficiency is improved. The API interface with the recursive structure with vulnerability suspicion is marked as possible security vulnerabilities, so that the system can more efficiently and accurately help testers to find related types of security vulnerabilities in the API interface, and then can timely optimize the API interface to defend attacks against the vulnerabilities.

Description

Technical Field

[0001] The present invention relates to the technical field of security vulnerability detection, and in particular to a security vulnerability detection system based on an API interface. Background Art

[0002] API is the abbreviation of "Application Programming Interface". It is a set of rules and definitions that allow software programs to communicate with each other. Through API, developers can use existing services or data to build new applications without having to understand the specific implementation details of the underlying. At present, most of the communication between Web, APP, etc. and servers is achieved through API interfaces to transfer and exchange data. However, due to the weak security awareness of some developers and the failure to strictly comply with security regulations during the development process, some API interfaces may have security vulnerabilities, which in turn affects the security of the overall system. Therefore, it is necessary to perform security testing on the API interface.

[0003] Existing security vulnerability detection technologies still have certain limitations in discovering deep security vulnerabilities in API interfaces, including: the need to generate a large number of test cases that meet the API interface requirements, otherwise it is difficult to discover deep vulnerabilities in the API interface; and the failure to consider the calling relationship between different API interfaces, only performing vulnerability detection on a single API interface, making it difficult to achieve deep detection, resulting in the need to further improve detection efficiency and accuracy. Summary of the invention

[0004] The purpose of the present invention is to provide a security vulnerability detection system based on API interface to further improve the efficiency and accuracy of API interface security vulnerability detection.

[0005] To achieve the above-mentioned purpose, the present invention provides a security vulnerability detection system based on an API interface, the system comprising:

[0006] The parsing module is used to parse the API interface to be detected and obtain all the information of the API interface to be detected, wherein the all the information includes the calling information of the API interface;

[0007] Static analysis module, used to analyze the calls of API interfaces and determine the calling relationships between different API interfaces based on the analysis results;

[0008] Dynamic analysis module, used to generate a call graph based on the call relationship between different API interfaces, and generate a detection queue according to the call graph;

[0009] Random generation module, used to generate test parameters of API interface according to the call graph;

[0010] The vulnerability analysis module is used to input test parameters into the API interface to be tested in the detection queue, analyze the method calls when the API interface processes the test parameters, determine whether the API interface has a recursive structure suspected of having a vulnerability, and determine the API interface that may have a security vulnerability based on the judgment result.

[0011] Furthermore, all the information of the API interface to be detected also includes the path information, method, input parameters or output parameters of the API interface.

[0012] Furthermore, the static analysis module is specifically used to determine other API interfaces called by the API interface according to the calling information of the API interface, so as to determine the calling relationship between different API interfaces.

[0013] Furthermore, the dynamic analysis module specifically includes:

[0014] The first initialization submodule is used to initialize the call graph and add corresponding API nodes in the call graph according to the API interface to be detected;

[0015] The edge adding submodule is used to add edges between API nodes with calling relationships according to the calling relationships between different API interfaces;

[0016] The weight calculation submodule is used to calculate the weight of an API node based on the number of times it is called;

[0017] The graph output submodule is used to output the call graph.

[0018] Furthermore, the dynamic analysis module specifically includes:

[0019] The second initialization submodule is used to initialize the detection queue;

[0020] The fetch and place submodule is used to fetch API nodes from the call graph based on the order of weight from large to small, and put the fetched API nodes into the detection queue;

[0021] The adjacent node determination submodule is used to determine the adjacent nodes of the API node placed in the detection queue. The adjacent nodes are other API nodes that have edges with the API node. The node with the highest weight among the adjacent nodes is selected, the necessary API calls it contains are determined, and the node is placed in the detection queue.

[0022] Furthermore, the random generation module specifically includes:

[0023] The constraint submodule is used to convert the requirements of each API interface on the value range or format of the input parameter into constraint conditions to obtain multiple constraint conditions;

[0024] A parameter generation submodule, used for randomly generating multiple test parameter groups that satisfy at least one constraint condition, each test parameter group containing at least one test parameter;

[0025] The output identification submodule is used to generate a corresponding output state array based on the detection queue. Each element in the output state array corresponds to an API interface in the detection queue. The value of the element is 0 or 1. If the API interface can generate a valid output when the test parameter group is input into the API interface, the element corresponding to the API interface is assigned a value of 1, otherwise it is assigned a value of 0;

[0026] The iterative submodule is used to input the test parameter group into the API interface in the detection queue at each iteration, update the elements of the output state array according to whether the API interface generates valid output, remove the elements with a value of 1, and update the test parameter group at the same time, and perform multiple loop iterative solutions until the number of elements in the output state array is zero.

[0027] Furthermore, the vulnerability analysis module specifically includes:

[0028] The parameter input submodule is used to input the test parameters into the API interface to be tested;

[0029] The type analysis submodule is used to analyze the call type of the API interface and determine whether the call of the API interface is a call type or an assignment type containing a method call. If so, it detects whether the method called by the API interface is contained in a statement block that can handle exceptions. If not, it triggers the recursive analysis submodule.

[0030] The recursive analysis submodule is used to check whether there are recursive calls in the stack when it is triggered. If so, it further determines whether the recursive calls obey the depth limit. If not, the corresponding API interface is marked as having a possible security vulnerability.

[0031] Compared with the prior art, the present invention has the following beneficial effects:

[0032] The present invention provides a security vulnerability detection system based on API interface. The system analyzes the calls of API interface through static analysis module and dynamic analysis module, generates a call graph that can characterize the call relationship between different API interfaces, generates a detection queue according to the call graph, and generates test parameters of API interface according to the call graph, thereby improving the generation efficiency of test parameters and thus improving the security vulnerability detection efficiency. Finally, by analyzing the method calls when the API interface processes the test parameters, the API interface with a recursive structure suspected of having a vulnerability is marked as a possible security vulnerability, so that the system can more efficiently and accurately help testers discover relevant types of security vulnerabilities in the API interface, and then timely optimize it to defend against attacks against such vulnerabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only preferred embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0034] Figure 1 It is a schematic diagram of the overall structure of a security vulnerability detection system based on an API interface provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0035] The principles and features of the present invention are described below in conjunction with the accompanying drawings. The enumerated embodiments are only used to explain the present invention and are not used to limit the scope of the present invention.

[0036] Reference Figure 1 This embodiment provides a security vulnerability detection system based on an API interface, the system comprising:

[0037] The parsing module is used to parse the API interface to be detected and obtain all the information of the API interface to be detected, wherein the all the information includes the calling information of the API interface. The calling information is used to indicate which interfaces or methods are called by the API interface.

[0038] Exemplarily, the entire information includes at least the path information, method, input parameter or output parameter of the API interface. The input parameter includes the name, type, reference value and constraint of the input parameter; the output parameter includes the name, type, reference value and constraint of the output parameter.

[0039] The static analysis module is used to analyze the calls of the API interface and determine the calling relationship between different API interfaces based on the analysis results. Specifically, the static analysis module can determine other API interfaces called by the API interface based on the calling information of the API interface to determine the calling relationship between different API interfaces.

[0040] The dynamic analysis module is used to generate a call graph based on the call relationship between different API interfaces and generate a detection queue according to the call graph.

[0041] The random generation module is used to generate test parameters for the API interface based on the call graph.

[0042] The vulnerability analysis module is used to input test parameters into the API interface to be tested in the detection queue, analyze the method calls when the API interface processes the test parameters, determine whether the API interface has a recursive structure suspected of having a vulnerability, and determine the API interface that may have a security vulnerability based on the judgment result.

[0043] The system provided in this embodiment analyzes the calls of the API interface through the static analysis module and the dynamic analysis module, generates a call graph that can characterize the calling relationship between different API interfaces, generates a detection queue according to the call graph, and generates test parameters of the API interface according to the call graph, thereby improving the efficiency of generating test parameters, thereby improving the efficiency of security vulnerability detection, and finally, by analyzing the method calls when the API interface processes the test parameters, the API interface with a recursive structure that is suspected of having a vulnerability is marked as a possible security vulnerability, so that the system can more efficiently and accurately help testers discover relevant types of security vulnerabilities in the API interface, and then optimize it in time to defend against attacks against such vulnerabilities.

[0044] As a preferred implementation, the dynamic analysis module specifically includes a first initialization submodule, an edge adding submodule, a weight calculation submodule and a graph output submodule.

[0045] The first initialization submodule is used to initialize the call graph and add corresponding API nodes in the call graph according to the API interface to be detected.

[0046] The edge adding submodule is used to add edges between API nodes with calling relationships according to the calling relationships between different API interfaces.

[0047] The weight calculation submodule is used to calculate the weight of an API node based on the number of times it is called.

[0048] The graph output submodule is used to output the call graph.

[0049] In this implementation, the output graph is a weighted directed graph, which is expressed as:

[0050] M=(P,S,W)

[0051] Among them, represents the call graph, represents the set of all API nodes in the call graph, represents the set of edges between different API nodes, and represents the set of weights of different API nodes. Whether there is an edge between different API nodes is determined based on the calling relationship between the API interfaces. If there is a calling relationship between two API nodes, an edge is added between the two API nodes, otherwise no edge is added. In principle, the more times an API node is called, the higher its weight. The specific calculation rules can be set according to actual needs, and this implementation method does not make specific limitations on this.

[0052] Based on this implementation, the dynamic analysis module further includes a second initialization submodule, a pick-and-place submodule, and an adjacent node determination submodule.

[0053] Wherein, the second initialization submodule is used to initialize the detection queue.

[0054] The fetch and place submodule is used to fetch API nodes from the call graph based on the order of weight from large to small, and put the fetched API nodes into the detection queue.

[0055] The adjacent node determination submodule is used to determine the adjacent nodes of the API node placed in the detection queue. The adjacent nodes are other API nodes that have edges with the API node. The node with the highest weight among the adjacent nodes is selected, the necessary API calls it contains are determined, and the node is placed in the detection queue.

[0056] In this implementation, after the call graph is generated, a detection queue is generated according to the call graph, the API nodes in the detection queue are sorted according to the weights, and the API nodes that have a call relationship are arranged adjacently.

[0057] As a preferred implementation, the random generation module includes a constraint submodule, a parameter generation submodule, an output identification submodule and an iteration submodule.

[0058] The constraint submodule is used to convert the requirements of each API interface on the value range or format of the input parameter into constraint conditions to obtain multiple constraint conditions.

[0059] The parameter generation submodule is used to randomly generate multiple test parameter groups that meet at least one constraint condition, and each test parameter group contains at least one test parameter.

[0060] The output identification submodule is used to generate a corresponding output status array based on the detection queue. Each element in the output status array corresponds to an API interface in the detection queue. The value of the element is 0 or 1. If the API interface can generate valid output when the test parameter group is input into the API interface, the element corresponding to the API interface is assigned to 1, otherwise it is assigned to 0.

[0061] The iterator module is used to input the test parameter group into the API interface in the detection queue at each iteration, update the elements of the output state array according to whether the API interface generates valid output, remove the elements with a value of 1, and update the test parameter group at the same time, performing multiple loop iterations until the number of elements in the output state array is zero.

[0062] In order to reduce the number of test parameter groups and improve detection efficiency, this implementation method searches for the test parameter group with the largest number of elements in the output state array that can generate valid outputs. By taking out the elements with a value of 1 in the output state array at each iteration, there are always elements in the output state array that cannot represent valid outputs at the beginning of the next iteration until the elements in the array are empty. In this way, the final test parameter group can fully meet the testing requirements of each API interface and improve detection efficiency by reducing the number of test parameters.

[0063] As another preferred implementation, the vulnerability analysis module specifically includes a parameter input submodule, a type analysis submodule and a recursive analysis submodule.

[0064] Among them, the parameter input submodule is used to input the test parameters into the API interface to be tested.

[0065] The type analysis submodule is used to analyze the call type of the API interface, determine whether the call of the API interface is a call type or an assignment type containing a method call, and if so, detect whether the method called by the API interface is contained in a statement block that can handle exceptions. If not, trigger the recursive analysis submodule.

[0066] The recursive analysis submodule is used to check whether there is a recursive call in the stack when it is triggered. If so, it further determines whether the recursive call obeys the depth limit. If not, the corresponding API interface is marked as a possible security vulnerability. The stack is a stack for storing calling methods.

[0067] This implementation determines whether to perform recursive analysis by checking the type of test parameters that are processed when the API interface calls the method, and further detecting whether the called method is contained in a statement block that can handle exceptions. If the called method is already contained in a statement block that can handle exceptions, there is no need to perform recursive analysis. When performing recursive analysis, by determining whether the recursive call obeys the depth limit, it is analyzed whether there is abnormal recursion in the method called by the API interface, that is, whether the recursion can terminate normally. When the recursion does not obey the depth limit, the recursion may not terminate, and the method called by the API interface may generate abnormal computing resource consumption. Therefore, the API interface with recursive method calls that do not obey the depth limit is marked as an API interface that may have security vulnerabilities, so that further detection and optimization can be performed later.

[0068] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A security vulnerability detection system based on API interface, characterized in that: The system comprises: The parsing module is used to parse the API interface to be detected and obtain all the information of the API interface to be detected, wherein the all the information includes the calling information of the API interface; Static analysis module, used to analyze the calls of API interfaces and determine the calling relationships between different API interfaces based on the analysis results; Dynamic analysis module, used to generate a call graph based on the call relationship between different API interfaces, and generate a detection queue according to the call graph; Random generation module, used to generate test parameters of API interface according to the call graph; The vulnerability analysis module is used to input test parameters into the API interface to be tested in the detection queue, analyze the method calls when the API interface processes the test parameters, determine whether the API interface has a recursive structure suspected of having a vulnerability, and determine the API interface that may have a security vulnerability based on the judgment result.

2. According to the API interface-based security vulnerability detection system of claim 1, it is characterized in that: All information about the API interface to be detected also includes path information, methods, input parameters or output parameters of the API interface.

3. According to the API interface-based security vulnerability detection system of claim 1, it is characterized in that: The static analysis module is specifically used to determine other API interfaces called by the API interface according to the calling information of the API interface, so as to determine the calling relationship between different API interfaces.

4. The API-based security vulnerability detection system according to claim 1, characterized in that: The dynamic analysis module specifically includes: The first initialization submodule is used to initialize the call graph and add corresponding API nodes in the call graph according to the API interface to be detected; The edge adding submodule is used to add edges between API nodes with calling relationships according to the calling relationships between different API interfaces; The weight calculation submodule is used to calculate the weight of an API node based on the number of times it is called; The graph output submodule is used to output the call graph.

5. The API-based security vulnerability detection system according to claim 4, characterized in that: The dynamic analysis module specifically includes: The second initialization submodule is used to initialize the detection queue; The fetch and place submodule is used to fetch API nodes from the call graph based on the order of weight from large to small, and put the fetched API nodes into the detection queue; The adjacent node determination submodule is used to determine the adjacent nodes of the API node placed in the detection queue. The adjacent nodes are other API nodes that have edges with the API node. The node with the highest weight among the adjacent nodes is selected, the necessary API calls it contains are determined, and the node is placed in the detection queue.

6. The API-based security vulnerability detection system according to claim 1, characterized in that: The random generation module specifically includes: The constraint submodule is used to convert the requirements of each API interface on the value range or format of the input parameter into constraint conditions to obtain multiple constraint conditions; A parameter generation submodule, used for randomly generating multiple test parameter groups that satisfy at least one constraint condition, each test parameter group containing at least one test parameter; The output identification submodule is used to generate a corresponding output state array based on the detection queue. Each element in the output state array corresponds to an API interface in the detection queue. The value of the element is 0 or 1. If the API interface can generate a valid output when the test parameter group is input into the API interface, the element corresponding to the API interface is assigned a value of 1, otherwise it is assigned a value of 0; The iterative submodule is used to input the test parameter group into the API interface in the detection queue at each iteration, update the elements of the output state array according to whether the API interface generates valid output, remove the elements with a value of 1, and update the test parameter group at the same time, and perform multiple loop iterative solutions until the number of elements in the output state array is zero.

7. The API-based security vulnerability detection system according to claim 1, characterized in that: The vulnerability analysis module specifically includes: The parameter input submodule is used to input the test parameters into the API interface to be tested; The type analysis submodule is used to analyze the call type of the API interface and determine whether the call of the API interface is a call type or an assignment type containing a method call. If so, it detects whether the method called by the API interface is contained in a statement block that can handle exceptions. If not, it triggers the recursive analysis submodule. The recursive analysis submodule is used to check whether there are recursive calls in the stack when it is triggered. If so, it further determines whether the recursive calls obey the depth limit. If not, the corresponding API interface is marked as having a possible security vulnerability.

Images