A time series database security testing method, device and equipment

Abstract

The embodiment of the specification discloses a kind of time series database security test method, device and equipment, the method comprises: the target program code in the time series database to be tested is compiled and inserted into the processing, the intermediate file corresponding to the target program code after inserting into is obtained, the intermediate file after inserting into is converted into the machine instruction code file after inserting into;Generation meets the time sequence rule corresponding to the time series database Time sequence SQL statement, the time sequence SQL statement is input into the target equipment running the machine instruction code file after inserting into, by the target equipment in the process of running the machine instruction code file after inserting into execution time sequence SQL statement, capture the abnormal information that appears in the process of running the time series database;Based on the captured abnormal information, determine the test result of the time series database security.

Description

Technical Field

[0001] This document relates to the field of computer technology, and in particular to a testing method, apparatus, and equipment for time-series database security. Background Technology

[0002] Data is the cornerstone of modern computer infrastructure, and databases are a crucial means of data storage. With the advent of the era of big data and the rise of cloud platforms and the Internet of Things (IoT), time-series databases have been widely adopted. Because much important and sensitive information is stored in time-series databases, they are increasingly becoming valuable targets for attacks. Once a time-series database is compromised, intruders can obtain highly valuable data. Therefore, ensuring the security of time-series databases is paramount, and testing their security is one of the most important methods. To this end, a more effective testing method for time-series database security is needed. Summary of the Invention

[0003] The purpose of the embodiments in this specification is to provide a more effective testing method for time-series database security, thereby providing a technical solution that can be applied to time-series databases and can automatically perform overall testing of time-series database security.

[0004] To achieve the above technical solution, the embodiments in this specification are implemented as follows:

[0005] This specification provides an embodiment of a method for testing the security of a time-series database. The method includes: compiling and instrumenting target program code in the time-series database to be tested to obtain an instrumented intermediate file corresponding to the target program code; converting the instrumented intermediate file into an instrumented machine instruction code file; generating a time-series SQL statement that satisfies the timing rules corresponding to the time-series database; inputting the time-series SQL statement into a target device that runs the instrumented machine instruction code file; executing the time-series SQL statement on the target device during the execution of the instrumented machine instruction code file; capturing abnormal information that occurs during the operation of the time-series database; and determining the test result for the security of the time-series database based on the captured abnormal information.

[0006] This specification provides an embodiment of a time-series database security testing device. The device includes a coverage collection component, a time-series SQL statement generation component, and an anomaly monitoring component. The coverage collection component is configured to perform compilation and instrumentation on target program code in the time-series database to be tested, obtaining an instrumented intermediate file corresponding to the target program code. It then converts the instrumented intermediate file into an instrumented machine code file, provides the instrumented machine code file to a target device, and triggers the target device to run the instrumented machine code file. The time-series SQL statement generation component is configured to generate a time-series SQL statement that satisfies the time-series rules corresponding to the time-series database, and inputs the time-series SQL statement into the target device running the instrumented machine code file. The coverage collection component is configured to, during the execution of the instrumented machine code file by the target device, execute the time-series SQL statement to obtain coverage information of multiple components in the time-series database, and then pass the coverage information to the time-series SQL statement generation component. The anomaly monitoring component is configured to execute the time-series SQL statement by the target device during the execution of the instrumented machine instruction code file, capture anomaly information that occurs during the operation of the time-series database, and determine the test result of the security of the time-series database based on the captured anomaly information.

[0007] This specification provides an embodiment of a time-series database security testing device, comprising: a processor; and a memory configured to store computer-executable instructions. When executed, the executable instructions cause the processor to: perform compilation and instrumentation on target program code in the time-series database to be tested, obtaining an instrumented intermediate file corresponding to the target program code; convert the instrumented intermediate file into an instrumented machine instruction code file; generate a time-series SQL statement that satisfies the timing rules corresponding to the time-series database; input the time-series SQL statement into a target device that runs the instrumented machine instruction code file; execute the time-series SQL statement on the target device during the execution of the instrumented machine instruction code file; and capture any anomalies occurring during the operation of the time-series database. Based on the captured anomaly information, the test result for the security of the time-series database is determined.

[0008] This specification also provides a storage medium for storing computer-executable instructions. When executed by a processor, these instructions perform the following process: compiling and instrumenting target program code in a time-series database to be tested to obtain an instrumented intermediate file corresponding to the target program code; converting the instrumented intermediate file into an instrumented machine instruction code file; generating a time-series SQL statement that satisfies the timing rules corresponding to the time-series database; inputting the time-series SQL statement into a target device running the instrumented machine instruction code file; executing the time-series SQL statement on the target device during the execution of the instrumented machine instruction code file; and capturing any abnormal information that occurs during the operation of the time-series database. Based on the captured abnormal information, determining the test results for the security of the time-series database. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a schematic diagram of the structure of a time-series database security testing system as described in this specification;

[0011] Figure 2A This is an embodiment of a test method for time-series database security as described in this specification;

[0012] Figure 2B This is a schematic diagram illustrating a time-series database security testing process as described in this specification;

[0013] Figure 3 This is a schematic diagram illustrating another testing process for time-series database security as described in this specification;

[0014] Figure 4 This specification provides an embodiment of a test apparatus for time-series database security.

[0015] Figure 5 This is a schematic diagram of another test system for time-series database security as described in this specification;

[0016] Figure 6 This is an embodiment of a test device for time-series database security, as described in this specification. Detailed Implementation

[0017] This specification provides a testing method, apparatus, and device for time-series database security.

[0018] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0019] This specification provides an embodiment of a time-series database security testing system, such as... Figure 1 As shown, its system architecture can include target devices and time-series database security testing equipment. The target device can be a terminal device or a server, such as a mobile terminal device like a phone or tablet, a computer device like a laptop or desktop computer, or an IoT device (specifically, a smartwatch or in-vehicle device). The server can be a single server or a server cluster consisting of multiple servers. This server can be a backend server for financial services or online shopping, or a backend server for a specific application. Figure 1 The following example uses a server. A time-series database security testing device can be an electronic device constructed from various components. It can be used to test the security of a specified time-series database, and the target device can be the device running that time-series database. The time-series database security testing process can include a preparation phase, an anomaly information collection phase, and an anomaly information analysis phase. In the preparation phase, the time-series database can be processed by the testing device to make it runnable by the target device. Specific probes (essentially code segments for information collection, such as assignment statements or function calls) are inserted into the database's program code to collect relevant information. In the anomaly information collection phase, the target device can run the time-series database, and the testing device can collect anomaly information during its operation. In the anomaly information analysis phase, the testing device can analyze the collected anomaly information to obtain the security test results for the time-series database. Specific processing details can be found in the following embodiments.

