JAVA fuzzy testing method based on program analysis

Abstract

The invention provides a JAVA fuzzy testing method based on program analysis. The JAVA fuzzy testing method comprises the steps that a binary file package of a tested program is obtained; aST analysis is carried out on the binary file package; all layers of nodes of a syntax tree of the binary file package are analyzed, and all conditional branches under all classes and all methods are obtained; analyzing a calling link relationship of each branch judgment parameter of the binary file package through reverse derivation of calling of each layer of nodes; and judging whether the calling link relationship is single-interface calling or cross-interface calling. According to the JAVA fuzzy test method based on program analysis provided by the invention, the interface parameters and the test case data of the interface calling sequence can be obtained through program analysis, and the service logic which is difficult to explore by fuzzy test can be greatly increased, so that the coverage rate of the tested object is increased, and the test efficiency is improved based on the improvement of the coverage rate. The number of paths explored by the fuzzy test is increased, and more non-overdue defects can be prompted to be found.

Description

Technical Field

[0001] The embodiment of the present invention relates to the field of network information security technology, and in particular to a JAVA fuzzy testing method based on program analysis. Background Art

[0002] The existing fuzz testing methods for JAVA have low running coverage of most codes during system-level testing, and cannot be improved through fuzz testing in a short period of time. There is a problem that the test coverage of the target under test is low when there is sufficient testing time.

[0003] The invention patent with the publication number CN118427830A and the name "Java deserialization vulnerability mining method, device and medium based on fuzzy testing" discloses a Java deserialization vulnerability mining method based on fuzzy testing, which includes: using the bidirectional tracking taint analysis technology, taking the Java deserialization entry function and the dangerous function as the starting point to search, find the potential vulnerability call chain, and obtain the function information in the corresponding execution path; based on the function weight allocation strategy of the TrustRank algorithm, determine the corresponding function type, and calculate the TrustRank weight coefficient corresponding to each function type, so as to sort the functions in the order of the TrustRank weight coefficient from high to low; the function types include dangerous functions, path functions, suspicious functions and branch functions; based on the function call information and the corresponding TrustRank weight coefficient, and through the gray box fuzzy test, the vulnerability call chain is fuzzy tested to determine the validity of the vulnerability call chain, and complete the mining of Java deserialization vulnerabilities. However, this method is relatively complicated and the testing efficiency is not high.

[0004] Therefore, it is necessary to provide a JAVA fuzz testing method based on program analysis to solve the above problems. Summary of the invention

[0005] The present invention provides a JAVA fuzzy testing method based on program analysis. The test case data of interface parameters and interface calling sequence that can be obtained through program analysis can greatly increase the business logic that is difficult to explore through fuzzy testing, thereby increasing the coverage of the object under test. Based on the improvement of coverage, the number of paths explored by fuzzy testing increases, which can promote the discovery of more non-overdue defects.

[0006] The embodiment of the present invention provides a JAVA fuzz testing method based on program analysis, comprising: Get the binary file package of the program under test; Performing AST parsing on the binary file package; Parsing nodes at each level of the syntax tree of the binary file package to obtain all conditional branches under all classes and all methods; By reverse deduction of the node calls at each layer, the call link relationship of each branch judgment parameter of the binary file package is parsed; Determine whether the call link relationship is a single interface call or a cross-interface call.

[0007] Preferably, when the call link relationship is a single interface call, a magic number is parsed for the single interface to determine whether the magic number is a constant or a configuration file field; When the magic number is a constant field, mapping the constant to an interface variable; When the magic number is a configuration file field, the corresponding variable is mapped to the configuration file field.

[0008] Preferably, it also includes: Generate test data for a single interface and change the calling method of the specified configuration file field.

[0009] Preferably, it also includes: When the call link relationship is a cross-interface call, parsing the interface relationship; Decompiling the binary file package to obtain program source code using the binary decompilation method; Parse the JAVA code files and various XML resource package files contained in the source code.

[0010] Preferably, determining whether there is an SQL operation in the source code; When there is an SQL operation in the source code, the method and field of the SQL operation are mapped to the interface through parsing, and the parsed relationship between the cache operation and the interface is stored in the interface relationship analysis pool; When there is no SQL operation in the source code, it is determined whether there is a cache operation in the source code.

[0011] Preferably, the determining whether there is a cache operation in the source code includes: When there is a cache operation in the source code, the mode and field of the cache operation are mapped to the interface through parsing, and the parsed relationship between the cache operation and the interface is stored in the interface relationship analysis pool; When there is no cache operation in the source code, it is determined whether there is a file operation in the source code.

