API Misuse Detection Method and System Based on Library Source Code and Client Source Code Mining

Abstract

An API misuse detection method based on library source code and client source code mining is proposed. First, a frequent subgraph mining algorithm is used to mine frequently occurring API usage patterns in client code as API usage pattern constraints. Second, an abstract syntax tree is constructed by collecting all methods of each target API class and its parent classes in the library source code, and then an inference strategy is used to extract API library source code constraints. The two types of constraints are then represented as an API usage graph, followed by constraint merging and optimization. Finally, a graph matching algorithm is used for API misuse detection. The degree of suspicion of misuse is calculated based on the obtained candidate API misuses, thus achieving API misuse detection. This invention utilizes third-party library source code to mine more comprehensive and accurate API constraints, effectively solving the problem of insufficient comprehensiveness and information in API constraints from client code, and significantly improving the recall and precision of API misuse detection.

Description

Technical Field

[0001] This invention relates to a technology in the field of information security, specifically an API misuse detection (CL-Detector) method and system based on the mining of library source code and client source code. Background Technology

[0002] In recent years, an increasing number of software systems have reused third-party libraries or frameworks by calling Application Programming Interfaces (APIs) to save software development time and improve efficiency. Calling APIs should adhere to various API constraints, such as call order, condition checks, and exception handling. Due to the large number of APIs, manually defining API constraints and detecting API misuse is extremely tedious. Therefore, many studies have emerged on automated API misuse detection based on static or dynamic code analysis methods.

[0003] Existing API misuse detection technologies based on customer code mining extract frequent API usage patterns from numerous API usage code snippets. API usage code snippets that violate these patterns are then considered candidate API misuses and sorted in descending order of suspicion. However, API usage patterns mined from customer code only represent a portion of common API usages, and there is a significant gap between these patterns and actual API constraints. This lack of comprehensiveness and precision results in low recall and precision for API misuse detection, making it difficult to deploy in practice. Furthermore, this approach is unsuitable for uncommon or newly released APIs, as it is difficult to obtain sufficient customer code for pattern mining. Therefore, how to mine comprehensive and accurate API constraints to improve API misuse detection effectiveness requires further in-depth exploration. Summary of the Invention

[0004] This invention addresses the lack of comprehensiveness and accuracy in API usage patterns mined from client code compared to actual API constraints in existing methods. It proposes an API misuse detection method and system based on library and client source code mining. By utilizing the source code of third-party API libraries, it uncovers more comprehensive and accurate API constraints, effectively bridging the significant gap between API usage patterns and actual API constraints derived from client code, and addressing the difficulty in obtaining sufficient client code for uncommon APIs. This significantly improves the recall and accuracy of API misuse detection.

[0005] This invention is achieved through the following technical solution:

[0006] This invention relates to an API misuse detection method based on library source code and client source code mining. It employs a frequent subgraph mining algorithm to mine frequently occurring API usage patterns in client code as API usage pattern constraints. It also constructs an abstract syntax tree by collecting all methods of each target API class and its parent classes from the library source code, and then extracts API library source code constraints using a derivation strategy. Finally, it represents the two types of constraints as an API usage graph, performs constraint merging and optimization, and uses a graph matching algorithm for API misuse detection. Based on the obtained candidate API misuses, it calculates the degree of suspicion of misuse, thus achieving API misuse detection.

[0007] API misuse refers to code snippets that violate API constraints, including misuse types such as lack of condition checks, lack of exception handling, lack of method calls, and redundant calls.

[0008] The client code refers to code snippets from actual projects collected from GitHub that use specific APIs.

[0009] The constraints include: condition checking constraints, exception handling constraints, and call order constraints. Condition checking constraints require checking the values ​​of method parameters or the current state of the object before calling a method of an object. For example, before calling the `get(int index)` method of the `java.util.List` class, it must be checked that `index >= 0`. Exception handling constraints require handling potential exceptions thrown by a method when calling it. For example, when calling the constructor of the `java.io.FileInputStream` class, it must handle the `NullPointerException` exception thrown if the file does not exist. Call order constraints require that multiple API methods often need to be called in a certain order to function correctly. For example, before calling the `next()` method of the `java.util.Iterator` class, the `hasNext()` method must be called first to ensure that the iterator contains the next element.