[0020] Example 1

[0021] like Figure 2A and Figure 2B As shown in the embodiments of this specification, a testing method for time-series database security is provided. The execution subject of this method can be an electronic device, which can be the aforementioned... Figure 1The testing equipment for time-series database security can, in practical applications, be a terminal device or a server. The terminal device can be a mobile terminal device such as a mobile phone or tablet, a computer device such as a laptop or desktop computer, or an IoT device (specifically, a smartwatch, in-vehicle device, etc.). The server can be a single server or a server cluster composed of multiple servers. The server can be a backend server for financial or online shopping services, or a backend server for an application. This embodiment uses a server as the execution subject for detailed explanation. For cases where the execution subject is a terminal device, please refer to the following server-side handling method, which will not be repeated here. The method specifically includes the following steps:

[0022] In step S202, the target program code in the timing database to be tested is compiled and instrumented to obtain the instrumented intermediate file corresponding to the target program code, and the instrumented intermediate file is converted into the instrumented machine instruction code file.

[0023] The time-series database can be used to process data with time tags (data that changes in chronological order, i.e., time serialization). Data with time tags can also be called time-series data. The target program code can be any program code in the time-series database. For example, it can be program code written in a specified programming language (such as C or JAVA), or program code containing a specified semantics. The specific settings can be determined according to the actual situation, and this specification does not limit this. Compilation can be the process of generating target program code from source program code written in a source language using a compiler. Specifically, it can be the conversion of high-level language program code written in a programming language into machine instruction code that a computer can recognize. Machine instruction code can be binary code, etc. Instrumentation can be the insertion of probes (also called "detectors," which are essentially code segments for information collection, such as assignment statements or calls to specified functions) into the source program code while ensuring the original logical integrity of the source program code. The execution of the probes will then output characteristic data of the source program code's operation.

[0024] In practice, data is the cornerstone of modern computer infrastructure development, and databases are a crucial means of data storage. With the advent of the era of big data and the rise of cloud platforms and the Internet of Things (IoT), time-series databases have been widely applied. A time-series database is a large-scale software application that operates and manages IoT data. It can handle operation requests from various clients and provide unified management and control. Because much important and sensitive information is stored in time-series databases, they are increasingly becoming valuable attack targets. Once a time-series database is compromised, intruders can obtain highly valuable data; therefore, ensuring the security of time-series databases is paramount. Compared to commonly used relational databases, time-series databases employ complex logic to handle their low latency and time-series characteristics, and their security, reliability, and correctness are all challenged by this complexity.

[0025] Fuzzing is a popular vulnerability discovery method that generates large amounts of input data to test program code and detects anomalies by monitoring for exceptions. Common fuzzing tools include AFL, SQLsmith, and Squirrel. AFL uses various methods, such as bit flipping and byte flipping, to transform an existing seed to generate new input data for testing the program code. SQLsmith uses an abstract syntax tree model to automatically construct input data for testing. Squirrel uses a syntax tree to transform existing input data for testing. However, due to the unique characteristics of time-series databases—multi-structure, multi-level, and multi-node—the aforementioned fuzzing tools are difficult to apply directly to them. This is because, firstly, they cannot obtain precise coverage information for the multiple components of a time-series database. Database systems often have extremely complex logic and numerous components, and roughly recorded features exhibit conflicts and inaccuracies within time-series database systems, thus failing to effectively guide the testing process towards new paths. Secondly, they cannot effectively synthesize syntactically and semantically correct time-series query statements. Time series is the fundamental form of data organization in time-series databases, but the aforementioned fuzzing tools struggle to generate syntactically and semantically correct time-series queries. For testing purposes, fuzzing tools targeting relational databases struggle to generate logical information with a time series structure. Furthermore, the highly structured queries accepted by time-series databases and their strict syntax hinder most seeds generated by random transformations in transformation-based (or mutation-based) fuzzing tools. Finally, implicit anomalies in time-series databases cannot be dynamically captured. While "crash" states are used as indicators of code vulnerabilities in fuzzing, time-series databases utilize implicit exception handling to prevent system crashes and improve availability and reliability. These anomalies may contain serious errors that fuzzing tools often ignore.

[0026] Typically, time-series database testers need to manually write numerous time-series test cases to perform security testing. However, this method not only consumes significant manpower but also suffers from low test completeness due to the lack of feedback from runtime information provided by the time-series database. Many deep-seated vulnerabilities hidden within the database's code are difficult to uncover, potentially leading to attacks on time-series database vendors and users, resulting in resource losses. Therefore, a method applicable to time-series databases and capable of automatically testing their security is of significant industrial value. To this end, a more effective testing method for time-series database security is needed. This specification provides an achievable technical solution, as detailed below.

[0027] When technicians or users need to test the security of a time-series database, they can provide the database to be tested or its identifier to an electronic device. The electronic device can directly obtain the corresponding time-series database or obtain it through the provided identifier, and can use the obtained database as the one to be tested. The electronic device can analyze the time-series database to obtain information such as the components contained in the database, the basic blocks, and the programming language corresponding to the program code. To accurately collect the coverage of multiple components in the time-series database during testing, a compiler is needed to perform white-box instrumentation compilation on the source files in the time-series database. Specifically, the target program code can be obtained from the time-series database based on the above analysis results, or it can be obtained directly from the time-series database through keyword matching or other methods, depending on the actual situation.

