Threat detection method and device, electronic equipment, storage medium and program product
By using a business identifier and whitelist approach to identify high-risk SQL requests, this technology addresses the low accuracy of existing SQL injection defense techniques and achieves more efficient threat detection.
Patent Information
- Application Number
- CN202610057479.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-01-16
- Publication Date
- 2026-04-14
AI Technical Summary
In existing technologies, SQL injection defense techniques have difficulty accurately distinguishing between malicious commands and complex normal business queries, resulting in low accuracy in threat detection.
Based on the business identifier of the current SQL request, the target SQL request is determined using a pre-set whitelist. If the current SQL request does not exist, it is determined to be a high-risk SQL request, and a risk score is performed to obtain the risk confidence level. The SQL request is then responded to based on the confidence level.
It improves the accuracy of threat detection, enabling it to identify whether SQL requests are triggered by legitimate business processes and distinguish between malicious commands and normal business queries.
Smart Images
Figure CN121864440A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of information security technology, and in particular to threat detection methods, devices, electronic equipment, storage media, and program products. Background Technology
[0002] SQL (Structured Query Language) injection attacks are a common and highly dangerous type of cyberattack that involves inserting malicious SQL code into the input parameters of a Web (World Wide Web) application, thereby deceiving the backend database into executing unexpected commands.
[0003] In existing technologies, SQL injection defense techniques (exemplary examples include Web Application Firewalls (WAFs)) are primarily deployed at the web application layer or middleware layer. The core principle of this technology is to utilize feature matching or behavioral models to detect SQL injection when an HTTP (Hypertext Transfer Protocol) request arrives or when an SQL statement is generated in the application's memory.
[0004] However, this method's judgment logic is still largely based on static rules or simple learning of the SQL statement itself. It cannot understand whether the SQL statement was triggered by a legitimate business process, making it difficult to accurately distinguish between malicious commands and complex, normal business queries, resulting in low accuracy. Summary of the Invention
[0005] This invention provides a threat detection method, apparatus, electronic device, storage medium, and program product for identifying high-risk SQL requests and improving the accuracy of threat detection.
[0006] According to one aspect of the present invention, a threat detection method is provided, the method comprising: For any current Structured Query Language (SQL) request stored in the database, determine the first target business corresponding to the current SQL request based on the business identifier in the current SQL request; Using a pre-set whitelist, each target SQL request corresponding to the first target business is determined, wherein the whitelist includes the correspondence between each business and each SQL request; If it is determined that the current SQL request does not exist among the target SQL requests, then the current SQL request is determined to be a high-risk SQL request; A risk score is performed on the current SQL request to obtain the risk confidence level of the current SQL request; The current SQL request is responded to using the execution action corresponding to the risk confidence level.
[0007] According to another aspect of the present invention, a threat detection device is provided, the device comprising: The business determination module is used to determine the first target business corresponding to any SQL request stored in the database, based on the business identifier in the current SQL request. The target SQL request determination module is used to determine each target SQL request corresponding to the first target business by using a pre-set whitelist, wherein the whitelist includes the correspondence between each business and each SQL request; The risk identification module is used to determine that the current SQL request is a high-risk SQL request if it is determined that the current SQL request does not exist among the target SQL requests. The scoring module is used to score the risk of the current SQL request and obtain the risk confidence level of the current SQL request. The response module is used to respond to the current SQL request with an action corresponding to the risk confidence level.
[0008] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the threat detection method according to any embodiment of the present invention.
[0009] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the threat detection method according to any embodiment of the present invention.
[0010] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the threat detection method as described in any embodiment of the present invention.
[0011] The technical solution of this invention determines a first target business corresponding to the current SQL request based on the business identifier in the current SQL request; uses a pre-set whitelist to determine each target SQL request corresponding to the first target business; if the current SQL request is not found among the target SQL requests, the current SQL request is determined to be a high-risk SQL request; performs a risk score on the current SQL request to obtain its risk confidence level; and responds to the current SQL request using an execution action corresponding to the risk confidence level. Therefore, this embodiment associates SQL requests with business processes, enabling the identification of whether an SQL statement is triggered by a legitimate business process. Furthermore, by using a whitelist for threat detection of SQL, it can distinguish between malicious commands and complex normal business queries, improving the accuracy of threat detection.
[0012] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description
[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0014] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of the present invention; Figure 2 This is a flowchart illustrating the threat detection method provided according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the process for determining a whitelist according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the process for determining risk confidence level according to an embodiment of the present invention; Figure 5 This is a flowchart illustrating the threat detection method provided according to an embodiment of the present invention; Figure 6 This is a schematic diagram of a threat detection device provided according to an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device that implements the threat detection method provided in the embodiments of the present invention. Detailed Implementation
[0015] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0016] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0017] Before introducing the risk identification method provided in the embodiments of this application, for ease of understanding, the technical background of the embodiments of this application will be described in detail below.
[0018] In existing technologies, the judgment logic of SQL injection defense techniques is still mostly based on static rules or simple learning of the SQL statement itself. This fails to understand whether the SQL statement was triggered by a legitimate business process, making it difficult to accurately distinguish between malicious commands and complex, normal business queries, resulting in low accuracy in identification.
[0019] In view of this, this application provides a threat detection method. Based on the business identifier in the current SQL request, a first target business corresponding to the current SQL request is determined. Using a pre-set whitelist, each target SQL request corresponding to the first target business is identified. If the current SQL request is not found among the target SQL requests, it is determined to be a high-risk SQL request. A risk score is performed on the current SQL request to obtain its risk confidence level. Finally, an execution action corresponding to the risk confidence level is used to respond to the current SQL request. Therefore, this embodiment associates SQL requests with business processes, enabling the identification of whether SQL statements are triggered by legitimate business flows. Furthermore, using a whitelist for threat detection of SQL queries can distinguish between malicious instructions and complex, normal business queries, improving the accuracy of threat detection.
[0020] Before introducing the threat detection method in this application, we will first introduce the application scenarios of the threat detection method in this application. Figure 1 This is a schematic diagram of an application scenario, from Figure 1 As can be seen from the above, this application scenario includes server 110 and terminal device 120. In this embodiment, server 110 can be implemented as a physical server or as a virtual server.
[0021] In one possible application scenario, server 110, for any current Structured Query Language (SQL) request stored in the database, determines a first target business corresponding to the current SQL request based on the business identifier in the current SQL request. Then, server 110 uses a pre-set whitelist to determine each target SQL request corresponding to the first target business, wherein the whitelist includes the correspondence between each business and each SQL request. If it is determined that the current SQL request is not among the target SQL requests, server 110 determines that the current SQL request is a high-risk SQL request; and performs a risk score on the current SQL request to obtain a risk confidence level for the current SQL request; server 110 responds to the current SQL request using an action corresponding to the risk confidence level, and displays the response result on terminal device 120.
[0022] in, Figure 1 The server 110 and the terminal device 120 can exchange information through a communication network. The communication network can be either wireless or wired.
[0023] For example, server 110 can access the network via cellular mobile communication technology and communicate with terminal device 120, wherein the cellular mobile communication technology includes, for example, 5th generation mobile networks (5G) technology.
[0024] Optionally, server 110 can access the network and communicate with terminal device 120 via short-range wireless communication, wherein the short-range wireless communication method includes, for example, Wireless Fidelity (Wi-Fi) technology.
[0025] Furthermore, the description in this application focuses only on a single server 110 and a single terminal device 120. However, those skilled in the art should understand that the illustrated server 110 and terminal device 120 are intended to illustrate the operation of the server 110 and terminal device 120 involved in the technical solutions of this application, and are not intended to imply any limitation on the number, type, or location of the server 110 and terminal device 120. It should be noted that adding additional modules to or removing individual modules from the illustrated environment will not change the underlying concept of the exemplary embodiments of this application.
[0026] It should be noted that the threat detection method proposed in this application is not only applicable to... Figure 1 The application scenarios shown are also applicable to any threat detection device.
[0027] For example, terminal device 120 includes, but is not limited to: large visual screens, tablet computers, laptops, handheld computers, mobile internet devices (MID), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminal devices in industrial control, wireless terminal devices in autonomous driving, wireless terminal devices in smart grids, wireless terminal devices in transportation safety, wireless terminal devices in smart cities, or wireless terminal devices in smart homes, etc.; the terminal device may have a related client installed, which may be software (e.g., browsers, short video software, etc.), or web pages, mini-programs, etc.
[0028] The following describes an exemplary embodiment of the threat detection method of this application in conjunction with the application scenarios described above and with reference to the accompanying drawings. It should be noted that the above application scenarios are only shown to facilitate understanding of the methods and principles of this application, and the implementation of this application is not limited in any way in this respect.
[0029] The threat detection method in the embodiments of this application will be described in detail below. Figure 2 A flowchart of a threat detection method provided in an embodiment of the present invention, the method comprising: S201: For any SQL request stored in the database, determine the first target service corresponding to the current SQL request based on the service identifier in the current SQL request; In this embodiment, a real-time SQL execution detail acquisition module is established on the database side. This acquisition module can capture all SQL requests arriving at the database and ready for execution, along with their context information. The context information in this embodiment includes, but is not limited to, execution timestamp, executing user / application account, client IP and port, and database session ID. Optional information may include: execution plan summary and number of rows affected.
[0030] Furthermore, this embodiment establishes standardized business logic log points on the web application side. That is, log recording points are embedded in the code of each business to record the business logs of each business. The business logs in this embodiment include, but are not limited to: business identifier, business operation type, operation timestamp, initiating user identifier, session ID, and key business parameters.
[0031] This application establishes a tracking identifier transmission link. It ensures that the unique business identifier of a business request initiated from the web client can be passed to the database driver layer through the application context (such as ThreadLocal, HTTP Header), and ultimately appended to all SQL requests triggered by that business request through comments or specific connection attributes. For example, the business identifier can be added as an SQL comment at the beginning of the SQL request.
[0032] In one embodiment, S201 can be specifically implemented as follows: using a pre-set correspondence between service identifiers and services, determine the first target service corresponding to the service identifier in the current SQL request. Table 1 shows the correspondence between service identifiers and services: Table 1 For example, taking the correspondence in Table 1 as an example, if the business identifier of the current SQL request is 'a', then the first target business is determined to be business 1.
[0033] S202: Using a pre-set whitelist, determine each target SQL request corresponding to the first target service, wherein the whitelist includes the correspondence between each service and each SQL request; The method for determining the whitelist in the embodiments of this application will be described below. Figure 3 A flowchart illustrating the process of determining the whitelist may include the following steps: S301: For any SQL request, based on the business identifier in the SQL request, determine whether there is a second target business corresponding to the SQL request; if yes, execute S302; if no, execute S304. In one possible embodiment, S301 can be specifically implemented as follows: using pre-set correspondences between service identifiers and services, determine whether there is a corresponding second target service for the service identifier in the SQL request.
[0034] S302: Using the pre-set correspondence between each SQL request and operation type, determine whether the operation type corresponding to the current SQL request is a high-risk type. If not, execute S303; if yes, execute S304. The high-risk operation types in this application embodiment include UNION SELECT, etc.; the high-risk types are pre-set, and this application embodiment does not limit them.
[0035] S303: Add the SQL request and the corresponding second target service to the whitelist; S304: Input the SQL request into a pre-trained abnormal SQL recognition model to obtain a first recognition result, and send the first recognition result and the SQL request to the target electronic device for manual recognition. When the second recognition result sent by the target electronic device is received, if the second recognition result determines that the SQL request is not a high-risk SQL request, then add the SQL request and the second target service corresponding to the SQL request to the whitelist.
[0036] In this embodiment, the SQL request and the execution details of the SQL request are both input into the first recognition result obtained by the pre-trained abnormal SQL recognition model.
[0037] Therefore, by confirming the correspondence between each SQL request in the whitelist and each business through human-machine collaboration, the accuracy of the determined whitelist is ensured, and the accuracy of subsequent threat detection is further improved.
[0038] S203: If it is determined that the current SQL request does not exist among the target SQL requests, then the current SQL request is determined to be a high-risk SQL request; S204: Perform a risk score on the current SQL request to obtain the risk confidence level of the current SQL request; The method for determining the risk confidence level in embodiment S204 of this application will be described below. Figure 4 A flowchart for determining risk confidence levels may include the following steps: S401: Retrieves the execution details of the current SQL request, which include data type, operation type, execution environment, and execution frequency; The data types in this application's embodiments include core data, ordinary data, and non-sensitive data. The operation types in this application's embodiments may include DROP, TRUNCATE, DELETE, UPDATE, and SELECT types. The execution environments in this application's embodiments include, but are not limited to, production environments, pre-production environments, and testing environments. The execution frequencies in this application's embodiments include, but are not limited to, high-frequency execution and single-execution.
[0039] S402: Using the pre-set correspondence between each data type and each data sensitivity score, determine the target data sensitivity score corresponding to the data type of the current SQL request; The core data in this application's embodiments is the data sensitivity score. Data sensitivity score for ordinary data The data sensitivity score for non-sensitive data. However, this application embodiment does not limit the specific value of the data sensitivity score corresponding to each data type. The data sensitivity score corresponding to each data type in this application embodiment can be set according to the specific actual situation.
[0040] S403: Using the pre-set correspondence between each operation type and each operation exception score, determine the target operation exception score corresponding to the operation type of the current SQL request; In this embodiment, the operation exception scores for DROP, TRUNCATE, and DELETE types are the same and are the highest among all operation types. The operation exception score for SELECT type is the lowest among all operation types. The operation exception score for UPDATE type is higher than that for SELECT type, but lower than that for DROP, TRUNCATE, and DELETE types.
[0041] However, this application embodiment does not limit the specific value of the operation anomaly score corresponding to each operation type. The operation anomaly score corresponding to each operation type in this application embodiment can be set according to the specific actual situation.
[0042] S404: Using the pre-set correspondence between each execution environment and each environment anomaly score, determine the target environment anomaly score corresponding to the execution environment of the current SQL request; In this application embodiment, the environmental anomaly score corresponds to the production environment. Environmental anomaly score corresponding to the pre-release environment The test environment corresponds to an environment anomaly score. However, this embodiment does not limit the specific value of the environment anomaly score for each execution environment. The environment anomaly score for each execution environment in this embodiment can be set according to the specific actual situation.
[0043] S405: Using the pre-set correspondence between execution frequencies and execution exception scores, determine the target execution exception score corresponding to the execution frequency of the current SQL request; In this embodiment, the execution exception score for high-frequency execution is greater than the execution exception score for a single execution. However, this embodiment does not limit the specific value of the execution exception score corresponding to each execution frequency; the execution exception score corresponding to each execution frequency in this embodiment can be set according to specific actual conditions.
[0044] S406: The risk confidence score of the current SQL request is obtained by weighted summing of the target data sensitivity score, target operation anomaly score, target environment anomaly score, and target execution anomaly score. The risk confidence score can be obtained using formula (1): ...(1); in, For risk confidence level, For the target data sensitivity score, The target is the score for abnormal operations. The target environment anomaly score, The target is to be assigned an anomaly score, where A, B, C, and D are pre-set weights.
[0045] Therefore, in this embodiment of the application, the risk confidence level of the SQL request is determined by the multi-dimensional characteristics of the SQL request, thus ensuring the accuracy of the determined SQL request.
[0046] S205: Respond to the current SQL request using the execution action corresponding to the risk confidence level.
[0047] In one possible embodiment, S205 can be specifically implemented as follows: if the risk confidence level is greater than a specified threshold, then the current SQL request is blocked; if the risk confidence level is not greater than the specified threshold, then the SQL request is isolated or slowed down.
[0048] It should be noted that the specified threshold in this application embodiment can be set according to the specific actual situation, and this application embodiment does not limit the specific value of the specified threshold.
[0049] Therefore, in this embodiment of the application, the response is based on the risk confidence level of the SQL request to ensure data security.
[0050] To further connect with the threat detection method in this application, Figure 5 This is a flowchart illustrating a threat detection method, which may include the following steps: S501: For any SQL request, based on the business identifier in the SQL request, determine whether there is a second target business corresponding to the SQL request; if yes, then execute S502; if no, then execute S504. S502: Using the pre-set correspondence between each SQL request and operation type, determine whether the operation type corresponding to the current SQL request is a high-risk type. If not, execute S503; if yes, execute S504. S503: Add the SQL request and the corresponding second target service to the whitelist; S504: Input the SQL request into a pre-trained abnormal SQL recognition model to obtain a first recognition result, and send the first recognition result and the SQL request to the target electronic device for manual recognition. When the second recognition result sent by the target electronic device is received, if the second recognition result determines that the SQL request is not a high-risk SQL request, then add the SQL request and the second target service corresponding to the SQL request to the whitelist. S505: For any current Structured Query Language (SQL) request stored in the database, determine the first target business corresponding to the current SQL request based on the business identifier in the current SQL request; S506: Using a pre-set whitelist, determine each target SQL request corresponding to the first target service, wherein the whitelist includes the correspondence between each service and each SQL request; S507: If it is determined that the current SQL request does not exist among the target SQL requests, then the current SQL request is determined to be a high-risk SQL request; S508: Perform a risk score on the current SQL request to obtain the risk confidence level of the current SQL request; S509: Determine whether the risk confidence level is greater than the specified threshold. If yes, proceed to S510; otherwise, proceed to S511. S510: Block the current SQL request; S511: Isolate or slow down the SQL request.
[0051] Based on the same inventive concept, this application also provides a threat detection device. Figure 6 This is a schematic diagram of the threat detection device. Figure 6 As shown, the device 600 includes: The business determination module 610 is used to determine the first target business corresponding to any current structured query language (SQL) request stored in the database, based on the business identifier in the current SQL request. The target SQL request determination module 620 is used to determine each target SQL request corresponding to the first target business by using a pre-set whitelist, wherein the whitelist includes the correspondence between each business and each SQL request; The risk identification module 630 is used to determine that the current SQL request is a high-risk SQL request if it is determined that the current SQL request does not exist among the target SQL requests; The scoring module 640 is used to score the risk of the current SQL request and obtain the risk confidence level of the current SQL request. The response module 650 is used to respond to the current SQL request using an execution action corresponding to the risk confidence level.
[0052] In one possible embodiment, the device further includes: The whitelist determination module 660 is used to determine the whitelist in the following ways: For any given SQL request, based on the business identifier in the SQL request, determine whether there exists a second target business corresponding to the SQL request; If such a situation exists, and the operation type corresponding to the SQL request is not a high-risk type, then the SQL request and the second target business corresponding to the SQL request are added to the whitelist. Otherwise, the SQL request is input into a pre-trained abnormal SQL recognition model to obtain a first recognition result. The first recognition result and the SQL request are then sent to the target electronic device for manual recognition. When the second recognition result sent by the target electronic device is received, if the second recognition result determines that the SQL request is not a high-risk SQL request, the SQL request and the second target service corresponding to the SQL request are added to the whitelist.
[0053] In one possible embodiment, the scoring module 640 is specifically used for: Obtain the execution details of the current SQL request, wherein the execution details include data type, operation type, execution environment, and execution frequency; By utilizing the pre-defined correspondence between various data types and data sensitivity scores, the target data sensitivity score corresponding to the data type of the current SQL request is determined; By utilizing the pre-defined correspondence between each operation type and each operation exception score, the target operation exception score corresponding to the operation type of the current SQL request is determined; By utilizing the pre-set correspondence between each execution environment and each environment anomaly score, the target environment anomaly score corresponding to the execution environment of the current SQL request is determined; By utilizing the pre-defined correspondence between execution frequencies and execution exception scores, the target execution exception score corresponding to the execution frequency of the current SQL request is determined. The risk confidence of the current SQL request is obtained by weighted summing of the target data sensitivity score, target operation anomaly score, target environment anomaly score, and target execution anomaly score.
[0054] In one possible embodiment, the response module 650 is specifically used for: If the risk confidence level is greater than a specified threshold, then the current SQL request is blocked; If the risk confidence level is not greater than the specified threshold, the SQL request is isolated or slowed down.
[0055] In one possible embodiment, the service determination module 610 is specifically used for: By utilizing the pre-set correspondence between various business identifiers and businesses, the first target business corresponding to the business identifier in the current SQL request is determined.
[0056] The threat detection device provided in the embodiments of the present invention can execute the threat detection method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.
[0057] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.
[0058] Figure 7A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.
[0059] like Figure 7 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.
[0060] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0061] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as threat detection methods.
[0062] In some embodiments, the threat detection method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the threat detection method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the threat detection method by any other suitable means (e.g., by means of firmware).
[0063] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0064] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0065] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.
[0066] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0067] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.
[0068] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through a communication network. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.
[0069] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.
[0070] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.
Claims
1. A threat detection method, characterized by, The method includes: For any current Structured Query Language (SQL) request stored in the database, determine the first target business corresponding to the current SQL request based on the business identifier in the current SQL request; Using a pre-set whitelist, each target SQL request corresponding to the first target business is determined, wherein the whitelist includes the correspondence between each business and each SQL request; If it is determined that the current SQL request does not exist among the target SQL requests, then the current SQL request is determined to be a high-risk SQL request; A risk score is performed on the current SQL request to obtain the risk confidence level of the current SQL request; The current SQL request is responded to using the execution action corresponding to the risk confidence level.
2. The method of claim 1, wherein, The whitelist is determined in the following ways: For any given SQL request, based on the business identifier in the SQL request, determine whether there exists a second target business corresponding to the SQL request; If such a situation exists, and the operation type corresponding to the SQL request is not a high-risk type, then the SQL request and the second target business corresponding to the SQL request are added to the whitelist. Otherwise, the SQL request is input into a pre-trained abnormal SQL recognition model to obtain a first recognition result. The first recognition result and the SQL request are then sent to the target electronic device for manual recognition. When the second recognition result sent by the target electronic device is received, if the second recognition result determines that the SQL request is not a high-risk SQL request, the SQL request and the second target service corresponding to the SQL request are added to the whitelist.
3. The method of claim 1, wherein, The step of performing a risk score on the current SQL request to obtain the risk confidence level of the current SQL request includes: Obtain the execution details of the current SQL request, wherein the execution details include data type, operation type, execution environment, and execution frequency; By utilizing the pre-defined correspondence between various data types and data sensitivity scores, the target data sensitivity score corresponding to the data type of the current SQL request is determined; By utilizing the pre-defined correspondence between each operation type and each operation exception score, the target operation exception score corresponding to the operation type of the current SQL request is determined; By utilizing the pre-set correspondence between each execution environment and each environment anomaly score, the target environment anomaly score corresponding to the execution environment of the current SQL request is determined; By utilizing the pre-defined correspondence between execution frequencies and execution exception scores, the target execution exception score corresponding to the execution frequency of the current SQL request is determined. The risk confidence of the current SQL request is obtained by weighted summing of the target data sensitivity score, target operation anomaly score, target environment anomaly score, and target execution anomaly score.
4. The method of claim 1, wherein, The step of responding to the current SQL request using the execution action corresponding to the risk confidence level includes: If the risk confidence level is greater than a specified threshold, then the current SQL request is blocked; If the risk confidence level is not greater than the specified threshold, the SQL request is isolated or slowed down.
5. The method according to any one of claims 1 to 4, characterized in that, The step of determining the first target service corresponding to the current SQL request based on the service identifier in the current SQL request includes: By utilizing the pre-set correspondence between various business identifiers and businesses, the first target business corresponding to the business identifier in the current SQL request is determined.
6. A threat detection apparatus, characterized by, The device includes: The business determination module is used to determine the first target business corresponding to any current structured query language (SQL) request stored in the database, based on the business identifier in the current SQL request. The target SQL request determination module is used to determine each target SQL request corresponding to the first target business by using a pre-set whitelist, wherein the whitelist includes the correspondence between each business and each SQL request; The risk identification module is used to determine that the current SQL request is a high-risk SQL request if it is determined that the current SQL request does not exist among the target SQL requests. The scoring module is used to score the risk of the current SQL request and obtain the risk confidence level of the current SQL request. The response module is used to respond to the current SQL request with an action corresponding to the risk confidence level.
7. The apparatus of claim 6, wherein, The device further includes: The whitelist determination module is used to determine the whitelist in the following ways: For any given SQL request, based on the business identifier in the SQL request, determine whether there exists a second target business corresponding to the SQL request; If such a situation exists, and the operation type corresponding to the SQL request is not a high-risk type, then the SQL request and the second target business corresponding to the SQL request are added to the whitelist. Otherwise, the SQL request is input into a pre-trained abnormal SQL recognition model to obtain a first recognition result. The first recognition result and the SQL request are then sent to the target electronic device for manual recognition. When the second recognition result sent by the target electronic device is received, if the second recognition result determines that the SQL request is not a high-risk SQL request, the SQL request and the second target service corresponding to the SQL request are added to the whitelist.
8. An electronic device, comprising: The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the threat detection method according to any one of claims 1-5.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the threat detection method according to any one of claims 1-5.
10. A computer program product, characterised in that, The computer program product includes a computer program that, when executed by a processor, implements the threat detection method according to any one of claims 1-5.