[0012] Preferably, the determining whether there is a file operation in the source code includes: When there is a file operation in the source code, the mode and field of the file operation are mapped to the interface through parsing, and the relationship between the parsed file operation and the interface is stored in the interface relationship analysis pool; When there is no file operation in the source code, it is determined whether there is a message operation in the source code.

[0013] Preferably, the determining whether there is a message operation in the source code includes: When there is a message operation in the source code, the mode and field of the message operation are mapped to the interface through parsing, and the relationship between the parsed message operation and the interface is stored in the interface relationship analysis pool; When there is no message operation in the source code, the interface relationship data stored in the interface relationship analysis pool is dynamically run and explored.

[0014] Preferably, it also includes dynamically running and exploring the interface relationship data stored in the interface relationship analysis pool; Use the path exploration algorithm to perform breadth-first exploration and generation of all combinations of interface call relationships; The generated interface call relationship, interface test data and configuration steps are run and tested and the run coverage is collected.

[0015] Preferably, the method further comprises the following steps: If the interface call relationship, interface test data, and configuration steps generate a new path, it is a valid test case; If no new path is generated, the algorithm continues to generate new test cases for testing until the interface relationship analysis pool is explored; Output all valid test cases.

[0016] Compared with the prior art, the technical solution of the embodiment of the present invention has the following beneficial effects: A JAVA fuzzy testing method based on program analysis provided by an embodiment of the present invention includes: obtaining a binary file package of a program under test; performing AST parsing on the binary file package; parsing nodes at each layer of a syntax tree of the binary file package to obtain all conditional branches under all classes and all methods; parsing the call link relationship of parameters of each branch of the binary file package through reverse deduction of the calls of the nodes at each layer; judging whether the call link relationship is a single interface call or a cross-interface call. The test case data of interface parameters and interface call sequence that can be obtained through program analysis can greatly increase the business logic that is difficult to explore with fuzzy testing, thereby increasing the coverage of the object under test. Based on the improvement of coverage, the number of paths explored by fuzzy testing increases, which can prompt more non-overdue defects to be discovered. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the prior art descriptions. Obviously, the drawings described below are some embodiments of the present invention, not all embodiments. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative labor.

[0018] Figure 1 A flowchart of a JAVA fuzzy testing method based on program analysis provided by an embodiment of the present invention; Figure 2 A flowchart of a JAVA fuzzy testing method based on program analysis provided by another embodiment of the present invention; Figure 3 A flowchart of a JAVA fuzzy testing method based on program analysis is provided for yet another embodiment of the present invention. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0020] The technical solution of the present invention is described in detail with specific embodiments below. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0021] Based on the problems existing in the prior art, an embodiment of the present invention provides a JAVA fuzz testing method based on program analysis. The test case data of interface parameters and interface call sequence that can be obtained through program analysis can greatly increase the business logic that is difficult to explore through fuzz testing, thereby increasing the coverage of the object under test. Based on the improvement of coverage, the number of paths explored by fuzz testing increases, which can prompt more non-overdue defects to be discovered.

[0022] Figure 1 A flowchart of a JAVA fuzzy testing method based on program analysis is provided for one embodiment of the present invention. Figure 1 , provides a JAVA fuzz testing method based on program analysis, including: Step S101: Obtain the binary file package of the program under test; Step S102: performing AST (Abstract Syntax Tree) parsing on the binary file package; Step S103: parsing nodes at each level of the syntax tree of the binary file package to obtain all conditional branches under all classes and all methods; Step S104: parsing the call link relationship of each branch judgment parameter of the binary file package through reverse deduction of the node calls of each layer; Step S105: Determine whether the call link relationship is a single interface call or a cross-interface call.

[0023] Specifically, in step S102, the AST syntax tree, i.e., the abstract syntax tree, is a tree-shaped data structure used to represent the syntax structure of the source code. Before the code is compiled or interpreted, it needs to go through two stages: lexical analysis and grammatical analysis. Lexical analysis decomposes the source code into lexical units (Tokens), such as keywords, identifiers, operators, etc. Syntactic analysis organizes these lexical units into a syntax tree according to grammatical rules. This tree is the AST syntax tree.

[0024] In step S104, branch judgment includes statements such as if, Block, Catch, continue, do, forEach, return, try, synchronized, throw, while, and yield.