[0028] A compiler can be built according to the actual situation. This compiler can not only compile the program code in the time series database, but also perform instrumentation on the aforementioned program code. This compiler can be installed in an electronic device. When it is necessary to compile and instrument the target program code in the time series database, the compiler can be started, and the target program code in the time series database can be compiled and instrumented during the compilation process. Through the above processing, the instrumented intermediate file corresponding to the target program code can be obtained. Alternatively, it is not necessary to build a compiler. The target program code can be instrumented first using a pre-set instrumentation mechanism to obtain the instrumented program code. Then, the instrumented program code can be compiled using a pre-set compiler to obtain the instrumented intermediate file corresponding to the target program code. Alternatively, the target program code can be compiled first using a pre-set compiler to obtain intermediate files. Then, the pre-set instrumentation mechanism can be used to instrument the intermediate files to obtain the instrumented intermediate file corresponding to the target program code. The above are just some of the feasible processing methods. In practical applications, there can be many other different processing methods, which can be set according to the actual situation.

[0029] Since the instrumented intermediate files cannot be recognized by electronic devices, they need to be converted into files that electronic devices can recognize. This involves analyzing the instrumented intermediate files to determine their type, and then obtaining a conversion program based on the determined type. This program can then convert the instrumented intermediate files into instrumented machine instruction code files. These machine instruction code files can then be provided to the target device, which can load and run the instrumented machine instruction code files according to the original startup method of the time-series database. The target device can be any device capable of running the aforementioned time-series database, such as a server. This server could be the original server to which the time-series database belongs, or a server with a different specified operating environment, depending on the actual situation.

[0030] In step S204, a timing SQL statement that satisfies the timing rules corresponding to the timing database is generated. The timing SQL statement is input into the target device that runs the instrumented machine instruction code file. The target device executes the timing SQL statement during the running of the instrumented machine instruction code file to capture abnormal information that occurs during the operation of the timing database.

[0031] The time series rules can be of various types. For example, the time series rules can be constructed based on the time series characteristics corresponding to the time series database, or the time series rules corresponding to the time series database can be set based on expert experience. The specific rules can be set according to the actual situation, and the embodiments in this specification do not limit this. The abnormal information can be of various types. For example, abnormal information can include time span abnormality, sequence span abnormality, data abnormality, etc. The specific rules can also be set according to the actual situation.

[0032] In implementation, to identify potential bugs in the time-series database, the database can be run and its use simulated under normal conditions to determine possible bugs. Based on this, timing rules corresponding to the time-series database can be pre-defined. The electronic device can then automatically generate timing SQL statements that satisfy these rules. The generated timing SQL statements can include one or more, but in practice, multiple statements can be generated to more comprehensively identify potential bugs. These generated timing SQL statements can then be input into the target device running the instrumented machine instruction code file. The target device can have a pre-configured application that collects specified information and returns it to the electronic device. When the generated timing SQL statements are input into the target device, this application can be launched. The target device executes the timing SQL statements during the running of the instrumented machine instruction code file, generating various related information. This application can capture any anomalies occurring during the time-series database's operation from this generated information and provide this information to the electronic device. The electronic device can then collect the returned anomaly information based on the timing SQL statements input into the target device.

[0033] In step S206, the test results for the security of the time-series database are determined based on the captured anomaly information.

[0034] In practice, after collecting abnormal information through the above methods, the abnormal information can be analyzed. Based on the analysis results, the abnormal information and the input information for the abnormal handling corresponding to the abnormal information can be saved. Based on the saved information, a complete test report for the time series database can be generated, thereby obtaining the test results for the security of the time series database.

[0035] This specification provides a method for testing the security of time-series databases. The method involves compiling and instrumenting the target program code in the time-series database to obtain an instrumented intermediate file. This intermediate file is then converted into an instrumented machine instruction code file. A timing SQL statement that satisfies the timing rules of the time-series database is generated. This timing SQL statement is input into a target device that runs the instrumented machine instruction code file. The target device executes the timing SQL statement during the execution of the instrumented machine instruction code file, capturing any anomalies that occur during the time-series database's operation. Finally, based on the captured anomaly information, the test result for the time-series database security can be determined. Thus, by compiling and instrumenting the target program code in the time-series database and processing the resulting executable file using the generated correct timing SQL statement, the purpose of security testing of the time-series database is automatically achieved. Furthermore, by simply adjusting the above processing, accurate coverage information of multiple components of the time-series database can be obtained, and implicit anomalies that may occur in the time-series database can be dynamically captured, thereby improving the effectiveness of security testing of time-series databases and enabling more effective security testing.

[0036] Example 2

[0037] like Figure 3 As shown in the embodiments of this specification, a testing method for time-series database security is provided. The execution subject of this method can be a terminal device or a server, etc. The terminal device can be a mobile terminal device such as a mobile phone or tablet computer, a computer device such as a laptop or desktop computer, or an IoT device (specifically, a smartwatch, in-vehicle device, etc.). The server can be a single server or a server cluster composed of multiple servers. The server can be a backend server for financial or online shopping services, or a backend server for an application. This embodiment uses a server as the execution subject for detailed description. For the case where the execution subject is a terminal device, please refer to the following server case handling, which will not be repeated here. The method may specifically include the following steps:

[0038] In step S302, the target program code in the time series database to be tested is compiled to obtain multiple intermediate compilation files.

[0039] In this embodiment, the target program code can be program code written in a preset programming language, which may include one or more of the programming languages ​​C, C++ and JAVA, and can be set according to the actual situation.

[0040] In practice, a compiler can be pre-configured based on the above method. This compiler can be used to compile the source files (containing target program code) in the time series database, and can generate multiple intermediate compilation files containing the logical information in the source files.

[0041] In step S304, multiple intermediate compilation files belonging to the same executable file are merged to obtain the full program compilation intermediate file corresponding to the target program code. The basic blocks in the full program compilation intermediate file are instrumented to obtain the instrumented intermediate file corresponding to the target program code.

[0042] A basic block can be a program code consisting of a sequence of statements to be executed sequentially. A basic block has only one entry point and one exit point. The entry point is the first program statement in the basic block, and the exit point is the last program statement in the basic block. When a basic block is executed, it enters only from its entry point and exits only from its exit point. That is, as long as the first instruction in the basic block is executed, all instructions in the basic block will be executed only once in sequence.

