WO2023151436A1

WO2023151436A1 - Sql statement risk detection

Info

Publication number: WO2023151436A1
Application number: PCT/CN2023/071226
Authority: WO
Inventors: 钟泽鑫; 狄鹏; 刘向阳; 刘江潮
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2022-02-08
Filing date: 2023-01-09
Publication date: 2023-08-17
Also published as: CN114547024A

Abstract

An SQL statement risk detection method, apparatus, and device, and a medium. The method comprises: obtaining a binary file corresponding to a target object, and determining whether the binary file comprises a call for a preset operation, wherein the preset operation is an operation of deleting a data table or deleting data in the data table (S101); if the binary file comprises a call for the preset operation, determining whether there is a conditional constraint statement in an SQL statement used for executing the preset operation (S103); and if there is no conditional constraint statement in the SQL statement used for executing the preset operation, determining that the SQL statement has a risk (S105).

Description

SQL statement risk detection

technical field

The present application relates to the field of computer technology, in particular to risk detection of SQL statements.

Background technique

SQL (Structured Query Language) is a database language with multiple functions such as data manipulation and data definition. This language is interactive and can provide users with great convenience. At the same time, improving the security of using SQL is a very important issue. In view of this, a more effective and efficient SQL statement risk detection scheme is needed.

Contents of the invention

The embodiment of this specification provides a SQL statement risk detection method, device, equipment and medium to solve the technical problem of how to perform SQL statement risk detection more effectively and efficiently.

In order to solve the above technical problems, the embodiments of this specification provide the following technical solutions. The embodiment of this specification provides a SQL statement risk detection method, including: obtaining the binary file corresponding to the target object, and judging whether the binary file contains a call to a preset operation; wherein, the preset operation is to delete a data table or delete The operation of the data in the data table; if the binary file contains a call to the preset operation, it is judged whether there is a conditional constraint statement in the SQL statement used to execute the preset operation; if the SQL statement used to execute the preset operation If there is no conditional constraint statement in the SQL statement, it is determined that the SQL statement has risks.

The embodiment of this specification provides a SQL statement risk detection device, including: a call analysis module, which is used to obtain the binary file corresponding to the target object, and judge whether the binary file contains a call to a preset operation; wherein, the preset operation It is the operation of deleting the data table or deleting the data in the data table; the constraint analysis module is used to determine whether the SQL statement used to execute the preset operation has a conditional constraint if the binary file contains a call to the preset operation A statement; a risk analysis module, configured to determine that the SQL statement is risky if there is no conditional constraint statement in the SQL statement used to execute the preset operation.

The embodiment of this specification provides a SQL statement risk detection device, including: at least one processor; and a memory connected to the at least one processor in communication; wherein, the memory stores information that can be executed by the at least one processor An instruction, the instruction is executed by the at least one processor, so that the at least one processor can execute the above SQL statement risk detection method.

An embodiment of the present specification provides a computer-readable storage medium, the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the above SQL statement risk detection method is implemented.

The above-mentioned at least one technical solution adopted in the embodiment of this specification can achieve the following beneficial effects: the above-mentioned technical solution can detect the risk of the SQL statement through static analysis without running the program and the SQL statement, thereby improving the risk of the SQL statement Test effectiveness and efficiency. In particular, the above technical solution can detect whether there is a risk of deleting the data table or deleting data in the data table (especially deleting all data in the data table) in the SQL statement, and further improves the effect of risk detection.

Description of drawings

FIG. 1 is a schematic diagram of an execution subject of the SQL statement risk detection method in the first embodiment of the present specification.

Fig. 2 is a schematic flowchart of the SQL statement risk detection method in the first embodiment of the present specification.

Fig. 3 is a schematic diagram of an intermediate representation in the first embodiment of the present specification.

Fig. 4 is a schematic diagram of a function call graph in the first embodiment of this specification.

Fig. 5 is a schematic diagram of a data flow diagram in the first embodiment of this specification.

Fig. 6 is a schematic structural diagram of the SQL statement risk detection device in the second embodiment of the present specification.

Detailed ways