[0010] The API usage pattern constraints refer to the API usages that frequently occur in client code, represented by an API usage graph, which is specifically obtained through the following methods:

[0011] 1) Represent each API usage code snippet as an API usage graph: Use the Eclipse JDT parsing tool to represent the code snippet as an AST (Abstract Syntax Tree), extract the data or action entities, as well as the data flow and control flow relationships, as nodes and edges of the API usage graph, thereby generating the API usage graph.

[0012] The API usage graph refers to a graph representing the API usage within a code snippet. It consists of various types of nodes and edges. Nodes in the API usage graph represent data entities in the code, including objects, values, and literals, as well as action entities, including method calls, operators, and instructions. Edges in the API usage graph represent the control and data flow between nodes, including: initiating a call, passing parameters, initialization assignment, execution order, conditional branching, exception throwing, exception catching, and synchronization locks.

[0013] 2) From numerous API usage code snippets represented as API usage graphs, a frequent subgraph mining algorithm is used to obtain subgraphs that frequently appear in the graphs composed of points and edges. When the frequency reaches a preset threshold, the API usage subgraph is taken as the API usage pattern.

[0014] The frequent subgraph mining algorithm uses the method call nodes of the target API in the graph as the initial subgraph. Under the premise that the frequency is greater than a threshold, it recursively expands to the surrounding neighbor nodes to form a larger subgraph. During the recursive expansion process, each neighbor node around the subgraph is traversed to determine whether it can be added to the subgraph. At the same time, nodes that are only connected by control flow edges but have no data flow relationship are ignored, because these nodes are not related to the use of the target API and are usually code related to the business logic of the project itself.

[0015] The aforementioned API library source code constraints were obtained through the following methods:

[0016] 1) Determine the scope of methods to be analyzed in the library source code: Identify all methods of the class containing each target API in the library source code. If it inherits from a parent class, include all methods of the parent class in the analysis scope, as many parent class methods are frequently used in subclasses. If the target API is an interface without a concrete implementation, analyze the implementation of methods in one of its commonly used implementation classes.

[0017] 2) Derive API constraints from library source code using deduction strategy: First, generate an abstract syntax tree for the source code of each API method, and then extract the API constraints implicit in the API implementation source code from the node information of the syntax tree according to the deduction strategy.

[0018] The condition check constraints in the API library source code constraints are obtained through the following derivation strategy:

[0019] Strategy 1: Identify the `assert` keyword and calls to the `Objects.requireNonNull()` method in the source code, and extract the parameters as conditional constraints. Then, identify the conditional constraints on the method parameter values ​​in the `@param` or `@throws` annotations.

[0020] Strategy 2: Identify the `throw` keyword, then identify the conditions in the conditional branch statements that wrap the `throw` exception statement, filter out conditions that contain private attributes or local variables that are not accessible from the outside, and use the remaining conditions as condition checks and constraints.

[0021] Strategy 3: Java native methods also have conditional checks and constraints, but there is no Java source code implementation. This example is based on Java development experience to manually analyze common Java native methods and define their conditional checks and constraints.

[0022] Strategy 4: Within the API method implementation, other methods may be called. Condition checks and constraints existing in these other methods may be passed to the API method. Therefore, constraints for other methods within a certain call depth can also be derived using the three strategies described above.

[0023] The exception handling constraints in the API library source code constraints are obtained through the following derivation strategy:

[0024] Strategy 5: Identify the throw statement, the throws keyword, the @throws annotation, and the @exception annotation. The exception class following these annotations represents the exceptions that may be thrown, and these are extracted as exception handling constraints.

[0025] Strategy 6: Derive the substitutability relationship between exception handling constraints and conditional checking constraints. The client code for the corresponding API only needs to satisfy one of the substitutable constraints. When a throw statement corresponding to an exception handling constraint is wrapped by a conditional branch statement, and the conditional checking constraint can be derived from the conditional branch statement according to Strategy 2, then the two are substitutable.

[0026] The call order constraint in the API library source code constraints is derived using the following derivation strategy:

[0027] Strategy 7: Derive call order constraints from the method call graph. When method 1 initializes variable 'a' and method 2 uses variable 'a', then method 1 must be called before method 2. When method 3 uses object 'o' and method 4 clears object 'o' (e.g., sets it to null), then method 4 must be called after method 3. This order relationship can be passed to the methods that call these methods through the method call graph.

