A method for generating and mutating database fuzzy test query statements

Abstract

This invention discloses a method for generating and mutating database fuzzy testing query statements. First, a stateless query statement is generated; then, the stateless query statement is mutated; finally, the test is executed and the results are fed back. The generated or mutated stateless query statement is sent to the target database for execution, and the database response is recorded. The results are also fed back to optimize subsequent statement generation. This invention can improve testing efficiency by eliminating the need for pre-creating tables and inserting data, reducing test preparation time; it avoids persistent disk writes, reducing I / O overhead and making the testing process more efficient, especially when frequently switching test scenarios, where efficiency improvements can reach over 30%.

Description

Technical Field

[0001] This invention belongs to the field of testing technology, specifically relating to a method for generating and mutating database fuzzy test query statements. Background Technology

[0002] With the widespread application of database technology in various information systems, the security and stability of databases have become increasingly important. Fuzz testing, as an efficient vulnerability detection method, is widely used in testing database systems and related applications. By generating and executing a large number of queries, vulnerabilities in the database's handling of abnormal input (such as SQL injection vulnerabilities, crash vulnerabilities, etc.) can be discovered.

[0003] However, existing database fuzzing relies on specific table structures and data. Before testing, tables must be created and data inserted according to the target scenario, making the testing process complex and time-consuming, especially when frequently changing test scenarios or restoring test states, resulting in low efficiency. Furthermore, persistent disk write operations not only increase testing costs but may also affect the accuracy of test results due to data residue, posing numerous limitations to database system security testing.