[0025] Figure 2 A flowchart of a JAVA fuzzy testing method based on program analysis is provided for another embodiment of the present invention. Figure 2 , provides a JAVA fuzz testing method based on program analysis, including: Step S201: Obtain the binary file package of the program under test; Step S202: performing AST parsing on the binary file package; Step S203: parsing nodes at each level of the syntax tree of the binary file package to obtain all conditional branches under all classes and all methods; Step S204: parsing the call link relationship of each branch judgment parameter of the binary file package through reverse deduction of the node calls of each layer; Step S205: determining whether the call link relationship is a single interface call or a cross-interface call; Step S206: when the call link relationship is a single interface call, performing magic number analysis on the single interface to determine whether the magic number is a constant or a configuration file field; Step S207: When the magic number is a constant field, map the constant to an interface variable; Step S208: When the magic number is a configuration file field, mapping the corresponding variable to the configuration file field.

[0026] Specifically, for example, there is a judgment condition if A=1, 1 is the magic number, A is the corresponding variable, and the variable A can be mapped to a field in the configuration file through parsing.

[0027] Figure 3 A flowchart of a JAVA fuzzy testing method based on program analysis is provided for another embodiment of the present invention. Figure 3 , provides a JAVA fuzz testing method based on program analysis, including: Step S301: Obtain the binary file package of the program under test; Step S302: performing AST parsing on the binary file package; Step S303: parsing nodes at each level of the syntax tree of the binary file package to obtain all conditional branches under all classes and all methods; Step S304: parsing the call link relationship of each branch judgment parameter of the binary file package through reverse deduction of the node calls of each layer; Step S305: determining whether the call link relationship is a single interface call or a cross-interface call; Step S306: when the call link relationship is a single interface call, performing magic number analysis on the single interface to determine whether the magic number is a constant or a configuration file field; Step S307: When the magic number is a constant field, map the constant to an interface variable; Step S308: When the magic number is a configuration file field, mapping the corresponding variable to the configuration file field; Step S309: Generate test data for a single interface and change the calling method of the specified configuration file field.

[0028] Step S310: When the call link relationship is a cross-interface call, the interface relationship is parsed; Step S311: Decompile the binary file package to obtain program source code using a binary decompilation method; Step S312: Parse the JAVA code files and various XML resource package files contained in the source code. Specifically, in step S309, for example, there is a judgment condition if A=1, 1 is a magic number, A is a corresponding variable, and if through parsing, A can correspond to a field B in the configuration file. Then when generating this single interface test, it is necessary to add a call step to rewrite the configuration file field B, so as to test different situations of the judgment condition A=1 in the program code by changing the value of field B.

[0029] In a specific implementation, it is determined whether there is an SQL operation in the source code; When there is a SQL (Structured Query Language) operation in the source code, the method and field of the SQL operation are mapped to the interface through parsing, and the parsed relationship between the cache operation and the interface is stored in the interface relationship analysis pool; When there is no SQL operation in the source code, it is determined whether there is a cache operation in the source code.

[0030] In a specific implementation, determining whether there is a cache operation in the source code includes: When there is a cache operation in the source code, the mode and field of the cache operation are mapped to the interface through parsing, and the parsed relationship between the cache operation and the interface is stored in the interface relationship analysis pool; When there is no cache operation in the source code, it is determined whether there is a file operation in the source code.

[0031] In a specific implementation, the determining whether there is a file operation in the source code includes: When there is a file operation in the source code, the mode and field of the file operation are mapped to the interface through parsing, and the relationship between the parsed file operation and the interface is stored in the interface relationship analysis pool; When there is no file operation in the source code, it is determined whether there is a message operation in the source code.

[0032] In a specific implementation, the determining whether there is a message operation in the source code includes: When there is a message operation in the source code, the mode and field of the message operation are mapped to the interface through parsing, and the relationship between the parsed message operation and the interface is stored in the interface relationship analysis pool; When there is no message operation in the source code, the interface relationship data stored in the interface relationship analysis pool is dynamically run and explored.

[0033] In a specific implementation, it also includes dynamically running and exploring the interface relationship data stored in the interface relationship analysis pool; Use the path exploration algorithm to perform breadth-first exploration and generation of all combinations of interface call relationships; The generated interface call relationship, interface test data and configuration steps are run and tested and the run coverage is collected.

[0034] In the specific implementation, the following steps are also included: If the interface call relationship, interface test data, and configuration steps generate a new path, it is a valid test case; If no new path is generated, the algorithm continues to generate new test cases for testing until the interface relationship analysis pool is explored; Output all valid test cases.

[0035] Finally, the fuzz testing of the above method is verified through auxiliary effects.

[0036] The unassisted fuzz testing coverage is as follows: Row coverage: 51.28%; Row hits: 60 / 117.

[0037] Branch coverage: 18.75%; Branch hit count: 9 / 48.