[0028] Strategy 8: Define two heuristics based on method names. First, methods whose names contain "hasNext" are called before methods whose names contain "next," applicable to traversal-related APIs such as the `java.util.Iterator` class. Second, methods whose names contain "close" are called after methods whose names contain "write," applicable to resource usage-related APIs such as the `java.io.DataOutputStream` class.

[0029] The aforementioned constraint merging refers to representing constraints from the library source code as an API usage graph and unifying them with constraints from the client code. For each constraint, an API usage code snippet satisfying that constraint is generated, and then the API usage code snippet is represented as an API usage graph. For example, if the method `method` has a conditional check constraint `condition`, the generated code snippet would be "if(condition{}){method();}".

[0030] The aforementioned constraint optimizations include: enhancing API constraints from client code and improving the comprehensiveness and richness of constraints.

[0031] The aforementioned enhancement of API constraints from client code refers to: when the methods and types of constraints overlap with the constraints in the library source code, passing the fine semantic details of the overlapping constraints to the constraints from the client code, such as the pre- or post-type of the call order constraint; and then directly merging the sets of API constraints from the library source code and the client source code.

[0032] The improvement of the comprehensiveness and richness of constraints refers to: modifying the constraints of the client code according to the constraints of the library source code to generate new constraints; when a subgraph in the constraints of the client code is related to condition checks or exception handling, replacing the subgraph with the corresponding type of constraint from the library source code to generate a new constraint that has a substitution relationship with the original constraint.

[0033] The API misuse detection process specifically includes:

[0034] 1) For each API usage code snippet to be detected, generate its API usage graph, and then use a graph matching algorithm to match it with the API usage graph of the API constraints. Code snippets that fail to match or violate the API constraints are considered as candidate API misuses.

[0035] 2) Calculate the degree of suspicion of misuse of candidate API misuse, and take the K reports with the highest degree of suspicion of misuse as the final API misuse.

[0036] The degree of suspicion of misuse refers to the score of the likelihood that a candidate API misuse is a real API misuse. Factors affecting this score include: the frequency of the violated API constraint in the client code, whether the API constraint was discovered from the library source code, the frequency of the violation of this API constraint in the client code, and the difference between the usage that satisfies the API constraint.

[0037] This invention relates to a system for implementing the above method, comprising: a client code mining module, a library source code mining module, a constraint combination module, and a misuse detection module, wherein: the client code mining module generates frequently occurring API usage patterns in client code as API constraints; the library source code mining module derives API constraints implicit in the API implementation source code; the constraint combination module combines the API constraints from the library source code and the client code; and the misuse detection module detects API misuses that violate API constraints.

[0038] Technical effect

[0039] This invention comprehensively addresses the shortcomings of existing API misuse detection methods based on client code, which suffer from a gap between API usage patterns and actual API constraints, and lack comprehensiveness and accuracy. This invention utilizes components that mine API constraints from API library source code and a fusion component of API constraints from client code and library source code. Based on multiple mining strategies, it extracts more comprehensive API constraints from the library source code, encompassing various types. In the API fusion module, constraints from the library source code are used to enhance constraints from client code, thus increasing the richness of API constraints. Compared to existing technologies, this invention significantly improves the recall and accuracy of API misuse detection. By using API library source code as the source for deriving API constraints, regardless of whether the API has sufficient client code, the API library source code, as the origin of API constraints, always exists and can derive relatively comprehensive and accurate API constraints. This effectively solves the problem of the gap between API usage patterns from client code and actual API constraints, improving the effectiveness of API misuse detection. Attached Figure Description

[0040] Figure 1 This is a diagram illustrating the method architecture of the present invention;

[0041] Figure 2 This is a schematic diagram illustrating API source code and implicit API usage in the form of an API constraint example in the embodiment. Detailed Implementation

[0042] like Figure 1 As shown, this relates to an API misuse detection method based on library source code and client source code mining, including:

[0043] 1) The MuBench dataset is used as the API to be detected.

[0044] The dataset MuBench is a dataset of API misuse instances, which includes some API misuse instances that have occurred in actual projects. Each API misuse instance data includes: the repository address of the project where the misuse occurred, the commit ID of the project version where the misuse occurred, the location of the file and method where the misuse occurred, the API used, and a description of how the API was misused.