[0004] Currently, the mainstream database fuzzing engines on the market (such as SQLMap's fuzzing module and AFL-based database testing tools) are the closest existing technologies to this invention. The core function of these engines is to generate and mutate query statements to test the database, but they all rely on specific table structures: the generated query statements must target preset table names, field names, data types, etc., and before execution, it must be ensured that the corresponding table has been created and contains a certain amount of data.

[0005] The existing technology for generating and mutating fuzzy test query statements is as follows: Figure 1 .

[0006] The specific implementation process is as follows: 1. The fuzz testing engine first analyzes the table structure of the test target (e.g., obtaining table names, field names, data types, etc. through database metadata); 2. Create the corresponding table in the database based on the table structure; 3. Insert preset test data (such as random strings, numbers, etc.) into the created table; 4. Generate query statements based on table structure and data (e.g., SELECT * FROM table_name WHERE field=value); 5. Send the generated query statement to the database for execution; 6. Record the database response (e.g., whether it crashed, returned abnormal results, etc.); 7. Modify the generated query statement (e.g., change field names or values, or add invalid keywords) to generate a new query statement; 8. Repeat steps 5 through 7 until the test is complete.

[0007] The disadvantages of existing technologies are as follows: Dependent on specific table structure: The generated query statements are strongly bound to the preset table structure. When changing the test scenario (such as testing different tables or databases), the tables and data need to be recreated, resulting in poor flexibility. Test preparation time: Creating tables and inserting data takes a lot of time, especially when the table structure is complex or the amount of data is large, which significantly reduces test efficiency; Reliance on persistent disk writes: Persistent storage of tables and data increases disk I / O overhead, and data cleanup and state recovery are time-consuming when frequently switching test environments; Poor reproducibility of test results: Since the query statement depends on preset data, the execution results of the same query statement may be different when the data is modified or deleted, making it difficult to reproduce the test results. Summary of the Invention

[0008] To overcome the shortcomings of existing technologies, this invention provides a method for generating and mutating database fuzzy testing query statements. First, a stateless query statement is generated; then, the stateless query statement is mutated; finally, test execution and result feedback are completed. The generated or mutated stateless query statement is sent to the target database for execution, and the database response is recorded. The results are also fed back to optimize subsequent statement generation. This invention can improve testing efficiency by eliminating the need for pre-creating tables and inserting data, reducing test preparation time; it avoids persistent disk writes, reducing IO overhead and making the testing process more efficient, especially when frequently switching test scenarios, where efficiency improvements can reach over 30%.

[0009] The technical solution adopted by this invention to solve its technical problem is as follows: Step 1: Generating stateless query statements: Analyze the syntax rules of the target database; Generates initial query statements based on syntax rules, independent of preset table structures and data; Step 2: Stateless query statement mutation: Receive the initial query statement, mutate it according to the preset mutation rules, and ensure that the stateless property is maintained after mutation; Step 3: Test Execution and Result Feedback: The modified query statement is sent to the target database for execution. Record the database response; The feedback result is sent to step 2 to optimize subsequent statement generation.

[0010] Preferably, the syntax rules of the database include SQL's SELECT and INSERT syntax and MongoDB's find and insert syntax.

[0011] Preferably, the generation of the initial query statement based on syntax rules, which does not depend on a preset table structure and data, includes: For SQL databases: generate SELECT 1+2, SELECT NOW(), and SELECT 'test' LIKE 't%'; For NoSQL databases: generate db.eval("1+1") and db.getCollectionNames().

[0012] Preferably, the mutation rules include: Add / remove irrelevant keywords, modify constant values, replace functions, and adjust statement structure.

[0013] Preferably, the database response includes whether it has crashed, returns an error code, and indicates an execution timeout.

[0014] A database fuzzing query generation and mutation system includes: Stateless query statement generation module: Analyzes the syntax rules of the target database; generates an initial query statement based on the syntax rules that does not depend on the preset table structure and data, and sends it to the mutation module; Mutation module: Receives the initial stateless query statement, performs mutation according to the preset mutation rules, and ensures that the stateless characteristics are maintained after mutation; Test execution module: Sends the generated or mutated stateless query statement to the target database for execution; records the database response; and feeds back the results to the mutation module for optimizing subsequent statement generation.

[0015] An electronic device includes: a processor and a memory; the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory to cause the electronic device to execute the above-described database fuzzy test query statement generation and mutation method.

[0016] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method for generating and mutating database fuzzy test query statements.

[0017] A chip includes a processor for retrieving and running a computer program from memory, causing a device equipped with the chip to execute the aforementioned database fuzzy test query statement generation and mutation method.

[0018] A computer program product includes a computer storage medium storing a computer program, the computer program including instructions executable by at least one processor, which, when executed by the at least one processor, implement the above-described database fuzzy test query statement generation and mutation method.

[0019] The beneficial effects of this invention are as follows: 1. Improved testing efficiency: No need to pre-create tables and insert data, reducing test preparation time; avoidance of persistent disk writes reduces IO overhead, making the testing process more efficient, especially when frequently switching test scenarios, efficiency can be improved by more than 30%.

[0020] 2. Enhanced test result reproducibility: The execution result of a stateless query statement is determined only by the statement itself and the current state of the database (not preset data). The same statement will produce consistent results under the same database version, which solves the problem of unreproducible results due to data changes in the existing technology.

[0021] 3. Enhanced testing flexibility: The generated query statements do not depend on a specific table structure and can be directly used for testing different types and versions of databases (such as supporting both SQL and NoSQL), thus expanding the testing scope.

[0022] 4. Reduced testing costs: Reduced table creation, data insertion and cleanup operations, reducing resource consumption in the testing environment (such as disk space and computing resources), especially suitable for resource-limited scenarios (such as embedded database testing). Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the implementation of fuzzy testing query generation and mutation techniques in existing technologies. Figure 2 This is a framework diagram of the database fuzzy test query statement generation and mutation system of the present invention; Figure 3 This is a flowchart of the database fuzzy test query statement generation and mutation method of the present invention; Figure 4 This is a flowchart of Embodiment 1 of the present invention; Figure 5 This is a flowchart of Embodiment 2 of the present invention. Detailed Implementation

[0024] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0025] To address the shortcomings of existing database fuzzing engines, such as reliance on specific table structures, the need for pre-creating tables and inserting data, low testing efficiency, and poor reproducibility of results, this invention proposes a method for generating and mutating database fuzzing query statements.

[0026] Its core technical problems include: 1. How to generate stateless query statements that do not depend on preset table structures and data, avoiding table creation and data insertion operations before testing; 2. How to optimize query statement mutation technology so that the mutated statement still retains its stateless characteristics and ensures the continuity of the testing process; 3. Improve testing efficiency, reduce persistent disk write operations, and enhance the reproducibility of test results.