[0043] In implementation, a pre-defined full-program optimization mechanism can be used. This mechanism can merge intermediate compilation files and mark the merged information. Based on this, electronic devices can merge multiple intermediate compilation files belonging to the same executable file through the pre-defined full-program optimization mechanism. Simultaneously, it can assign conflict-free labels to the basic blocks contained in the merged file, ultimately obtaining the full-program intermediate compilation file corresponding to the target program code. Static analysis can be performed on this full-program intermediate compilation file, and the analysis results can be exported. Based on the analysis results, instrumentation can be performed on the basic blocks in the full-program intermediate compilation file, thereby obtaining the instrumented intermediate file corresponding to the target program code. This instrumentation can be performed on every basic block in the full-program intermediate compilation file, or on only some basic blocks, depending on the specific requirements.

[0044] In step S306, the instrumented intermediate file is converted into an instrumented machine instruction code file.

[0045] In this embodiment, the instrumented machine instruction code file can be a binary file carrying a memory safety check program.

[0046] In implementation, a security enhancement transformation mechanism can be set according to the actual situation. The security enhancement transformation mechanism can convert the intermediate file obtained after instrumentation into a specified machine instruction code file. Specifically, static analysis can be performed on the instrumented intermediate file and the analysis results can be exported. Based on the analysis results, the above-mentioned security enhancement transformation mechanism can be used to convert the instrumented intermediate file into a binary file carrying a memory security check program.

[0047] In the above embodiment one, step S202 involves compiling and instrumenting the target program code in the timing database to be tested to obtain the instrumented intermediate file corresponding to the target program code. The specific processing of converting the instrumented intermediate file into the instrumented machine instruction code file can also be achieved through the processing of steps 302 to S306 above. Step S202 can also be completed in various different ways. The following provides another optional processing method, which can specifically include the processing of steps A2 and A4.

[0048] In step A2, the target program code in the timing database to be tested is compiled and instrumented to obtain the instrumented intermediate files corresponding to the target program code. There are multiple instrumented intermediate files.

[0049] The specific processing of step A2 above can be found in the relevant content of Embodiment 1 above or the relevant content of steps 302 to S306 above, and will not be repeated here.

[0050] In step A4, multiple instrumented intermediate files belonging to the same executable file are merged to obtain the instrumented full program intermediate file corresponding to the target program code, and the instrumented full program intermediate file is converted into an instrumented machine instruction code file.

[0051] In implementation, an alternative full-program optimization mechanism can be pre-defined. This mechanism can merge instrumented intermediate files and mark the merged information. Based on this, electronic devices can merge multiple instrumented intermediate files belonging to the same executable file using the pre-defined full-program optimization mechanism. Simultaneously, it can assign conflict-free labels to the basic blocks contained in the merged file, ultimately obtaining the instrumented full-program intermediate file corresponding to the target program code. Alternatively, a security-enhanced transformation mechanism can be defined according to the actual situation. This mechanism can convert the instrumented full-program intermediate file into a specified machine instruction code file. Specifically, static analysis can be performed on the instrumented full-program intermediate file, and the analysis results can be exported. Based on the analysis results, the aforementioned security-enhanced transformation mechanism can be used to convert the instrumented full-program intermediate file into a binary file carrying a memory security check program.

[0052] In practical applications, the instrumented machine instruction code file (i.e., the binary file carrying the memory safety check program) obtained above can be provided to the target device. The target device can also have a test program configured, or the test program can be inserted into the instrumented machine instruction code file as an intelligent agent. The electronic device triggers the test program to extract the basic block information contained in the timing database. Based on the extracted basic block information, it can initialize shared memory to store counter information. Then, the test program runs the original startup program of the timing database to initialize the timing database. During initialization, the timing database can obtain the shared memory file in the target device and map the shared memory into the address space of the current process.

[0053] In step S308, a time-series SQL statement that satisfies the time-series rules corresponding to the time-series database is generated based on the time-series features corresponding to the time-series database and / or the preset syntax and semantic rules of the SQL statement.

[0054] In implementation, we will take the generation of time-series SQL statements based on the time-series features corresponding to the time-series database and the preset syntax and semantic rules of SQL statements as an example for detailed explanation. For cases where time-series SQL statements are generated based on either of these two methods, the following processing methods will be used, which will not be elaborated upon here. Electronic devices can first construct a mixed input specification, followed by time-series-oriented variation processing. The mixed input specification describes the rules for constructing structured time-series SQL statements. The mixed input specification can be composed of commonly used SQL statement specifications and the time-series features corresponding to the time-series database. The SQL statement specifications describe the syntax and semantic rules of relational queries, while the time-oriented model describes the keywords and syntax rules of the time series. The SQL statement specifications contain many basic descriptions of SQL queries, which provide the skeleton for the query. Furthermore, the time-oriented model abstracts the time-series features, which provide rules for generating time-series elements. The combination of the above two can yield a mixed input specification, which can provide guidance for generating appropriate time-series SQL statements. That is, time-series SQL statements that meet the time-series rules corresponding to the time-series database can be generated according to the mixed input specification (i.e., the time-series features corresponding to the time-series database and the preset syntax and semantic rules of SQL statements). In practical applications, after initializing the time-series database, time-series SQL statements can be generated randomly and continuously in the above manner.

[0055] The specific processing method of the above step S308 can be varied. The following provides another optional processing method, which may include the processing of step B2 and step B4.

[0056] In step B2, the timing SQL statement is input into the target device that runs the instrumented machine instruction code file. The target device executes the timing SQL statement during the running of the instrumented machine instruction code file to obtain the coverage information of multiple components in the timing database.

[0057] In practice, the generation of time-series SQL statements can be guided by the coverage information of multiple components in the time-series database. Specifically, after mapping shared memory to the address space of the current process and initializing the time-series database, the time-series SQL statements can be input into the target device that runs the instrumented machine instruction code file. The target device executes the time-series SQL statements during the execution of the instrumented machine instruction code file, and collects information generated by all processes in the target device, thereby obtaining the coverage information of multiple components in the time-series database.

[0058] In step B2, a time-series SQL statement that satisfies the time-series rules corresponding to the time-series database is generated based on the time-series characteristics corresponding to the time-series database and / or the preset syntax and semantic rules of the SQL statement, and in combination with the coverage information of multiple components in the time-series database.