In order to enable those skilled in the art to better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below in conjunction with the drawings of the embodiments of the present specification. Apparently, the embodiments described in this specification are only some of the embodiments of this application, not all of them. All other embodiments obtained by persons of ordinary skill in the art based on the embodiments in this specification without creative efforts shall fall within the protection scope of the present application.

SQL (Structured Query Language) is a database language with multiple functions such as data manipulation and data definition. This language is interactive and can provide users with great convenience.

However, in a traditional single system application, the invocation of SQL statements can only be triggered within the system by the application itself, and cannot be triggered by external requests or external calls, so the invocation of SQL statements in a single system application is relatively controllable . Because of this, the risk detection of SQL statements has been neglected for a long time.

Moreover, in order to meet the growth of Internet business scale and business complexity, and to meet the needs of rapid system construction and deployment, the traditional single system architecture is gradually replaced by the microservice architecture. Microservice architectures usually support service registration as well as RPC (remote call). A single microservice application can register services in the registry and allow other microservice applications to trigger corresponding operations through RPC using its externally exposed interfaces. This makes the invocation of SQL statements not only triggered in the application, but also triggered by external applications at any time through the RPC interface exposed by the application. It can be seen that due to the externally exposed interfaces in the microservice system, the invocation of SQL statements becomes uncontrollable, and the risks of SQL statements may be exposed to the client along with the externally exposed interfaces.

In particular, some SQL statements have the function of deleting data tables or data in data tables in the database. Once this SQL statement is improperly called, the data table or some or all of the data in the data table may be deleted, and the database will not be able to respond to the data query request for the data table, seriously affecting the security and integrity of the data stored in the database. It will also pose a serious threat to the stability and reliability of the application associated with the data table.

In addition, the detection of SQL statements is usually limited to detection of common problems such as the syntax of SQL statements and SQL implantation, and cannot detect the data table data deletion function of SQL statements.

The first embodiment of this specification (hereinafter referred to as "Embodiment 1") provides a SQL statement risk detection method. The execution subject of Embodiment 1 can be a terminal (including but not limited to mobile phones, computers, pads, TVs) or servers Or an operating system or an application program or a SQL statement risk detection platform or a SQL statement risk detection system, etc., that is, the execution subject can be varied, and the execution subject can be set, used or changed as required. In addition, there may also be a third-party application program assisting the execution subject to execute Embodiment 1. For example, as shown in Figure 1, the SQL statement risk detection method in Embodiment 1 can be executed by the server, and the corresponding application program (with the server) can be installed on the terminal (held by the user), terminal or application Data transmission can be performed between the program and the server, and data collection or input or output or (to the user) page or information processing can be performed through the terminal or application program, thereby assisting the server to execute the SQL statement risk detection method in Embodiment 1.

As shown in Figure 2, the SQL statement risk detection method provided by Embodiment 1 includes: S01: (execution subject) obtain the binary file corresponding to the target object, and judge whether the binary file contains a call to a preset operation; wherein, the The preset operation is an operation of deleting a data table or deleting data in the data table; in the first embodiment, the target object may be various applications (including but not limited to applets and microservice applications).

The execution subject of Embodiment 1 can obtain the binary file corresponding to the target object in a suitable manner. Among them, the user can import the binary file corresponding to the target object into the execution subject of Embodiment 1, or the execution subject of Embodiment 1 can obtain the binary file corresponding to the target object from itself or other subjects according to user operations, or the user can pass other subjects Send the binary file corresponding to the target object to the execution subject of Embodiment 1.

Generally speaking, the binary file is a file that can be executed by a computer to provide the function of the target object. Wherein, the binary file may be a source code or an installation package or a jar package or the like.

After obtaining the binary file corresponding to the target object, the execution subject in Embodiment 1 can determine whether the binary file contains a call to a preset operation. Wherein, the preset operation may be an operation of deleting a data table or deleting data in a data table.

In the first embodiment, the data table is a common form of data storage and a basic element of a database, and the definition of the data table can refer to the prior art.