[0027] This paper achieves automated generation, mutation, and testing of stateless query statements by modifying the query statement generation and mutation algorithm. The specific process is as follows: (1) Generation of stateless query statements: The stateless query statement generation module first analyzes the syntax rules of the target database (such as SQL's SELECT and INSERT syntax, MongoDB's find and insert syntax, etc.). Generate initial query statements based on syntax rules that do not depend on pre-defined table structures and data, for example: For SQL databases: Generate SELECT 1+2; (calculated based on constants, no table required), SELECT NOW(); (calls system functions, no table required), SELECT 'test' LIKE 't%'; (string manipulation, no table required), etc. For NoSQL databases (such as MongoDB): generate db.eval("1+1"); (directly execute the expression, no collection needed), db.getCollectionNames(); (query system information, no pre-defined collection needed), etc.

[0028] (2) Variation of stateless query statements: The mutation module receives the initial stateless query statement, mutates it according to preset rules, and ensures that the stateless characteristics are maintained after mutation. Variation rules include: adding / removing irrelevant keywords (such as adding / *comment* / comments in SQL statements), modifying constant values ​​(such as changing SELECT 1+2; to SELECT 3*4;), replacing functions (such as changing NOW() to CURDATE()), and adjusting statement structure (such as changing SELECT 'a' to SELECT 'a' UNION SELECT 'b'), etc.

[0029] (3) Test execution and result feedback: The test execution module sends the generated or modified stateless query statement to the target database for execution; Record the database response (e.g., whether it crashed, returned an error code, or timed out). The results are fed back to the mutation module to optimize subsequent statement generation (such as increasing the mutation frequency for statement types that frequently crash).

[0030] The entire process does not require creating tables or inserting data. All query statements are executed based on the database's own syntax and system functions, avoiding persistent disk operations. Furthermore, the execution result of the statement is determined only by the statement itself and the current state of the database (not preset data), making it highly reproducible.

[0031] Example 1: Fuzz testing for MySQL databases; (1) The flowchart of Example 1 is as follows Figure 4 As shown; (2) The detailed implementation process of the technical solution in Example 1 is as follows: 1) Initial statement generation: The MySQL stateless generation module generates the initial statement based on MySQL syntax and the system's built-in table structure (without requiring pre-creation by the user): SELECT COUNT(*) FROM information_schema.tables.

[0032] The information_schema.tables table is a system table that comes with the MySQL database and is used to store metadata for all tables in the database. It exists by default and does not need to be created manually by the user. Therefore, this statement does not depend on the default user table structure and data, which conforms to the stateless characteristic.

[0033] 2) First mutation: The mutation module performs a "function substitution" mutation on the initial statement, generating: SELECT MAX(TABLE_ROWS)FROM information_schema.tables.

[0034] Variation description: The statistical function COUNT(*) has been replaced with MAX(TABLE_ROWS). The query is still based on the TABLE_ROWS field (number of table rows) of the system table information_schema.tables. No user tables or data have been introduced, and the system remains stateless.

[0035] 3) Perform the test: The test execution module sends the statement to the MySQL database. After execution, it returns the maximum number of rows in all tables in the system (e.g., 100). If there are no exceptions, it records "normal response".

[0036] 4) Second mutation: The mutation module performs "add comments and adjust fields" mutation on the initial statement, generating: SELECT COUNT(TABLE_NAME) / *fuzz_test_001* / FROM information_schema.tables WHERE TABLE_SCHEMA = 'mysql'.

[0037] 5) Perform the test: After the statement is executed, it returns the number of tables in the MySQL system database (e.g., 30). If there are no exceptions, it is recorded as "normal response".

[0038] 6) Third mutation: The mutation module performs a "replace system table" mutation, generating: SELECT DISTINCT TABLE_TYPE FROM information_schema.columns;.

[0039] 7) Perform the test: After the statement is executed, it returns a list of table types to which the fields in the system table belong (e.g., ['BASE TABLE', 'VIEW']). If there are no exceptions, it records "normal response".

[0040] By repeatedly mutating and executing the query, the stability of MySQL in handling different stateless query statements can be tested without pre-creating tables or data.

[0041] Example 2: Fuzz testing for MongoDB; (1) The flowchart of Example 2 is as follows Figure 5 As shown; (2) The detailed implementation process of the technical solution in Example 2 is as follows: 1) Initial statement generation: The MongoDB stateless generation module is based on MongoDB syntax and generates the initial statement: db.eval("1+1"); (the eval function is called to execute the expression, without needing a set).

[0042] 2) First mutation: The mutation module performs a "modify expression" mutation, generating: db.eval("3*3 + 2"); (still an expression calculation, stateless).