[0059] The generated time-series SQL statements can include multiple statements.

[0060] In implementation, based on the time series characteristics corresponding to the time series database and / or the preset syntax and semantic rules of SQL statements, and combined with the coverage information of multiple components in the time series database, time series SQL statements that satisfy the time series rules corresponding to the time series database are randomly generated.

[0061] It should be noted that after the time-series database is started, the electronic device needs to generate time-series SQL statements with correct syntax and semantics and time-series characteristics. The electronic device itself uses a combination of variation rules that conform to syntax and semantics and specifications that meet the characteristics of time series to continuously generate time-series SQL statements. At the same time, it will also continuously obtain feedback on the coverage information of multiple components in the runtime time-series database. The above feedback information will further guide the generation of time-series SQL statements, thereby improving the coverage of server-side code.

[0062] The specific processing of step B2 above can be varied. Here is another optional processing method, which may include the following: Based on the time series characteristics corresponding to the time series database and / or the predefined syntax and semantic rules of the SQL statement, and combined with the coverage information of multiple components in the time series database, generate multiple different time series SQL statements through a predefined mutation strategy. The mutation strategy includes a strategy to modify the time series data corresponding to the target program code or a strategy to modify the time series structure corresponding to the target program code.

[0063] In implementation, a small number of pre-built time-series SQL statements that satisfy the time-series rules corresponding to the time-series database can be used as seeds. These seeds can be mutated at the syntax tree level to generate time-series SQL statements that satisfy the time-series rules corresponding to the time-series database. Specifically, these seeds can be converted into an Abstract Syntax Tree (AST) to better understand and analyze the structured information within them. Compared to the original query statement, the AST provides a more structured and precise format for analyzing the construction and logic of the query. Then, based on the input specifications (i.e., the time-series characteristics corresponding to the time-series database and / or the pre-defined syntax and semantic rules of the SQL statement), the time-series data nodes and time-series structure of the AST are identified. Two mutation strategies are randomly selected (i.e., modifying the time-series data corresponding to the target program code or modifying the time-series structure corresponding to the target program code) to mutate the initial time-series SQL statement, ultimately resulting in multiple time-series SQL statements. Among them, for the strategy of modifying the time series data corresponding to the target program code, the data in the above abstract syntax tree can be modified, and the time series values ​​can be changed to generate new time series SQL statements; for the strategy of modifying the time series structure corresponding to the target program code, the strategy changes the structure of the above abstract syntax tree by deleting, modifying or adding specified nodes based on the above input specification (or the above mixed input specification) to generate new time series SQL statements.

[0064] In step S310, the timing SQL statement is input into the target device that runs the instrumented machine instruction code file. The target device executes the timing SQL statement during the running of the instrumented machine instruction code file to capture abnormal information that occurs during the operation of the timing database.

[0065] In implementation, time-series SQL statements are input into the target device running the instrumented machine instruction code file. The target device executes the time-series SQL statements during the execution of the instrumented machine instruction code file. During the above test, the electronic device actively monitors each thread of the test through the test program. Specifically, error messages from the runtime environment can be captured during the operation of the time-series database. This can be achieved by detecting exception handling code to trace a process of the time-series database. First, the exception handling code is located, and all custom exceptions in the time-series database are obtained to distinguish the types of exceptions. Then, each program that performs implicit exception handling can be scanned to capture error messages, thereby obtaining the exception information that occurs during the operation of the time-series database.

[0066] In step S312, the test results for the security of the time-series database are determined based on the captured anomaly information.

[0067] This specification provides a method for testing the security of time-series databases. The method involves compiling and instrumenting the target program code in the time-series database to obtain an instrumented intermediate file. This intermediate file is then converted into an instrumented machine instruction code file. A timing SQL statement that satisfies the timing rules of the time-series database is generated. This timing SQL statement is input into a target device that runs the instrumented machine instruction code file. The target device executes the timing SQL statement during the execution of the instrumented machine instruction code file, capturing any anomalies that occur during the time-series database's operation. Finally, based on the captured anomaly information, the test result for the time-series database security can be determined. Thus, by compiling and instrumenting the target program code in the time-series database and processing the resulting executable file using the generated correct timing SQL statement, the purpose of security testing of the time-series database is automatically achieved. Furthermore, by simply adjusting the above processing, accurate coverage information of multiple components of the time-series database can be obtained, and implicit anomalies that may occur in the time-series database can be dynamically captured, thereby improving the effectiveness of security testing of time-series databases and enabling more effective security testing.

[0068] Example 3

[0069] The above describes the testing method for time-series database security provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide a testing device for time-series database security, such as... Figure 4 As shown.

[0070] The time-series database security testing apparatus 400 includes: a coverage collection component 410, a time-series SQL statement generation component 420, and an anomaly monitoring component 430. Furthermore, embodiments of this specification also provide a time-series database security testing system, which can be found in [reference needed]. Figure 5 As shown, this includes a test device 400 for time-series database security and a target device 500, wherein:

[0071] The time-series database security testing device 400 can compile and instrument the target program code in the time-series database under test to obtain an instrumented intermediate file corresponding to the target program code. This instrumented intermediate file is then converted into an instrumented machine instruction code file, which is provided to the target device 500. Furthermore, the time-series database security testing device 400 can generate time-series SQL statements that satisfy the timing rules corresponding to the time-series database and input these statements into the target device 500, which runs the instrumented machine instruction code file. Additionally, the time-series database security testing device 400 also captures exception information that occurs during the execution of the instrumented machine instruction code file by the target device 500 executing the time-series SQL statements, and determines the test results for the time-series database security based on the captured exception information.

[0072] The coverage collection component 410 can perform compilation instrumentation on the target program code in the time-series database under test, collect the runtime status of the basic blocks of the time-series database, and also collect coverage information of multiple components in the time-series database during the test. The time-series SQL statement generation component 420 can automatically generate a large number of syntactically and semantically correct time-series SQL statements. The exception monitoring component 430 can actively obtain runtime exception information from the runtime environment during the operation of the time-series database, analyze and deduplicate the exception information, save the time-series input data that can trigger exceptions, and store the aforementioned time-series input data and exception information call stack together.