[0045] 2) Collect the source code of the target API and its associated third-party libraries for subsequent collection of client code.

[0046] The target APIs include: all API classes involved in misuse instances in the MuBench API misuse dataset, and the API classes containing the top 100 Java API methods widely discussed on the StackOverflow forum.

[0047] 3) Collect customer code that uses the target API from GitHub. Specifically, use the Boa mining tool to select the top 20 open source projects that use each target API the most from GitHub repositories as customer projects. From each customer project, select code snippets that use the target API as customer code. Using the API means that a class calls a method of the API class.

[0048] 4) Extract API constraints from both client code and library source code, and then merge the constraints.

[0049] In the aforementioned API constraint mining, mining API constraints from client code means: representing client code as an API usage graph, using a frequent subgraph mining algorithm to mine frequently occurring API usage subgraphs, and using API usage subgraphs with a frequency exceeding a threshold of 5 as API usage patterns, i.e., API constraints from client code.

[0050] like Figure 2 As shown in (a), this is a partial implementation of the java.util.Iterator API class, which implicitly imposes call order constraints: hasNext() must be called before calling next(), and next() must be called before calling remove(). These two constraints are represented by the API usage diagram as follows. Figure 2 As shown in (b).

[0051] In the aforementioned API constraint mining, mining API constraints from library source code refers to: for each target API class, collecting all methods of the class and its parent classes, performing code parsing, constructing an abstract syntax tree, and then using a derivation strategy to extract condition check constraints, exception handling constraints, and call order constraints from the abstract syntax tree.

[0052] The aforementioned constraint merging refers to representing the API library source code constraints as an API usage graph, and then merging it with the set of API usage graphs representing API usage pattern constraints to obtain the final set of API constraints.

[0053] 5) API misuse detection is performed based on the discovered API constraints. Specifically, the code snippets of API usage to be detected are represented as API usage graphs. Graph matching algorithms are used to match them with the API usage graphs of API constraints. The degree of suspicion of misuse is then calculated for candidate API misuses that violate API constraints, thereby realizing API misuse detection.

[0054] The formula for calculating the degree of suspicion of misuse is: score = (c s +s l ) / v s *v d v d =n m / n c , where: c s The number of times the violated API constraint appears in the client code; s l For API constraints from library source code, s is the initial weight constant. l Set to 1, otherwise, s l =0; v s The frequency of API misuse in client code is constrained; the rarer the misuse, the more likely it is a genuine misuse. d To measure the difference between this misuse and the usage that satisfies the API constraints, calculate the number of nodes n missing in the misuse compared to the API constraints. m Divide by the total number of nodes constrained by API, n c get.

[0055] This embodiment uses the MuBench API misuse dataset and other API misuse detection methods for comparative experiments. The MuBench dataset contains 223 API misuse instances from 57 real-world projects, involving the usage of 65 APIs. Of these, 110 misuses were due to missing condition checks, 26 due to missing exception handling, 81 due to missing method calls, and 6 due to redundant elements such as redundant calls. This embodiment collects 106 target APIs, including 65 APIs covered by MuBench and 68 APIs widely discussed on the Stack Overflow forum. This embodiment collects client code and library source code for each target API. From the client code, this embodiment extracted 1092 constraints, while from the library source code, it extracted 12,538 constraints, including 712 condition check constraints, 3432 exception handling constraints, and 8394 call order constraints.

[0056] This embodiment uses three metrics—Recall, Precision, and F1—to measure the performance of different API misuse detection tools. Recall measures how many MuBench misuse instances are correctly detected. Precision measures how many of the top-ranked misuses are genuine misuses. The F1 metric is the harmonic mean of Recall and Precision, calculated as follows: F1 = 2 * (precision * recall) / (precision + recall).

[0057] Accuracy requires manual analysis to determine if the detection results represent genuine misuse, as misuse not recorded in MuBench may also be genuine. Therefore, this embodiment randomly samples 10 items from MuBench's 57 items, and calculates the accuracy based on the top 20 misuse detection results for each item. To reduce errors from human judgment, two developers with over 3 years of Java development experience independently annotated the detection results, and Cohen's Kappa index was used to verify the consistency of their annotations. Finally, any discrepancies were discussed to reach a consensus.