[0043] 3) Perform the test: The test execution module sends the statement to MongoDB, and returns result 11 after execution. There are no exceptions, and "normal response" is recorded.

[0044] 4) Second mutation: The mutation module performs an "add invalid parameter" mutation, generating: db.eval("1+1", "extra_param",123); (MongoDB's eval function ignores extra parameters, and the statement can still be executed).

[0045] 5) Perform the test: The statement returned result 2 after execution, with no exceptions, and was recorded as "normal response".

[0046] 6) Third mutation: The mutation module performs a "replacement function" mutation, generating: db.runCommand({eval: "5-2"}); (using runCommand to call eval is functionally equivalent and stateless).

[0047] 7) Perform the test: The statement returned result 3 after execution, indicating no exceptions. Record "Normal Response".

[0048] This embodiment achieves efficient testing of MongoDB by generating and mutating stateless statements, without relying on preset collections and data.

[0049] The present invention can also be replaced by the following technical solutions, which can achieve the same objective: 1. Query statement generation based on in-memory temporary tables: The generated query statement includes instructions for automatically creating an in-memory temporary table (such as SQL's CREATE TEMPORARY TABLE) and inserting temporary data. The temporary table is automatically deleted after the statement is executed. Although this approach involves table operations, the in-memory table does not require persistent disk writes and is automatically cleaned up after execution, thus avoiding the shortcomings of existing technologies.

[0050] 2. Query statement generation based on database system tables: Generate query statements using database system tables (such as information_schema in MySQL and pg_catalog in PostgreSQL). System tables are tables that exist in the database by default and do not need to be created by the user in advance, which can achieve a stateless effect.

[0051] 3. Static syntax mutation combined with dynamic adaptation: First, the basic statement is generated according to the stateless rule. If table-related keywords (such as FROM) are introduced during mutation, it will be automatically adapted to the default tables in the database (such as system tables) to ensure that the statement is executable and does not depend on user-preset data.

Claims

1. A method for generating and mutating database fuzzy test query statements, characterized in that, Includes the following steps: Step 1: Generating stateless query statements: Analyze the syntax rules of the target database; Generates initial query statements based on syntax rules, independent of preset table structures and data; Step 2: Stateless query statement mutation: Receive the initial query statement, mutate it according to the preset mutation rules, and ensure that the stateless property is maintained after mutation; Step 3: Test Execution and Result Feedback: The modified query statement is sent to the target database for execution. Record the database response; The feedback result is sent to step 2 to optimize subsequent statement generation.

2. The method for generating and mutating database fuzzy test query statements according to claim 1, characterized in that, The syntax rules of the database include SQL's SELECT and INSERT syntax and MongoDB's FIND and INSERT syntax.

3. The method for generating and mutating database fuzzy test query statements according to claim 1, characterized in that, The generation of initial query statements based on syntax rules, which do not depend on preset table structures and data, includes: For SQL databases: generate SELECT 1+2, SELECT NOW(), and SELECT 'test' LIKE 't%'; For NoSQL databases: generate db.eval("1+1") and db.getCollectionNames().

4. The method for generating and mutating database fuzzy test query statements according to claim 1, characterized in that, The mutation rules include: Add / remove irrelevant keywords, modify constant values, replace functions, and adjust statement structure.

5. The method for generating and mutating database fuzzy test query statements according to claim 1, characterized in that, The database response includes whether it crashed, returned an error code, and indicated an execution timeout.

6. A database fuzzy test query statement generation and mutation system employing the generation and mutation method as described in claim 1, characterized in that, include: Stateless query statement generation module: Analyzes the syntax rules of the target database; An initial query statement, generated based on syntax rules and independent of the preset table structure and data, is sent to the mutation module. Mutation module: Receives the initial stateless query statement, performs mutation according to the preset mutation rules, and ensures that the stateless characteristics are maintained after mutation; Test execution module: Sends the generated or mutated stateless query statement to the target database for execution; records the database response; The results are fed back to the mutation module to optimize subsequent statement generation.

7. An electronic device, characterized in that, include: Processor and memory; The memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory to cause the electronic device to perform the method as described in any one of claims 1 to 6.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 6.

9. A chip, characterized in that, include: A processor for retrieving and running a computer program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer storage medium storing a computer program, the computer program including instructions executable by at least one processor, which, when executed by the at least one processor, implement the method as described in any one of claims 1 to 6.

Images