[0073] The target device 500 can receive the instrumented machine instruction code file sent by the time-series database security testing device 400, and can load and run the instrumented machine instruction code file to run the time-series database. During the execution of the time-series database, it can receive the time-series SQL statement that satisfies the time-series rules corresponding to the time-series database sent by the time-series database security testing device 400, and can run the time-series SQL statement.

[0074] The functions and roles of the various components in the time-series database security testing device 400 can be summarized as follows:

[0075] The coverage collection component 410 is configured to compile and instrument the target program code in the timing database to be tested, obtain the instrumented intermediate file corresponding to the target program code, convert the instrumented intermediate file into an instrumented machine instruction code file, provide the instrumented machine instruction code file to the target device 500, and trigger the target device 500 to run the instrumented machine instruction code file.

[0076] The timing SQL statement generation component 420 is configured to generate timing SQL statements that satisfy the timing rules corresponding to the timing database, and input the timing SQL statements into the target device 500 of the machine instruction code file after instrumentation.

[0077] Coverage collection component 410 is configured to execute time-series SQL statements through the target device during the running of the instrumented machine instruction code file, obtain coverage information of multiple components in the time-series database, and pass the coverage information to time-series SQL statement generation component 420.

[0078] The anomaly monitoring component 430 is configured to execute time-series SQL statements on the target device 500 during the running of the instrumented machine instruction code file, capture anomaly information that occurs during the operation of the time-series database, and determine the test results of the time-series database security based on the captured anomaly information.

[0079] The specific processing procedures for each of the above components can be found in the relevant content of Embodiment 1 and Embodiment 2 above, and will not be repeated here.

[0080] In this embodiment of the specification, the coverage collection component 410 may include a compilation toolchain developed based on the underlying virtual machines LLVM and ASM. This compilation toolchain can be used to perform compilation instrumentation and other processing on the target program code in the time-series database to be tested.

[0081] In the embodiments described in this specification, the anomaly monitoring component 430 may include an agent and an anomaly detector, wherein:

[0082] The agent is configured to execute time-series SQL statements through the target device 500 during the running of the instrumented machine instruction code file, and to obtain exception information from the runtime environment during the operation of the time-series database.

[0083] An anomaly detector is configured to receive anomaly information sent by the agent and, based on this information, determine the test results for the security of the time-series database.

[0084] In implementation, the agent aims to capture error messages from the runtime environment during the operation of the time-series database. Specifically, this is achieved by tracing a process within the time-series database through the inspection of exception handling code. First, the exception handling code is located, and all custom exceptions in the time-series database are retrieved to differentiate their types. Then, each program performing implicit exception handling can be scanned to capture error messages, thus obtaining information on exceptions that occur during the time-series database's operation. The agent can then send this exception information to an exception detector, which can further analyze the information to record and report anomalies. Ultimately, test results on the security of the time-series database can be obtained.

[0085] In the embodiments of this specification, the instrumented intermediate files include multiple ones. The coverage collection component 410 is configured to merge multiple instrumented intermediate files belonging to the same executable file to obtain the instrumented full program intermediate file corresponding to the target program code, and convert the instrumented full program intermediate file into an instrumented machine instruction code file.

[0086] The specific processing steps described above can be found in the relevant content of Embodiment 1 and Embodiment 2 above, and will not be repeated here.

[0087] In the embodiments described in this specification, the target program code is program code written in a preset programming language, which includes one or more of the following programming languages: C, C++, and JAVA.

[0088] In this embodiment of the specification, the coverage collection component 410 is configured to compile the target program code in the time series database to be tested to obtain multiple intermediate compilation files; merge the multiple intermediate compilation files belonging to the same executable file to obtain the full program compilation intermediate file corresponding to the target program code; and instrument the basic blocks in the full program compilation intermediate file to obtain the instrumented intermediate file corresponding to the target program code.

[0089] The specific processing steps described above can be found in the relevant content of Embodiment 1 and Embodiment 2 above, and will not be repeated here.

[0090] In this embodiment of the specification, the time-series SQL statement generation component 420 is configured to generate time-series SQL statements that satisfy the time-series rules corresponding to the time-series database based on the time-series characteristics corresponding to the time-series database and / or the preset syntax and semantic rules of SQL statements.

[0091] The specific processing procedure described above can be found in the relevant content of Embodiment 2 above, and will not be repeated here.

[0092] In this embodiment of the specification, the time-series SQL statement generation component 420 is configured to receive coverage information of multiple components in the time-series database sent by the coverage collection component 410; and generate a time-series SQL statement that satisfies the time-series rules corresponding to the time-series database based on the time-series characteristics corresponding to the time-series database and / or the preset syntax and semantic rules of the SQL statement, combined with the coverage information of multiple components in the time-series database.

[0093] The specific processing procedure described above can be found in the relevant content of Embodiment 2 above, and will not be repeated here.

[0094] In this embodiment of the specification, the generated time-series SQL statements include multiple ones. The time-series SQL statement generation component 420 is configured to generate multiple different time-series SQL statements based on the time series characteristics corresponding to the time series database and / or the preset syntax and semantic rules of the SQL statements, and in combination with the coverage information of multiple components in the time series database, through a preset mutation strategy. The mutation strategy includes a strategy to modify the time series data corresponding to the target program code or a strategy to modify the time series structure corresponding to the target program code.

[0095] In implementation, such as Figure 5 As shown, a robust SQL dictionary (which may include time series features corresponding to the time series database and / or preset syntax and semantic rules of SQL statements, as well as mutation strategies such as strategies for modifying the time series data corresponding to the target program code or strategies for modifying the time series structure corresponding to the target program code, etc., can be set according to the actual situation) and a seed pool (pre-set time series SQL statements that meet the time series rules corresponding to the time series database, etc.) can be used to generate multiple different time series SQL statements through the SQL generator. The specific processing procedure described above can be found in the relevant content of Embodiment 2 above, and will not be repeated here.

[0096] In the embodiments described in this specification, the machine instruction code file after instrumentation is a binary file carrying a memory safety check program.

[0097] In implementation, such as Figure 5 As shown, a binary file carrying a memory safety checker may include binary files for supporting server operation, binary files for supporting client operation, and binary files for specified functional units, etc.