In Embodiment 1, judging whether the binary file includes a call to a preset operation may include: S011: judging whether the binary file includes a call to a target SQL statement; wherein, the target SQL statement is used to execute the preset operation. Set the SQL statement of operation; The execution of embodiment one can judge whether described binary file comprises the calling of target SQL statement, promptly judge whether described binary file can call target SQL statement, and described target SQL statement is used to execute described SQL statements for preset operations.

In Embodiment 1, it is not necessary to run the binary file to determine whether the binary file contains a call to the target SQL statement, but to use a static analysis method to determine whether the binary file contains a call to the target SQL statement.

In the first embodiment, judging whether the binary file contains a call to the target SQL statement may include: S0111: judging whether the function in the binary file has called the target SQL statement; Whether the function of the function has called the target SQL statement may include: for any function in the binary file, determine the SQL call ID (that is, the ID of the SQL statement called) corresponding to the function; locate the SQL call ID corresponding to the The SQL statement, according to whether the SQL statement corresponding to the SQL call ID is a target SQL statement, determines whether the function in the binary file calls the target SQL statement. That is, for any function in the binary file, if the SQL statement corresponding to the "SQL call ID corresponding to the function" is the target SQL statement, it is determined that the function calls the target SQL statement.

For the convenience of judging whether the function in the binary file has called the target SQL statement, and also for the convenience of judging the SQL call ID corresponding to the function, in Embodiment 1, judging whether the function in the binary file has called the target SQL statement may include : (execution subject of embodiment one) establishes database calling model, and described database calling model is used for characterizing the calling relation of the function in described binary file to SQL statement, namely the database calling situation existing in target object; According to described database The calling model judges whether the function in the binary file calls the target SQL statement (or judges the SQL calling ID corresponding to the function).

Specifically, setting up the database call model may include: scanning all orm framework (such as ibatis, mybatis) related xml files in the binary file, and performing table field modeling on all SQL contained in the xml file, In order to establish a database call model. The database call model includes one or more of the following: the type of the SQL statement called in the binary file; the SQL call ID of the SQL statement called in the binary file; Database table information corresponding to the SQL statement; database field information corresponding to the SQL statement called in the binary file; program variable field information corresponding to the SQL statement called in the binary file.

By establishing a database call model, the association between the "call to SQL statement" and the SQL statement in the binary file can be established, and the call relationship between the function in the binary file and the SQL statement, and the database in the SQL Fields and data variables in the program, the association between fields. For example, for "getSqlMapClientTemplate().queryForObject("MS-LOAD-USER-DETAILS", param)", through the database call model, it is recognized that the loadUserDetail function calls the SQL bound to "MS-LOAD-USER-DETAILS" statement, and it can also be determined that the variables id, name, and email passed in the SQL statement are derived from the local variable param in loadUserDetail, and the query result of the SQL statement will be returned to the qualified phone field and address field information, and Encapsulate the information in an object of the User type and return it to the application program (ie, the target object). That is to say, through the database call model, you can obtain the call relationship between the function and the SQL statement, that is, determine what SQL statement the function calls, and you can also determine the SQL call ID corresponding to the function, and then determine whether the function calls the target SQL statement.

In addition, the execution subject of Embodiment 1 may pre-create an intermediate representation of the binary file, as shown in FIG. 3 for example. The intermediate representation graph is the intermediate representation between the source code of the application program and the target code (that is, the intermediary of translation). Through the intermediate representation graph, the knowledge/information in the application program (that is, the target object) and other related program behaviors and information can be integrated The corresponding algorithm is represented in the form of a graph (that is, nodes and edges) to facilitate abstraction and understanding of program behavior, and to perform efficient specified analysis and operations directly on the graph in sequence. In Embodiment 1, the database call model can be established by means of an intermediate representation graph and static program analysis.

In the first embodiment, if the SQL statement corresponding to the "SQL call ID corresponding to the function" is not the target SQL statement, it can be judged that the function indirectly calls the target SQL statement through the calling relationship between functions. That is, judging whether the function in the binary file has called the target SQL statement may also include: (execution subject of Embodiment 1) setting up the calling relationship between functions in the binary file (that is, the mutual calling relationship between each function); For any function in the binary file, determine the subordinate function of the function according to the calling relationship between the functions; wherein, the subordinate function of the function is the function called by the function; if the subordinate function of the function calls the target SQL statement, it is judged that the function calls the target SQL statement. That is to say, for any function in the binary file, since the function will call its subordinate function, and if the subordinate function of the function calls the target SQL statement, it is equivalent to that the function indirectly calls the target SQL statement.