[0058] The Kappa index is calculated as follows: k = (p o -p e ) / (1-p e ). Where p o It is the sum of the number of samples with identical labels divided by the total number of samples. e The calculation formula is p e = (a1*a2+b*b2) / (n*n), where a1 and a2 are the number of samples labeled as correctly misused, b1 and b2 are the number of samples labeled as incorrectly misused, and n is the total number of samples.

[0059] This embodiment selects MuDetect as the comparative misuse detection method. MuDetect is the best-performing misuse detection method recently, which detects API misuse based on API usage patterns mined from client code. The misuse detection method in this embodiment is based on API constraints mined from both library source code and client code; comparing the two methods can measure the effectiveness of API constraints from the library source code.

[0060] Table 1 shows the experimental results of MuDetect and our method on the MuBench dataset in terms of recall, precision, and F1 score.

[0061] Table 1

[0062]

[0063] As shown in Table 1, the overall F1 score of our proposed method for misuse detection is 45.6%, a significant improvement compared to MuDetect's 34.5%. Our method also achieves a recall rate of 50.2%, a significant improvement over MuDetect's 39.5%. Of the 223 MuBench misuse instances, our method correctly recalled 112, including 36 instances lacking condition checks, 21 lacking exception handling, and 55 lacking method calls. In Table 1, Pre1 and Pre2 represent the accuracy results independently judged by annotator 1 and annotator 2, respectively. PreF represents the final accuracy result after the two annotators reached a consensus on areas of inconsistency. The Kappa coefficients, measuring consistency, are all above 0.60, indicating a high degree of consistency and high reliability of the accuracy results. Our method's final accuracy of 41.7% is also significantly higher than MuDetect's.

[0064] The analysis of the experimental results is as follows: This method, to a certain extent, solves the problem of poor API misuse detection caused by the gap between API usage patterns from client code and actual API constraints. Starting from the source code of the library where API constraints originate, this method mines more comprehensive and precise API constraints containing more semantic details. More comprehensive API constraints help detect more API misuses, and more precise API constraints reduce misuses that are incorrectly identified, thereby improving the overall recall and precision of API misuse detection results.

[0065] The above specific embodiments can be partially adjusted by those skilled in the art in different ways without departing from the principles and spirit of the present invention. The scope of protection of the present invention is defined by the claims and is not limited to the above specific embodiments. All implementation schemes within the scope of the claims are bound by the present invention.

Claims

1. A method for detecting API misuse based on library source code and client source code mining, characterized in that, API usage patterns are mined from customer code by a frequent subgraph mining algorithm as API usage pattern constraints, and API library source code constraints are mined by collecting all methods of each target API class and its parent classes to build abstract syntax trees, and then API library source code constraints are extracted from the abstract syntax trees using a deduction strategy; the two kinds of constraints are represented as API usage graphs, and then constraint merging and constraint optimization are performed, and API misuse detection is performed using a graph matching algorithm, and the suspiciousness of the candidate API misuse is calculated to achieve API misuse detection; The API library source code constraints are mined by the following methods: 1) determining the method range for analysis in the library source code: determining all methods of each target API class in the library source code, and when it inherits parent classes, all parent class methods are also included in the analysis range, because many parent class methods are often used in child classes; when the target API is an interface without specific implementation, the method implementation of a commonly used implementation class is analyzed; 2) deriving API constraints from library source code by a deduction strategy: first, generating an abstract syntax tree for each API method source code, and then extracting API implementation source code constraints from the syntax tree node information according to the deduction strategy; The API usage pattern constraints refer to API usage patterns that frequently occur in customer code, which are represented by API usage graphs, and are mined by the following methods: 1) representing each API usage code snippet as an API usage graph: using the Eclipse JDT parsing tool to represent the code snippet as an AST abstract syntax tree, and extracting data or action entities, as well as data flow and control flow relationships as API usage graph nodes and edges, thereby generating an API usage graph; 2) using a frequent subgraph mining algorithm to obtain frequently occurring subgraphs in numerous graphs composed of nodes and edges from numerous API usage code snippets represented by API usage graphs, and when the frequency reaches a threshold, the API usage subgraph is used as an API usage pattern; The API misuse detection process specifically includes: 1) for each API usage code snippet to be detected, generating its API usage graph, and then using a graph matching algorithm to match the API usage graph with the API usage graph of the API constraint, and the code snippet that fails to match is considered as a candidate API misuse that violates the API constraint; 2) calculating the suspiciousness of the candidate API misuse, and taking the top K reports with the highest suspiciousness as the final API misuse.