[0098] This specification provides a testing device for time-series database security. It performs compilation and instrumentation on the target program code in the time-series database to be tested, obtaining an instrumented intermediate file. This instrumented intermediate file is then converted into an instrumented machine instruction code file. Next, a time-series SQL statement that satisfies the timing rules corresponding to the time-series database is generated. This time-series SQL statement is input into a target device that runs the instrumented machine instruction code file. The target device executes the time-series SQL statement during the execution of the instrumented machine instruction code file, capturing any anomalies that occur during the time-series database's operation. Finally, based on the captured anomaly information, the test result for the time-series database security can be determined. Thus, by compiling and instrumenting the target program code in the time-series database to be tested, and processing the resulting executable file using the generated correct time-series SQL statement, the purpose of security testing of the time-series database is automatically achieved. Furthermore, by simply adjusting the above processing, accurate coverage information of multiple components of the time-series database can be obtained, and implicit anomalies that may occur in the time-series database can be dynamically captured, thereby improving the effectiveness of time-series database security testing and enabling more effective security testing of time-series databases.

[0099] Example 4

[0100] The above are the time-series database security testing devices provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide a time-series database security testing device, such as... Figure 6 As shown.

[0101] The testing equipment for time-series database security can provide electronic devices, etc., as described in the above embodiments.

[0102] Test equipment for time-series database security can vary significantly due to differences in configuration and performance. It may include one or more processors 601 and memory 602, with memory 602 storing one or more application programs or data. Memory 602 can be temporary or persistent storage. The application programs stored in memory 602 may include one or more modules (not shown), each module including a series of computer-executable instructions for the time-series database security test equipment. Furthermore, processor 601 may be configured to communicate with memory 602 and execute the series of computer-executable instructions in memory 602 on the time-series database security test equipment. The time-series database security test equipment may also include one or more power supplies 603, one or more wired or wireless network interfaces 604, one or more input / output interfaces 605, and one or more keyboards 606.

[0103] Specifically, in this embodiment, the time-series database security testing device includes a memory and one or more programs, wherein one or more programs are stored in the memory, and one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the time-series database security testing device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following:

[0104] The target program code in the timing database to be tested is compiled and instrumented to obtain the instrumented intermediate file corresponding to the target program code, and the instrumented intermediate file is converted into the instrumented machine instruction code file.

[0105] Generate a timing SQL statement that satisfies the timing rules corresponding to the timing database, input the timing SQL statement into the target device that runs the instrumented machine instruction code file, and execute the timing SQL statement through the target device during the running of the instrumented machine instruction code file to capture abnormal information that occurs during the operation of the timing database;

[0106] Based on the captured anomaly information, the test results for the security of the time-series database are determined.

[0107] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the above embodiment of a test device for time-series database security is basically similar to the method embodiment, so the description is relatively simple; relevant parts can be referred to the description of the method embodiment.

[0108] This specification provides a testing device for time-series database security. It performs compilation and instrumentation on the target program code in the time-series database to be tested, obtaining an instrumented intermediate file. This instrumented intermediate file is then converted into an instrumented machine instruction code file. Next, a time-series SQL statement that satisfies the timing rules corresponding to the time-series database is generated. This time-series SQL statement is input into the target device running the instrumented machine instruction code file. The target device executes the time-series SQL statement during the execution of the instrumented machine instruction code file, capturing any anomalies that occur during the time-series database's operation. Finally, based on the captured anomaly information, the test result for the time-series database security can be determined. Thus, by compiling and instrumenting the target program code in the time-series database to be tested, and processing the resulting executable file using the generated correct time-series SQL statement, the purpose of security testing of the time-series database is automatically achieved. Furthermore, by simply adjusting the above processing, accurate coverage information of multiple components of the time-series database can be obtained, and implicit anomalies that may occur in the time-series database can be dynamically captured, thereby improving the effectiveness of time-series database security testing and enabling more effective security testing of time-series databases.

[0109] Example 5

[0110] Furthermore, based on the above Figures 2A to 3 The method shown in this specification, along with one or more embodiments, also provides a storage medium for storing computer-executable instruction information. In one specific embodiment, the storage medium can be a USB flash drive, optical disc, hard disk, etc. When the computer-executable instruction information stored in the storage medium is executed by a processor, it can achieve the following process:

[0111] The target program code in the timing database to be tested is compiled and instrumented to obtain the instrumented intermediate file corresponding to the target program code, and the instrumented intermediate file is converted into the instrumented machine instruction code file.

[0112] Generate a timing SQL statement that satisfies the timing rules corresponding to the timing database, input the timing SQL statement into the target device that runs the instrumented machine instruction code file, and execute the timing SQL statement through the target device during the running of the instrumented machine instruction code file to capture abnormal information that occurs during the operation of the timing database;

[0113] Based on the captured anomaly information, the test results for the security of the time-series database are determined.

[0114] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the above-described storage medium embodiment is basically similar to the method embodiment, so the description is relatively simple; relevant parts can be referred to the description of the method embodiment.

[0115] This specification provides a storage medium that performs compilation and instrumentation on the target program code in a time-series database to be tested, obtaining an instrumented intermediate file corresponding to the target program code. This instrumented intermediate file is then converted into an instrumented machine instruction code file. Next, a timing SQL statement that satisfies the timing rules corresponding to the time-series database is generated. This timing SQL statement is input into a target device that runs the instrumented machine instruction code file. The target device executes the timing SQL statement during the execution of the instrumented machine instruction code file, capturing any anomalies that occur during the time-series database's operation. Finally, based on the captured anomaly information, the security test result for the time-series database can be determined. Thus, by performing compilation and instrumentation on the target program code in the time-series database to be tested, and processing the resulting executable file using the generated correct timing SQL statement, the purpose of security testing of the time-series database is automatically achieved. Furthermore, by simply adjusting the above processing, accurate coverage information of multiple components of the time-series database can be obtained, and implicit anomalies that may occur in the time-series database can be dynamically captured, thereby improving the effectiveness of security testing of the time-series database and enabling more effective security testing of the time-series database.