In Embodiment 1, establishing the inter-function call relationship in the binary file may include: establishing an intermediate representation of the binary file (as described above); based on the intermediate representation, combining a static program analysis algorithm to establish the binary Call relationship between functions in the file. Specifically, the execution subject of Embodiment 1 can establish a function call graph (call graph, such as shown in Figure 4) based on the intermediate representation graph. The node "function" in Figure 4 represents a function, and the edges between nodes represent call relationships or control dependencies. Relationship), through the function call graph, it is convenient to determine the context call relationship between functions in interprocedural analysis, that is, the call relationship between functions, so as to obtain more accurate inter-function call analysis results.

The intermediate representation graph can be divided into linear IR (Intermediate representation), graph IR and hybrid IR according to its structure, and an appropriate intermediate representation graph can be selected in Embodiment 1.

S0113: According to whether the function in the binary file calls the target SQL statement, determine whether the binary file contains a call to the target SQL statement.

If there is a function in the binary file that calls the target SQL statement, then it is judged that the binary file includes a call to the target SQL statement; or, if there is no function in the binary file that calls the target SQL statement, then it is judged that the binary file does not Contains a call to the target SQL statement.

S013: Determine whether the binary file includes a call to a preset operation according to whether the binary file includes a call to a target SQL statement.

If the binary file includes a call to the target SQL statement, it is judged that the binary file includes a call to a preset operation; or, if the binary file does not include a call to the target SQL statement, then it is judged that the binary file does not Contains calls to preset actions.

S03: (execution subject) if the binary file contains a call to a preset operation, then judge whether there is a conditional constraint statement in the SQL statement used to execute the preset operation; if the binary file contains a call to a preset operation , then the execution subject in Embodiment 1 can judge whether there is a conditional constraint statement in the SQL statement (that is, the target SQL statement) used to execute the preset operation.

In Embodiment 1, the relationship between SQL statements can be determined through the database call model, and then it can be determined whether any target SQL statement has a conditional constraint statement.

S05: (execution subject) If the SQL statement used to execute the preset operation does not have a conditional constraint statement, then determine that the SQL statement is at risk.

For any target SQL statement, if the execution subject in Embodiment 1 judges that the target SQL statement does not have a conditional constraint statement, then the execution subject in Embodiment 1 judges that the target SQL statement has a risk. That is, if the target SQL statement does not have a conditional constraint statement, the target SQL statement may be invoked by (the target object or other application program) without constraints, thereby performing preset operations (including deleting data tables or part or all of the data in the data tables) operation), that is, the risk of the target SQL statement is the call risk. If the target SQL statement is an SQL statement used to execute the "delete data table operation", the target SQL statement is called without constraints, which can cause the data table to be deleted; if the target SQL statement is used to execute the "delete data table "Operation of data in" SQL statement, the target SQL statement is invoked without constraints, which can cause the data in the data table (including all data in the data table) to be deleted.

If it is judged that the target SQL statement has a conditional constraint statement, the execution subject of Embodiment 1 determines whether the conditional constraint statement of the target SQL statement is always true. If it is judged that the conditional constraint statement of the target SQL statement is always true, it means that the target SQL statement can still be called without constraints, thus generating the above-mentioned risks of unconstrained calls.

In Embodiment 1, judging whether the conditional constraint statement of the target SQL statement has an ever-true situation may include: establishing a data flow relationship in the binary file, and judging whether the conditional constraint statement of the target SQL statement is There is an everlasting case.