2. The method of claim 1, wherein the API misuse detection based on library source code and client source code mining is characterized by, The deduction strategy includes: Strategy 1: identifying the call of the assert keyword and the Objects.requireNonNull() method in the source code, extracting the parameters as condition checking constraints, and identifying the condition constraints on the method parameter values in the @param or @throws annotations; Strategy 2: identifying the throw keyword, and then identifying the conditions in the conditional branch statements that wrap the throw exception throwing statements, filtering out conditions that contain private properties or local variables that cannot be accessed externally, and the remaining conditions are used as condition checking constraints; Strategy 3: Manually analyze common java native method and define its condition check constraint based on java development experience; Strategy 4: In the API method implementation, other methods are called, and the called methods are also deduced by the above three strategies to derive constraints; Strategy 5: Identify throw statements, throws keywords, @throws annotations, and @exception annotations. The exception classes after them are the possible exceptions that may be thrown, and they are extracted as exception handling constraints; Strategy 6: Derive the replaceable relationship between exception handling constraints and condition check constraints. The customer code of the API only needs to meet one of the replaceable constraints; when the throw statement corresponding to the exception handling constraint is wrapped in a conditional branching statement, and the condition check constraint is derived from the conditional branching statement according to strategy 2, the two have a replaceable relationship; Strategy 7: Derive the call order constraint from the method call relationship graph: when method 1 initializes variable a, and method 2 uses variable a, method 1 needs to be called before method 2; When object o is used in method 3, and object o is cleared in method 4, such as null, method 4 needs to be called after method 3; The order relationship of the two is transmitted to the method that calls these methods through the method call relationship graph; Strategy 8: Define two heuristic rules based on method names: one is that the method name contains hasNext, and the method name contains next, which is suitable for traversal-related APIs such as java.util.Iterator class; The second is that the method name contains close, and the method name contains write, which is suitable for resource usage-related APIs such as java.io.DataOutputStream class.

3. The method of claim 1, wherein the API misuse detection based on library source code and client source code mining is characterized by, The constraint merging refers to: expressing the constraints from the library source code into API usage graph form, and unifying the constraints from the customer code, for each constraint, generating an API usage code fragment that satisfies the constraint, and expressing the API usage code fragment as an API usage graph.

4. The method of claim 1, wherein the API misuse detection based on library source code and client source code mining is characterized by, The constraint optimization includes: enhancing the API constraints from the customer code and improving the comprehensiveness and richness of the constraints, wherein: enhancing the API constraints from the customer code refers to: when the method and type of the constraint overlap with the constraints of the library source code, the fine semantic details of the overlapping constraints are transmitted to the constraints from the customer code, such as the pre or post type of the call order constraint; Then the API constraints from the library source code and the customer source code are directly merged; improving the comprehensiveness and richness of the constraints refers to: modifying the constraints of the customer code according to the constraints of the library source code, thereby generating new constraints, when the subgraph in the constraints of the customer code is related to condition check or exception handling, replace the subgraph with the corresponding type constraint of the library source code, generate new constraints that have a replaceable relationship with the original constraints.

5. The method of claim 1, wherein the method is characterized by, The misuse suspicious degree refers to scoring the possibility of a candidate API misuse as a real API misuse; factors affecting the scoring include the frequency of the violated API constraint appearing in the client code, whether the API constraint is mined from the library source code, the frequency of the violation of the API constraint appearing in the client code, and the gap of the usage meeting the API constraint.

6. A system for implementing the API misuse detection method based on library source code and client source code mining according to any one of claims 1-5, characterized in that, The method comprises the following steps: A client code mining module, a library source code mining module, a constraint combining module, and a misuse detection module, wherein the client code mining module generates frequently appearing API usage patterns in the client code as API constraints, the library source code mining module derives the API constraints implied in the API implementation source code, the constraint combining module combines the API constraints from the library source code and the client code, and the misuse detection module detects API misuses violating the API constraints.

Images