[0116] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0117] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0118] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0119] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0120] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing one or more embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0121] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0122] Embodiments in this specification are described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable parallel device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable parallel device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0123] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable fraud device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0124] These computer program instructions can also be loaded onto a computer or other programmable device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0125] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0126] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0127] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0128] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0129] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0130] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0131] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0132] The above description is merely an embodiment of this specification and is not intended to limit this application. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A testing method for the security of a time-series database, the method comprising: The target program code in the time series database to be tested is compiled and instrumented to obtain the instrumented intermediate file corresponding to the target program code. The instrumented intermediate file is then converted into an instrumented machine instruction code file. The time series database is used to process data with time tags, which is time series data. Generate a timing SQL statement that satisfies the timing rules corresponding to the timing database, input the timing SQL statement into the target device that runs the instrumented machine instruction code file, and execute the timing SQL statement through the target device during the running of the instrumented machine instruction code file to capture abnormal information that occurs during the operation of the timing database; Based on the captured anomaly information, the test results for the security of the time-series database are determined.

2. The method according to claim 1, wherein the instrumented intermediate files comprise a plurality of files, and the step of converting the instrumented intermediate files into instrumented machine instruction code files comprises: Multiple instrumented intermediate files belonging to the same executable file are merged to obtain the instrumented full program intermediate file corresponding to the target program code, and the instrumented full program intermediate file is converted into an instrumented machine instruction code file.

3. The method according to claim 2, wherein the target program code is program code written in a preset programming language, and the preset programming language includes one or more of the following: C programming language, C++ programming language, and JAVA programming language.

4. The method according to claim 1, wherein the compilation and instrumentation of the target program code in the time series database to be tested to obtain the instrumented intermediate file corresponding to the target program code includes: The target program code in the time series database to be tested is compiled to obtain multiple intermediate compilation files; Multiple intermediate compilation files belonging to the same executable file are merged to obtain the full program compilation intermediate file corresponding to the target program code. The basic blocks in the full program compilation intermediate file are instrumented to obtain the instrumented intermediate file corresponding to the target program code.

5. The method according to any one of claims 1-4, wherein generating a time-series SQL statement that satisfies the time-series rules corresponding to the time-series database comprises: Based on the time series characteristics corresponding to the time series database and / or the preset syntax and semantic rules of SQL statements, generate time series SQL statements that satisfy the time series rules corresponding to the time series database.

6. The method according to claim 5, wherein generating a time-series SQL statement that satisfies the time-series rules corresponding to the time-series database based on the time-series features corresponding to the time-series database and / or the preset syntax and semantic rules of the SQL statement comprises: The timing SQL statement is input into the target device that runs the instrumented machine instruction code file. The target device executes the timing SQL statement during the running of the instrumented machine instruction code file to obtain the coverage information of multiple components in the timing database. Based on the time series characteristics corresponding to the time series database and / or the preset syntax and semantic rules of SQL statements, and combined with the coverage information of multiple components in the time series database, a time series SQL statement that satisfies the time series rules corresponding to the time series database is generated.

7. The method according to claim 6, wherein the generated time-series SQL statement comprises multiple statements, and the step of generating a time-series SQL statement that satisfies the time-series rules corresponding to the time-series database based on the time-series characteristics corresponding to the time-series database and / or preset syntax and semantic rules of SQL statements, and in combination with the coverage information of multiple components in the time-series database, comprises: Based on the time series characteristics corresponding to the time series database and / or the preset syntax and semantic rules of SQL statements, and combined with the coverage information of multiple components in the time series database, multiple different time series SQL statements are generated through a preset mutation strategy. The mutation strategy includes a strategy to modify the time series data corresponding to the target program code or a strategy to modify the time series structure corresponding to the target program code.

8. The method according to claim 7, wherein the instrumented machine instruction code file is a binary file carrying a memory safety check program.

9. A testing apparatus for time-series database security, the apparatus comprising a coverage collection component, a time-series SQL statement generation component, and an anomaly monitoring component, wherein: The coverage collection component is configured to compile and instrument the target program code in the time series database to be tested, obtain the instrumented intermediate file corresponding to the target program code, convert the instrumented intermediate file into an instrumented machine instruction code file, provide the instrumented machine instruction code file to the target device, and trigger the target device to run the instrumented machine instruction code file. The time series database is used to process data with time tags, which is time series data. The timing SQL statement generation component is configured to generate timing SQL statements that satisfy the timing rules corresponding to the timing database, and input the timing SQL statements into the target device that runs the instrumented machine instruction code file; The coverage collection component is configured to execute the time-series SQL statement through the target device during the process of running the instrumented machine instruction code file, obtain the coverage information of multiple components in the time-series database, and pass the coverage information to the time-series SQL statement generation component; The anomaly monitoring component is configured to execute the time-series SQL statement by the target device during the execution of the instrumented machine instruction code file, capture anomaly information that occurs during the operation of the time-series database, and determine the test result of the security of the time-series database based on the captured anomaly information.

10. The apparatus of claim 9, wherein the coverage collection component includes a compilation toolchain developed based on the underlying virtual machines LLVM and ASM.

11. The apparatus of claim 9, wherein the anomaly monitoring component comprises an agent and an anomaly detector, wherein: The agent is configured to execute the time-series SQL statement through the target device during the running of the instrumented machine instruction code file, and to obtain the exception information from the runtime environment during the operation of the time-series database; The anomaly detector is configured to receive the anomaly information sent by the agent and, based on the anomaly information, determine the test result for the security of the time-series database.

12. A testing device for time-series database security, the testing device for time-series database security comprising: processor; as well as A memory configured to store computer-executable instructions, which, when executed, cause the processor to: The target program code in the time series database to be tested is compiled and instrumented to obtain the instrumented intermediate file corresponding to the target program code. The instrumented intermediate file is then converted into an instrumented machine instruction code file. The time series database is used to process data with time tags, which is time series data. Generate a timing SQL statement that satisfies the timing rules corresponding to the timing database, input the timing SQL statement into the target device that runs the instrumented machine instruction code file, and execute the timing SQL statement through the target device during the running of the instrumented machine instruction code file to capture abnormal information that occurs during the operation of the timing database; Based on the captured anomaly information, the test results for the security of the time-series database are determined.

Images