Wherein, judging whether the conditional constraint statement of the target SQL statement is always true according to the data flow relationship may include: determining the database field corresponding to "the conditional constraint statement of the target SQL statement" according to the data flow relationship (in According to the data transfer information in the binary file), the possible assignment information of the database field is judged according to the data transfer information; according to the assignment information, it is judged whether the database field corresponding to "the conditional constraint statement of the target SQL statement" exists permanent True assignment; according to whether the database field corresponding to the "conditional constraint statement of the target SQL statement" has a permanent true value, determine whether the conditional constraint statement of the target SQL statement has a permanent true condition. That is, if there is an ever-true assignment in the conditional constraint statement of the target SQL statement, it is judged that there is an ever-true condition in the conditional constraint statement of the target SQL statement; or, if there is no ever-true assignment in the conditional constraint statement of the target SQL statement, then It is judged that the conditional constraint statement of the target SQL statement does not have an ever-true condition.

In Embodiment 1, establishing the data flow relationship in the binary file may include: establishing an intermediate representation of the binary file (as described above); establishing a call relationship between functions in the binary file based on the intermediate representation (that is, a function call graph); establishing a data flow relationship in the binary file based on the calling relationship between the functions. Wherein, the execution subject of Embodiment 1 generates a data flow graph based on the function call graph (as shown in FIG. 5 , which shows the transmission process of database field x), and the data flow graph includes fields, nodes, and data between description fields. The edges of the transfer relationship (that is, the data dependency relationship), the constraints of the database fields can be determined through the data flow diagram. By solving the constraints, the data flow of any database field in the binary file or target object can be determined, thereby judging the possible assignment of the database field, and then judging whether there is a permanent assignment (that is, 1=1, a = a), that is, to judge whether there is an ever-true situation.

Of course, other data flow analysis algorithms, such as field-based algorithms, may also be used to establish the data flow graph.

In the first embodiment, the database call model can be used to supplement the db call node related to the database operation on the function call graph, and the data flow related to the db operation on the database call model data flow conversion graph can also be used at the same time.

In embodiment one, for any function, if the target SQL statement is called by the function (including indirect calls), it can be judged whether the target SQL statement called by the target has a conditional constraint statement; if the target SQL statement called by the target If there is no conditional constraint statement, the target SQL statement called by the target has the above risks; if there is a conditional constraint statement in the target SQL statement called by the target, then it is judged true; if the conditional constraint statement of the target SQL statement called by the target is always true, then the target SQL statement called by the target has the above risk; or, if the conditional constraint statement of the target SQL statement called by the target is not If there is an ever-true condition, the target SQL statement invoked by the target does not have the above-mentioned risks.

For any target SQL statement, if it is judged that the target SQL statement is risky, the execution subject of Embodiment 1 can locate and highlight the target SQL statement, and can locate and highlight the function that calls the target SQL statement .

In the first embodiment, the binary file can be analyzed through static program analysis means such as syntax analysis, function call modeling, field data flow, etc., to determine the target SQL statement without actually running the application program or the target object or the SQL statement. Whether there is a conditional constraint statement and whether the conditional constraint statement may be true forever, so as to accurately detect the risks of SQL statements, improve the effect and efficiency of SQL statement risk detection, and ensure the security, integrity and goals of data stored in the database Object reliability and stability. Based on this, the "invocation" mentioned in all the above content means that it can be invoked, but not actually invoked, that is, it does not need to actually run the application program or target object or SQL statement.

In particular, Embodiment 1 creatively proposes to detect whether there is a risk of deleting the data table or deleting data in the data table (especially deleting all data in the data table) in the SQL statement, so as to further improve the effect and pertinence of risk detection.

The SQL language and the language in the binary file (that is, the programming language, such as the Java language) are different languages. In the first embodiment, the database calling model can be based on the programming language analysis and program (or Java) related data calling and data flow. , and can analyze the field flow information related to SQL based on the SQL language, and then use the database call model to establish a data flow diagram. Analyze the flow and assignment of database fields in binary files and SQL.

The execution subject of Embodiment 1 may be a blockchain node, and the intermediate representation graph, function call modeling, function call graph, and data flow graph established in Embodiment 1 can be stored in the embodiment after being consensused by the blockchain. In each block chain node of the execution subject, it is prevented from being tampered with in the risk detection process applied to the SQL statement, and the reliability of the risk detection result is improved.