[0038] After using the above method to assist fuzz testing with program analysis, the coverage is as follows: Row coverage: 72.65%; Row hits: 85 / 117; Improvement over no assistance: 42%.

[0039] Branch coverage: 43.75%; Branch hits: 21 / 48; Improvement over unassisted: 133%.

[0040] In summary, an embodiment of the present invention provides a JAVA fuzzy testing method based on program analysis, including: obtaining a binary file package of a program under test; performing AST parsing on the binary file package; parsing nodes at each layer of the syntax tree of the binary file package to obtain all conditional branches under all classes and all methods; parsing the call link relationship of parameters of each branch of the binary file package through reverse deduction of the calls of the nodes at each layer; judging whether the call link relationship is a single interface call or a cross-interface call. The test case data of interface parameters and interface call sequence that can be obtained through program analysis can greatly increase the business logic that is difficult to explore with fuzzy testing, thereby increasing the coverage of the object under test. Based on the improvement of coverage, the number of paths explored by fuzzy testing increases, which can prompt more non-overdue defects to be discovered.

[0041] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A JAVA fuzz testing method based on program analysis, characterized in that: include: Get the binary file package of the program under test; Performing AST parsing on the binary file package; Parsing nodes at each level of the syntax tree of the binary file package to obtain all conditional branches under all classes and all methods; By reverse deduction of the node calls at each layer, the call link relationship of each branch judgment parameter of the binary file package is parsed; Determine whether the call link relationship is a single interface call or a cross-interface call.

2. The JAVA fuzz testing method based on program analysis according to claim 1 is characterized in that: When the call link relationship is a single interface call, performing magic number parsing on the single interface to determine whether the magic number is a constant or a configuration file field; When the magic number is a constant field, mapping the constant to an interface variable; When the magic number is a configuration file field, the corresponding variable is mapped to the configuration file field.

3. The JAVA fuzz testing method based on program analysis according to claim 2 is characterized in that: Also includes: Generate test data for a single interface and change the calling method of the specified configuration file field.

4. The JAVA fuzz testing method based on program analysis according to claim 3 is characterized in that: Also includes: When the call link relationship is a cross-interface call, parsing the interface relationship; Decompiling the binary file package to obtain program source code using the binary decompilation method; Parse the JAVA code files and various XML resource package files contained in the source code.

5. The JAVA fuzz testing method based on program analysis according to claim 4 is characterized in that: Determine whether there is an SQL operation in the source code; When there is an SQL operation in the source code, the method and field of the SQL operation are mapped to the interface through parsing, and the parsed relationship between the cache operation and the interface is stored in the interface relationship analysis pool; When there is no SQL operation in the source code, it is determined whether there is a cache operation in the source code.

6. The JAVA fuzz testing method based on program analysis according to claim 5 is characterized in that: The determining whether there is a cache operation in the source code includes: When there is a cache operation in the source code, the mode and field of the cache operation are mapped to the interface through parsing, and the parsed relationship between the cache operation and the interface is stored in the interface relationship analysis pool; When there is no cache operation in the source code, it is determined whether there is a file operation in the source code.

7. The JAVA fuzz testing method based on program analysis according to claim 5 is characterized in that: The determining whether there is a file operation in the source code includes: When there is a file operation in the source code, the mode and field of the file operation are mapped to the interface through parsing, and the relationship between the parsed file operation and the interface is stored in the interface relationship analysis pool; When there is no file operation in the source code, it is determined whether there is a message operation in the source code.

8. The JAVA fuzz testing method based on program analysis according to claim 7 is characterized in that: The determining whether there is a message operation in the source code includes: When there is a message operation in the source code, the mode and field of the message operation are mapped to the interface through parsing, and the relationship between the parsed message operation and the interface is stored in the interface relationship analysis pool; When there is no message operation in the source code, the interface relationship data stored in the interface relationship analysis pool is dynamically run and explored.

9. The JAVA fuzz testing method based on program analysis according to any one of claims 5 to 8, characterized in that: It also includes dynamically running and exploring the interface relationship data stored in the interface relationship analysis pool; Use the path exploration algorithm to perform breadth-first exploration and generation of all combinations of interface call relationships; The generated interface call relationship, interface test data and configuration steps are run and tested and the run coverage is collected.

10. The JAVA fuzz testing method based on program analysis according to claim 9, characterized in that: The following steps are also included: If the interface call relationship, interface test data, and configuration steps generate a new path, it is a valid test case; If no new path is generated, the algorithm continues to generate new test cases for testing until the interface relationship analysis pool is explored; Output all valid test cases.

Images