As shown in Figure 6, the second embodiment of this specification provides a SQL statement risk detection device corresponding to the SQL statement risk detection method described in Embodiment 1, including: calling the analysis module 202 to obtain the binary data corresponding to the target object file, judging whether the binary file contains a call to a preset operation; wherein, the preset operation is an operation of deleting a data table or deleting data in a data table; the constraint analysis module 204 is used to determine if the binary file contains To the call of the preset operation, it is judged whether there is a conditional constraint statement in the SQL statement for performing the preset operation; the risk analysis module 206 is used for if there is no conditional constraint statement in the SQL statement for performing the preset operation , it is judged that the SQL statement is risky.

Optionally, the constraint analysis module 204 is configured to determine whether the conditional constraint statement is always true if there is a conditional constraint statement in the SQL statement used to execute the preset operation; the risk analysis module 206, It is used for judging that the SQL statement is risky if the conditional constraint statement is always true.

Optionally, judging whether the binary file contains a call to a preset operation includes: judging whether the binary file contains a call to a target SQL statement; wherein, the target SQL statement is SQL for executing a preset operation statement; according to whether the binary file contains a call to a target SQL statement, determine whether the binary file contains a call to a preset operation.

Optionally, judging whether the binary file contains a call to the target SQL statement includes: judging whether the function in the binary file calls the target SQL statement; according to whether the function in the binary file calls the target SQL statement, It is judged whether the binary file contains a call to the target SQL statement.

Optionally, judging whether the function in the binary file invokes the target SQL statement includes: for any function in the binary file, determining the SQL call ID corresponding to the function; calling the SQL corresponding to the ID according to the SQL Whether the statement is a target SQL statement, and determine whether the function in the binary file invokes the target SQL statement.

Optionally, judging whether the function in the binary file calls the target SQL statement includes: establishing a database call model corresponding to the binary file, and the database call model is used to characterize the SQL statement of the function in the binary file The call relationship; according to the database call model, it is judged whether the function in the binary file calls the target SQL statement.

Optionally, the database call model includes one or more of the following: the type of the SQL statement called in the binary file; the SQL call ID of the SQL statement called in the binary file; database table information corresponding to the SQL statement called in the binary file; database field information corresponding to the SQL statement called in the binary file; program variable field information corresponding to the SQL statement called in the binary file.

Optionally, judging whether the function in the binary file calls the target SQL statement also includes: establishing a call relationship between functions in the binary file; for any function in the binary file, according to the The calling relation determines the subordinate function of the function; wherein, the subordinate function of the function is the function called by the function; if the subordinate function of the function calls the target SQL statement, it is determined that the function calls the target SQL statement.

Optionally, establishing the inter-function calling relationship in the binary file includes: establishing an intermediate representation graph of the binary file; and establishing the inter-function calling relationship in the binary file based on the intermediate representation graph.

Optionally, judging whether the conditional constraint statement is always true includes: establishing a data flow relationship in the binary file, and judging whether the conditional constraint statement is always true according to the data flow relationship.

Optionally, judging whether the conditional constraint statement is always true according to the data flow relationship includes: determining the data flow information of the database field corresponding to the conditional constraint statement according to the data flow relationship; Judging the possible assignment information of the database field based on the transfer information; judging whether there is a permanent assignment in the database field according to the assignment information; judging whether there is a permanent assignment in the conditional constraint statement according to whether there is a permanent assignment in the database field The real situation.

Optionally, establishing the data flow relationship in the binary file includes: establishing an intermediate representation graph of the binary file; establishing a calling relationship between functions in the binary file based on the intermediate representation graph; The calling relationship establishes the data flow relationship in the binary file.

Optionally, the risk in the SQL statement is an invocation risk.

Optionally, the risk analysis module 206 is configured to locate and highlight the risky SQL statement if it is judged that the SQL statement is risky.

The third embodiment of this specification provides a SQL statement risk detection device, including: at least one processor; and a memory connected to the at least one processor in communication; wherein, the memory stores information that can be used by the at least one Instructions executed by the processor, the instructions are executed by the at least one processor, enabling the at least one processor to execute the SQL statement risk detection method described in Embodiment 1.

The fourth embodiment of this specification provides a computer-readable storage medium, the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the SQL statement described in the first embodiment is implemented risk detection method.

The above embodiments can be used in combination, and modules with the same name between different embodiments or within the same embodiment can be the same or different modules.

While the foregoing describes certain embodiments of the specification, other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily have to be followed in the particular order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible or may be advantageous in certain embodiments.

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the apparatus, equipment, and non-volatile computer-readable storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and for relevant parts, please refer to part of the description of the method embodiments.

The device, device, and non-volatile computer-readable storage medium provided in the embodiments of this specification correspond to the method, therefore, the device, device, and non-volatile computer-readable storage medium also have beneficial technical effects similar to those of the corresponding method, because The beneficial technical effects of the method have been described in detail above, therefore, the beneficial technical effects of the corresponding devices, equipment, and non-volatile computer storage media will not be repeated here.

In the 1990s, the improvement of a technology can be clearly distinguished as an improvement in hardware (for example, improvements in circuit structures such as diodes, transistors, and switches) or improvements in software (improvement in method flow). However, with the development of technology, the improvement of many current method flows can be regarded as the direct improvement of the hardware circuit structure. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose logic functions are determined by programming the device by the user. It is programmed by the designer to "integrate" a digital system on a PLD, instead of asking a chip manufacturer to design and make a dedicated integrated circuit chip. Moreover, nowadays, instead of making integrated circuit chips by hand, this kind of programming is mostly realized by "logic compiler (logic compiler)" software, which is similar to the software compiler used when program development and writing, but before compiling The original code of the computer must also be written in a specific programming language, which is called a hardware description language (Hardware Description Language, HDL), and there is not only one kind of HDL, but many kinds, 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, RHDL (Ruby Hardware Description Language), etc., are currently the most commonly used The most popular are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be clear to those skilled in the art that only a little logical programming of the method flow in the above-mentioned hardware description languages and programming into an integrated circuit can easily obtain a hardware circuit for realizing the logic method flow.

The controller may be implemented in any suitable way, for example the controller may take the form of a microprocessor or processor and a computer readable medium storing computer readable program code (such as software or firmware) executable by the (micro)processor , logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), 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 Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that, in addition to realizing the controller in a purely computer-readable program code mode, it is entirely possible to make the controller use logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded The same function can be realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for realizing various functions can also be regarded as structures within the hardware component. Or even, means for realizing various functions can be regarded as a structure within both a software module realizing a method and a hardware component.

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

For the convenience of description, when describing the above devices, functions are divided into various units and described separately. Of course, when implementing this specification, the functions of each unit can be implemented in one or more pieces of software and/or hardware.

Those skilled in the art should understand that the embodiments of this specification may be provided as methods, systems, or computer program products. Accordingly, the embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The specification is described with reference to flowcharts and/or block diagrams of methods, devices (systems), and computer program products according to embodiments of the specification. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

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

Memory may include non-permanent storage in computer readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, 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 technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, A magnetic tape cartridge, magnetic tape disk storage or other magnetic storage device or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes Other elements not expressly listed, or elements inherent in the process, method, commodity, or apparatus are also included. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

The specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The present description may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for relevant parts, refer to part of the description of the method embodiment.

The above descriptions are only examples of the present specification, and are not intended to limit the present application. For those skilled in the art, various modifications and changes may occur in this application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims

A SQL statement risk detection method, comprising:

Obtaining the binary file corresponding to the target object, and judging whether the binary file contains a call to a preset operation; wherein, the preset operation is an operation of deleting a data table or deleting data in a data table;

If the binary file includes a call to a preset operation, it is judged whether there is a conditional constraint statement in the SQL statement used to execute the preset operation;

If the SQL statement used to execute the preset operation does not have a conditional constraint statement, it is determined that the SQL statement is risky.
The method of claim 1, further comprising:

If there is a conditional constraint statement in the SQL statement used to execute the preset operation, then it is judged whether the conditional constraint statement is always true;

If yes, it is determined that the SQL statement is risky.
The method according to claim 1, judging whether the binary file contains calls to preset operations, comprising:

Judging whether the binary file includes a call to a target SQL statement; wherein, the target SQL statement is an SQL statement for performing a preset operation;

Whether the binary file includes a call to a preset operation is determined according to whether the binary file includes a call to a target SQL statement.
The method according to claim 3, judging whether the binary file contains a call to the target SQL statement, comprising:

Judging whether the function in the binary file calls the target SQL statement;

According to whether the function in the binary file calls the target SQL statement, it is judged whether the binary file contains the call of the target SQL statement.
The method according to claim 4, judging whether the function in the binary file calls the target SQL statement, comprising:

For any function in the binary file, determine the SQL call ID corresponding to the function;

According to whether the SQL statement corresponding to the SQL call ID is a target SQL statement, it is judged whether the function in the binary file calls the target SQL statement.
The method according to claim 4, judging whether the function in the binary file calls the target SQL statement, comprising:

Set up the corresponding database calling model of described binary file, described database calling model is used for characterizing the calling relation of the function in described binary file to SQL statement;

It is judged according to the database calling model whether the function in the binary file calls the target SQL statement.
The method of claim 6, said database call model comprising one or more of the following:

The type of the SQL statement called in the binary file;

The SQL call ID of the SQL statement called in the binary file;

The database table information corresponding to the SQL statement called in the binary file;

The database field information corresponding to the SQL statement called in the binary file;

The program variable field information corresponding to the SQL statement called in the binary file.
The method according to any one of claims 1 to 7, judging whether the function in the binary file calls the target SQL statement, further comprising:

Establish a calling relationship between functions in the binary file;

For any function in the binary file, determine the subordinate function of the function according to the calling relationship between the functions; wherein, the subordinate function of the function is the function called by the function;

If the subordinate function of the function calls the target SQL statement, it is judged that the function calls the target SQL statement.
The method according to claim 8, establishing the calling relationship between functions in the binary file, comprising:

building an intermediate representation of said binary file;

The inter-function call relationship in the binary file is established based on the intermediate representation graph.
The method according to claim 2, judging whether there is an ever-true situation in the conditional constraint statement, comprising:

Establishing a data flow relationship in the binary file, and judging whether the conditional constraint statement is always true according to the data flow relationship.
The method according to claim 10, judging whether the conditional constraint statement is always true according to the data flow relationship, comprising:

According to the data flow relationship, determine the data flow information of the database field corresponding to the conditional constraint statement;

judging possible assignment information of the database field according to the data flow information;

judging whether there is a permanent true assignment in the database field according to the assignment information;

According to whether there is a permanent true assignment in the database field, it is judged whether there is a permanent true condition in the conditional constraint statement.
The method according to claim 10 or 11, establishing the data flow relationship in the binary file, comprising:

building an intermediate representation of said binary file;

establishing a calling relationship between functions in the binary file based on the intermediate representation;

The data flow relationship in the binary file is established based on the calling relationship between the functions.
The method according to claim 1 or 2, wherein the risk of the SQL statement is a call risk.
The method according to claim 1 or 2, said method further comprising:

If it is judged that the SQL statement is risky, then locate and highlight the risky SQL statement; or, locate and highlight a function that calls the risky SQL statement.
A SQL statement risk detection device, comprising:

calling the analysis module, used to obtain the binary file corresponding to the target object, and judge whether the binary file contains a call to a preset operation; wherein, the preset operation is an operation of deleting a data table or deleting data in a data table;

A constraint analysis module, configured to determine whether there is a conditional constraint statement in the SQL statement used to execute the preset operation if the binary file contains a call to the preset operation;

A risk analysis module, configured to judge that the SQL statement is risky if there is no conditional constraint statement in the SQL statement used to execute the preset operation.
A SQL statement risk detection device, comprising:

at least one processor;

as well as,

memory communicatively coupled to the at least one processor;

in,

The memory stores instructions executable by the at least one processor, the instructions are executed by the at least one processor, enabling the at least one processor to perform the method described in any one of claims 1 to 14 SQL statement risk detection method.
A computer-readable storage medium, the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the SQL statement risk detection described in any one of claims 1 to 14 is implemented method.