Vulnerability Scanning Method, Device, Storage Medium and Computer Equipment

Abstract

An embodiment of the present application provides a vulnerability scanning method, device, storage medium, and computer device. By obtaining a flow graph description, the flow graph description is compiled from the proof-of-concept names of multiple proofs-of-concept in a proof-of-concept library according to flow graph rules; converting the flow graph description into a syntax tree, the syntax tree includes the proof-of-concept names of each proof-of-concept and the execution rules between each proof-of-concept; calling each proof-of-concept for vulnerability scanning according to the execution rules in the syntax tree to obtain a scanning result. Through the flow graph description, the combined logic of multiple POCs is represented in an abstract manner of flow graph rules, so that the computer device converts the flow graph description into a syntax tree, visually presenting the execution rules between POCs in a tree form, and then sequentially calling each POC for vulnerability scanning, avoiding recompiling the POCs stored in the POC library, improving the POC reusability and vulnerability scanning efficiency.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular, to a vulnerability scanning method, apparatus, storage medium, and computer device. Background Art

[0002] Vulnerability scanning is an important part of network security management, which helps organizations protect their assets from potential attacks. Through regular vulnerability scanning, organizations can timely discover and fix security vulnerabilities, reducing the risk of being attacked. Proof of Concept (POC) in vulnerability scanning refers to a description or a sample of an attack. POC is used to verify whether a discovered vulnerability actually exists and the degree of harm of the vulnerability. It can help security researchers demonstrate how to use the vulnerability to launch attacks, obtain sensitive information, or damage the system.

[0003] In the related art, some simple POCs are stored in the POC library. When users need to perform complex vulnerability scanning and involve the combined use of some POCs in the POC library, they need to recompile the specific implementation code of these POCs, resulting in poor POC reusability and reduced vulnerability scanning efficiency. Therefore, the related art urgently needs to propose a vulnerability scanning method to solve the above technical problems. Summary of the Invention

[0004] The main purpose of this application is to provide a vulnerability scanning method, apparatus, storage medium, and computer device, which can avoid recompiling the POCs stored in the POC library, improve POC reusability, and vulnerability scanning efficiency.

[0005] In a first aspect, an embodiment of this application provides a vulnerability scanning method, including:

[0006] Obtain a flow graph description, where the flow graph description is obtained by compiling the POC names of multiple Proof of Concepts in a Proof of Concept library according to flow graph rules;

[0007] Convert the flow graph description into a syntax tree, where the syntax tree includes the POC names of each Proof of Concept and the execution rules between each Proof of Concept;

[0008] Call each Proof of Concept for vulnerability scanning according to the execution rules in the syntax tree to obtain a scanning result.

[0009] In a second aspect, an embodiment of this application provides a vulnerability scanning apparatus, including:

[0010] An obtaining unit, configured to obtain a flow graph description, where the flow graph description is obtained by compiling the POC names of multiple Proof of Concepts in a Proof of Concept library according to flow graph rules;

[0011] A conversion unit for converting the flowchart description into a syntax tree, the syntax tree including the proof-of-concept names of each of the proofs-of-concept and the execution rules between each of the proofs-of-concept;

[0012] A vulnerability scanning unit for calling each of the proofs-of-concept for vulnerability scanning according to the execution rules in the syntax tree to obtain a scanning result.

[0013] In a third aspect, an embodiment of the present application provides a storage medium. The computer-readable storage medium stores multiple instructions, and these instructions are suitable for being loaded by a processor to execute the vulnerability scanning method as described in any one of the above.

[0014] In a fourth aspect, an embodiment of the present application provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the vulnerability scanning method as described in any one of the above is implemented.

[0015] In the embodiment of the present application, by obtaining a flowchart description, the flowchart description is obtained by compiling the proof-of-concept names of multiple proofs-of-concept in a proof-of-concept library according to flowchart rules; converting the flowchart description into a syntax tree, the syntax tree including the proof-of-concept names of each of the proofs-of-concept and the execution rules between each of the proofs-of-concept; calling each of the proofs-of-concept for vulnerability scanning according to the execution rules in the syntax tree to obtain a scanning result. Compared with the related art, when it comes to the combined use of some POCs in a POC library, it is necessary to recompile the specific implementation codes of these POCs. In the embodiment of the present application, through the flowchart description, the combined logic of multiple POCs is represented in an abstract manner of flowchart rules, so that the computer device converts the flowchart description into a syntax tree, visually presenting the execution rules between POCs in a tree form, and then sequentially calling each POC for vulnerability scanning, avoiding recompiling the POCs stored in the POC library, and improving the POC reusability and vulnerability scanning efficiency.

[0016] Other features and advantages of the present disclosure will be described in the following specification, and will, in part, be obvious from the specification, or will be understood by implementing the present disclosure. The objectives and other advantages of the present disclosure can be achieved and obtained by the structures specifically pointed out in the specification, the claims, and the drawings. Description of the Drawings

[0017] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of this specification. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0018] Figure 1 It is a schematic diagram for the combined use of certain POCs in the POC library in the related art provided by the embodiments of the present application.

[0019] Figure 2 It is a schematic diagram of the scenario of the vulnerability scanning system provided by the embodiments of the present application.

[0020] Figure 3 It is a schematic flowchart of the vulnerability scanning method provided by the embodiments of the present application.

[0021] Figure 4 It is a schematic diagram of the interaction framework between the client and the server provided by the embodiments of the present application.

[0022] Figure 5 It is a schematic diagram of the structure of the vulnerability scanning device provided by the embodiments of the present application.

[0023] Figure 6 It is a schematic diagram of the structure of the computer device provided by the embodiments of the present application. Detailed implementation manners

[0024] In order to enable those skilled in the art of this technology to better understand the solutions of the present application, the following will clearly and completely describe the technical solutions in the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, rather than all embodiments. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative efforts belong to the scope of protection of the present application.

[0025] It should be noted that in some processes described in the specification, claims, and the above drawings, there are multiple steps that appear in a specific order. However, it should be clearly understood that these steps can be executed not in the order in which they appear in this article or in parallel. The step numbers are only used to distinguish different steps, and the numbers themselves do not represent any execution rules. In addition, descriptions such as "first", "second", or "target" in this article are used to distinguish similar objects, rather than necessarily describing a specific order or sequence.

[0026] Before further elaborating on the embodiments of the present disclosure, the nouns and terms involved in the embodiments of the present disclosure are explained. The nouns and terms involved in the embodiments of the present disclosure are applicable to the following explanations:

[0027] Proof of Concept (POC). In the field of network security, POC usually refers to a piece of code or a method used to verify whether a specific vulnerability exists in a target system. After security researchers discover a potential vulnerability, they will write a POC to prove that the vulnerability can be exploited. For example, for a possible input validation vulnerability in a software, the POC may be a piece of code that causes abnormal behavior (such as crashing or information leakage) in the software when specific characters are input.

[0028] The following is a simple example of using POC (Proof of Concept) for vulnerability scanning:

[0029] SQL injection vulnerability scanning. SQL injection is a common vulnerability in web applications. Attackers can inject malicious SQL statements into user input fields (such as login forms, search boxes, etc.), which may enable them to obtain sensitive information in the database, tamper with data, or perform unauthorized database operations.

[0030] For example, there is a simple World Wide Web (Web) application with a login page where users need to enter a username and password to log in. The application uses SQL statements in the background to verify user input. For example:

[0031] A normal SQL query statement may be: SELECT * FROM users WHERE username = 'user_input_username' AND password = 'user_input_password';

[0032] The POC constructed by the attacker (used to verify the existence of SQL injection vulnerability) may be as follows:

[0033] Enter in the username input box: 'OR '1' = '1

[0034] Enter any password (such as 123).

[0035] At this time, the actual SQL statement executed in the application background becomes: SELECT * FROM users WHERE username = '' OR '1' = '1' AND password = '123';

[0036] Since the condition '1'='1' always holds, this maliciously constructed input may bypass the normal login verification, causing the application to erroneously allow the attacker to log in, which verifies the existence of a SQL injection vulnerability in the web application.

[0037] Use of POC during vulnerability scanning

[0038] In vulnerability scanning tools, there will be POCs for common vulnerabilities such as SQL injection.

[0039] The scanner will automatically send malicious inputs similar to the above construction to various places in the target web application where user input may exist (such as forms, query parameters, etc.).

[0040] Then, the scanner will determine whether there is a SQL injection vulnerability based on the response of the target application. For example, if after sending malicious input, it is possible to successfully log in to an account that should not be logged in, or get database-related error messages, the scanner will report the discovery of a SQL injection vulnerability.

[0041] This is just a simple example of using POC for vulnerability scanning. In the actual field of network security, there are also POCs for various vulnerabilities such as cross-site scripting (XSS), file inclusion vulnerabilities, remote command execution vulnerabilities, etc., which are used to discover and verify security risks in the target system.

[0042] In related technologies, some simple POCs are stored in the POC library for users to use during vulnerability scanning. However, when users need to perform complex vulnerability scanning and involve combining some POCs in the POC library, they need to recompile the specific implementation code of these POCs to form a new POC, resulting in poor POC reusability and reduced vulnerability scanning efficiency.

[0043] A flow graph is a graphical representation method used to describe the flow relationships between various elements in a system. It consists of nodes and edges. Nodes usually represent entities, states, operations, or events in the system, and edges represent the relationships between these nodes, such as the flow direction of data, the transfer order of control, the execution order of operations, etc.

[0044] As Figure 1 shown, Figure 1 is a schematic diagram for combining some POCs in the POC library in the related technologies provided by the embodiments of the present application.

[0045] The execution rules expected by the user for vulnerability scanning are as follows: after A is executed, B and C are looped several times, and then D is executed. Since the existing tools do not support the POC loop rule, redundant POC implementations have to be added to the target POC. That is, all the implementation codes of POC B and POC C are recompiled into a new POC E, so that the finally formed POCs include POC A, POC E, and POC D. Since all the implementation codes of POC B and POC C are recompiled into a new POC E, the compilation content included in POC E is long and complex, and because it is manually compiled, compilation errors are likely to occur, resulting in poor POC reusability and reduced vulnerability scanning efficiency.

[0046] To solve the above problems, the embodiments of the present application obtain a flow graph description, which is obtained by compiling the POC names of multiple POCs in the proof-of-concept library according to the flow graph rules; convert the flow graph description into a syntax tree, which includes the POC names of each POC and the execution rules between each POC; call each POC according to the execution rules in the syntax tree for vulnerability scanning to obtain a scan result. Compared with the related art, when it comes to the combined use of some POCs in the POC library, it is necessary to recompile the specific implementation codes of these POCs. In the embodiments of the present application, through the flow graph description, the combined logic of multiple POCs is represented in an abstract manner of flow graph rules, so that the computer device converts the flow graph description into a syntax tree, visually presenting the execution rules between POCs in a tree form, and then calling each POC in turn for vulnerability scanning, avoiding recompiling the POCs stored in the POC library, improving POC reusability and vulnerability scanning efficiency. For details, please continue to refer to the following specific embodiments.

[0047] Please refer to Figure 2 , Figure 2 which is a scenario schematic diagram of the vulnerability scanning system provided by the embodiments of the present application. It includes a client 140, the Internet 130, a gateway 120, a server 110, etc.

[0048] The client 140 includes, but is not limited to, pre-configured electronic devices such as desktop computers, laptop computers, and tablet computers. In addition, it can be a single device or a collection of multiple devices. The client 140 can communicate with the Internet 130 in a wired or wireless manner to exchange data.

[0049] Server 110 refers to a computer system that can provide certain services to client 140. Compared with ordinary client 140, server 110 has higher requirements in terms of stability, security, performance, etc. Server 110 can be a high-performance computer in a network platform, a cluster of multiple high-performance computers, a part (such as a virtual machine) partitioned from a high-performance computer, a combination of parts (such as virtual machines) partitioned from multiple high-performance computers, etc.

[0050] The gateway 120 is also known as an internetwork connector and protocol converter. The gateway realizes network interconnection at the transport layer and is a computer system or device that acts as a converter. Between two systems using different communication protocols, data formats, or languages, and even with completely different architectures, the gateway is a translator. At the same time, the gateway can also provide filtering and security functions. The message sent by client 140 to server 110 needs to be sent to the corresponding server 110 through gateway 120. The message sent by server 110 to client 140 also needs to be sent to the corresponding client 140 through gateway 120.

[0051] The vulnerability scanning method of the embodiments of the present disclosure can be implemented on server 140.

[0052] It should be noted that Figure 2 The schematic diagram of the scenario of the vulnerability scanning system shown is only an example. The vulnerability scanning system and scenario described in the embodiments of the present application are for more clearly explaining the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those of ordinary skill in the art know that with the evolution of image processing technology and the emergence of new business scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.

[0053] In this embodiment, the description will be made from the perspective of the vulnerability scanning device, which can be specifically integrated in a client with a storage unit and equipped with a microprocessor and having computing power.

[0054] Please refer to Figure 3 , Figure 3 which is the schematic flowchart of the vulnerability scanning method provided by the embodiments of the present application. The vulnerability scanning method includes:

[0055] In step 201, a flow graph description is obtained, and the flow graph description is obtained by compiling the concept verification names of multiple concept verifications in the proof-of-concept library according to the flow graph rules.

[0056] Among them, the flow graph description regards the existing POCs as flow graph point elements, and the flow graph rules as flow graph edge elements. The point elements and edge elements are used to construct new complex POCs. The flow graph rules are a series of criteria for defining and constraining the relationships and behaviors between points and edges in a flow graph. These rules determine how information, data, control flow, etc. are transmitted, processed, and interacted in the system or process described by the flow graph. The flow graph rules cover control branch rules, loop rules, sequential execution rules, etc.

[0057] For example, the flow graph description is "flow: POC A && POC B". This flow graph description includes the names of the proofs of concept with two proofs of concept, namely POC A and POC B, and "&&" is the flow graph rule.

[0058] In step 202, the flow graph description is converted into a syntax tree, which includes the names of the proofs of concept for each proof of concept and the execution rules between each proof of concept.

[0059] Among them, since the flow graph description is a relatively complex text representation form, it contains the execution rules and logical relationships between multiple proofs of concept (POCs). Therefore, in order for the computer device to perform corresponding processing based on the flow graph description, it is necessary to convert it into a syntax tree to display these relationships in a more intuitive and clearer tree structure.

[0060] For example, the syntax tree includes the names of the proofs of concept for each proof of concept and the execution rules between each proof of concept. Through nodes and branches, it is easy to see whether the execution order of different POCs is serial or parallel, and whether there are conditional branches (such as selecting different POC execution paths according to different conditions). This clear representation helps the computer device better understand the execution rules of the entire vulnerability scanning process.

[0061] In some embodiments, the conversion of the flow graph description into a syntax tree includes:

[0062] (1) Perform lexical analysis on the flow graph description to obtain multiple lexical units;

[0063] (2) Screen out the rule lexical units corresponding to the flow graph rules and the names of each proof of concept from the multiple lexical units;

[0064] (3) Determine the execution rules corresponding to each of the rule lexical units;

[0065] (4) Perform syntactic analysis on the multiple lexical units to construct a syntax tree for the multiple names of the proofs of concept through the execution rules, and obtain the syntax tree.

[0066] Among them, first, lexical analysis is performed on the flow graph description. It is mainly responsible for decomposing the input character stream (such as the source code of a programming language) into individual lexical units (Tokens) in the order from left to right. These lexical units are the basic syntax units of the programming language. This process is like splitting a sentence into words when reading an article, and it will decompose the code string into individual lexical units (tokens).

[0067] For example, the flow graph rule module defines keywords such as flow, && operator, for keyword, set keyword, dedupe keyword, and internal keyword. When POC A || POC B appears in the POC, this lexical form does not conform to the flow graph rules, and an error will be reported during lexical analysis.

[0068] After obtaining each rule lexical unit, its corresponding execution rule will be determined.

[0069] For example, the rule lexical unit "&&" means to execute the content before "&&" first, and after the execution is completed, then execute the content after "&&". Taking "flow: POC A&&POC B" as an example, it means to execute POC A first, and after POC A is executed, then execute POC B.

[0070] In this way, according to the determined execution rules corresponding to each rule lexical unit, the specific execution method can be known.

[0071] After obtaining each lexical unit, filter out the rule lexical units corresponding to the flow graph rules (such as flow, &&, for, etc.) from multiple lexical units, and filter out each proof-of-concept name (such as POC A, POC B, etc.).

[0072] Secondly, on the basis of lexical analysis, syntax analysis will be carried out. The main task is to analyze the sequence of lexical units (Tokens) obtained from lexical analysis according to the grammar rules of the given language to determine whether this sequence constitutes a legal sentence (in a programming language, that is, a legal program statement). Syntax analysis constructs a data structure representing the syntax structure of the input code, usually a syntax tree (Syntax Tree) or an abstract syntax tree (Abstract Syntax Tree, AST). This is similar to analyzing the syntax structure of a sentence, and it will check whether the combination of these lexical units is legal according to the defined grammar rules. If the code does not conform to the grammar rules, a syntax error will be generated.

[0073] In step 203, each proof-of-concept is called according to the execution rules in the syntax tree for vulnerability scanning to obtain the scanning results.

[0074] Among them, the execution rules between each POC are extracted from the syntax tree, and then according to these rules, the corresponding POC in the proof-of-concept library is called to execute the specific implementation code for vulnerability scanning, so as to obtain the final scanning result after execution.

[0075] In some embodiments, calling each proof of concept for vulnerability scanning according to the execution rules in the syntax tree to obtain a scanning result includes:

[0076] (1) Converting the syntax tree into multiple execution codes, and the execution rules are met between each execution code;

[0077] (2) Executing each execution code according to the execution rules;

[0078] (3) If any target proof-of-concept name in the proof-of-concept name is included in the currently executed target execution code, call the target proof of concept of the target proof-of-concept name for vulnerability scanning until each execution code is executed, and obtain a scanning result.

[0079] Among them, after the code is parsed in the previous stage, in the code generation stage, the parsed abstract syntax tree (AST) or intermediate representation form needs to be converted into machine code or bytecode that can be actually executed on the target platform, so that the computer hardware can directly understand and execute the corresponding operations, and finally realize the functions defined by the code. Then these codes will be executed, and the computer will execute the operations in the order of the generated instructions. For example, convert the code "POC A&&POC B" into three execution codes, which are: execute POC A, detect whether POC A is executed, and execute POC B after POC A is executed, and execute each execution code according to this execution rule.

[0080] Specifically, if any target proof-of-concept name in the proof-of-concept name is included in the currently executed target execution code, call the target proof of concept of the target proof-of-concept name for vulnerability scanning until each execution code is executed, and obtain a scanning result.

[0081] For example, the three execution codes are: execute POC A, detect whether POC A is executed, and execute POC B after POC A is executed. Among them, the names of POC A and POC B are included in the two execution codes of executing POC A and executing POC B after POC A is executed respectively. If the currently executed target execution code is execute POC B after POC A is executed, call POC B for vulnerability scanning until each execution code is executed, and obtain a scanning result.

[0082] In some embodiments, performing vulnerability scanning by invoking the target proof-of-concept corresponding to the target proof-of-concept name includes:

[0083] (1.1) Obtaining the target proof-of-concept method of the target proof-of-concept corresponding to the target proof-of-concept name;

[0084] (1.2) Determining the target execution engine corresponding to the target proof-of-concept method according to the preset mapping relationship between the proof-of-concept method and the execution engine;

[0085] (1.3) Invoking the target proof-of-concept through the target execution engine to perform vulnerability scanning.

[0086] Among them, different proof-of-concept methods (such as TCP, HTTP, DNS, etc.) have their unique operating mechanisms and possible vulnerability types. In order to efficiently and accurately detect vulnerabilities related to these protocols, dedicated vulnerability detection codes, that is, POC statements, are designed for different protocols. Different execution engines are used to execute the proof-of-concepts corresponding to different proof-of-concept methods.

[0087] For example, the TCP engine is responsible for executing these POC statements related to the TCP protocol. It utilizes in-depth understanding of the TCP protocol and related network programming techniques to operate network connections according to the instructions in the POC statements, such as establishing a TCP connection, sending TCP packets in a specific format, receiving and analyzing the returned data, etc., to determine whether the target system has corresponding TCP protocol vulnerabilities. The HTTP engine focuses on executing these POC statements related to the HTTP protocol. It will send specific HTTP requests (including different request methods such as GET, POST, etc., and setting different request headers and request bodies) according to the requirements of the POC statements, receive and analyze the HTTP responses returned by the server, so as to determine whether the target system has vulnerabilities related to the HTTP protocol. The DNS engine is responsible for executing these POC statements related to the DNS protocol. It will perform DNS query operations according to the instructions in the POC statements (such as sending different types of DNS requests, including A record queries, CNAME record queries, etc.), analyze the response data returned by the DNS server, and then judge whether the target DNS server has related vulnerabilities. Through this division of labor, different engines focus on their respective proficient protocol fields and can complete the vulnerability detection work more professionally and efficiently.

[0088] Thus, when invoking the vulnerability detection code of a proof-of-concept method such as POC A that is specifically used to detect TCP, the TCP engine will be called to execute the execution code of POC A to perform vulnerability scanning.

[0089] In some embodiments, each of the proof-of-concepts includes sub-proof-of-concepts with different types of scanning objects. Before invoking the target proof-of-concept by the target execution engine for vulnerability scanning, it further includes:

[0090] (1.1) Obtain the specified target type of scanning object;

[0091] Invoking the target proof-of-concept by the target execution engine for vulnerability scanning includes:

[0092] (1.2) Determine the target sub-proof-of-concept corresponding to the target type of scanning object in the target proof-of-concept;

[0093] (1.3) Invoke the target sub-proof-of-concept by the target execution engine for vulnerability scanning.

[0094] Wherein, the type of scanning object is the type of the scanning object configured by the user for vulnerability scanning. In the POC library, each POC includes multiple sub-POCs, that is, sub-proof-of-concepts, for different types of scanning objects. Thus, when performing vulnerability scanning, according to the target type of scanning object specified by the user, the target sub-proof-of-concept corresponding to the target type of scanning object can be selected from each invoked proof-of-concept for vulnerability scanning.

[0095] For example, for different computer operating systems, they can be divided into the windows type, the macOS type, the Linux type, etc. Taking the proof-of-concept POC A as an example, it includes POC A1 for the windows type, POC A2 for the macOS type, and POC A3 for the Linux type. When the user specifies to perform vulnerability scanning for the windows type, POC A1 in POC A can be invoked specifically for vulnerability scanning of the windows type.

[0096] In some embodiments, before invoking the target sub-proof-of-concept by the target execution engine for vulnerability scanning, it further includes:

[0097] (1.1) Obtain the current load ratio of the target execution engine;

[0098] (1.2) If the current load ratio is greater than or equal to the preset load ratio, perform real-time detection of the load ratio of the target execution engine;

[0099] (1.3) When it is detected that the load ratio of the target execution engine is less than the preset load ratio, execute the step of invoking the target sub-proof-of-concept by the target execution engine for vulnerability scanning.

[0100] Among them, before invoking the target sub - concept verification through the target execution engine for vulnerability scanning, in order to avoid the problem of low execution efficiency caused by excessive engine execution load or direct downtime exception, it is necessary to obtain the current load ratio of the target execution engine. If the current load ratio is greater than or equal to the preset load ratio, it indicates that the load of the target execution engine is high. Then, the load ratio of the target execution engine is detected in real - time. When it is detected that the load ratio of the target execution engine is less than the preset load ratio, it indicates that the load of the target execution engine is low at this time. Then, the step of invoking the target sub - concept verification through the target execution engine for vulnerability scanning is executed to avoid the problem of low execution efficiency caused by excessive load or direct downtime exception and improve system stability.

[0101] In some embodiments, the method further includes:

[0102] When the duration when the detected load ratio of the target execution engine is greater than or equal to the preset load ratio reaches the preset duration, a prompt message is generated, and the prompt message is used to prompt that the vulnerability scanning times out.

[0103] Among them, during the process of detecting the load ratio of the target execution engine in real - time, if the duration when the load ratio of the target execution engine is greater than or equal to the preset load ratio reaches the preset duration, it indicates that the target execution engine may already have an exception or downtime. Then, a prompt message is generated to prompt that the vulnerability scanning times out and avoid the user's long - time waiting.

[0104] As can be seen from the above, in the embodiment of the present application, by obtaining a flow - graph description, the flow - graph description is obtained by compiling the concept - verification names of multiple concept verifications in the concept - verification library according to flow - graph rules; converting the flow - graph description into a syntax tree, the syntax tree includes the concept - verification names of each concept verification and the execution rules between each concept verification; and invoking each concept verification for vulnerability scanning according to the execution rules in the syntax tree to obtain a scanning result. Compared with the related art, when it comes to the combined use of some POCs in the POC library, it is necessary to re - compile the specific implementation codes of these POCs. In the embodiment of the present application, through the flow - graph description, the combined logic of multiple POCs is represented in an abstract manner of flow - graph rules, so that the computer device converts the flow - graph description into a syntax tree, visually presenting the execution rules between POCs in a tree - like form, and then sequentially invoking each POC for vulnerability scanning, avoiding re - compilation of the POCs stored in the POC library, and improving the POC reusability and vulnerability - scanning efficiency.

[0105] Please refer to Figure 4 , Figure 4Schematic diagram of the interaction framework between the client and the server provided by the embodiments of this application. Among them, the client includes a new POC function module, a configuration function module, and a reporting function module. The server includes a POC library module, a configuration module, a scheduler module, a flow graph rule module, an execution engine module, a flow graph engine module, and an analyzer module.

[0106] For the client, the new POC function module is used to allow users to customize POC content, and the configuration function module allows users to automate and customize vulnerability scanning through configuration scripts. For example, execute all POCs or specific POCs at one time, and configure the report to only display vulnerabilities with a severity level above critical. The reporting function module shows the results of the current POC execution to the user, including the severity of the vulnerability, the name of the vulnerability, the type of the vulnerability, the description of the vulnerability, etc.

[0107] For the server, the POC library module mainly includes user-defined POCs and third-party POCs. The POC library needs to be updated with new POCs regularly to ensure the completeness of the vulnerability scanning tool. The configuration module is used to receive the configuration parameters of the client configuration function module as the configuration parameter module of the server-side module. It mainly provides a parameter basis for the scheduler scheduling. The various configuration parameters of the vulnerability scanning of this module. The scheduler is the core module of the server-side. By obtaining the various configuration parameters of the configuration module and the POCs in the POC library, it schedules the POCs to be executed to their respective execution engines and returns the results to the analyzer. Common execution engines include Execution Engine 1, Execution Engine 2, etc. The analyzer module is responsible for the analysis and integration of the results of the entire POC scheduler, and finally sends the analysis report to the reporting function module of the client. The flow graph rule module is mainly responsible for the definition of reusing POC rules, including control branch rules, loop rules, etc. The flow graph engine module is mainly responsible for the parsing of the flow graph rules. Through this module, the existing POCs in the POC library can be associated with the execution flow to achieve the rapid invocation of the existing POCs.

[0108] Among them, for the flow graph rule module, it is responsible for the implementation of user-defined POC rules. Through rich flow graph rules, it can make it simpler and more efficient for users to implement complex POCs. The detailed flow graph rules are described as follows.

[0109] Rule 1, Control Branch:

[0110] Example: The user brute-forces the WordPress login information using the default username and password. First, check whether the target is a WordPress website. If so, then brute-force the login information using the default credentials. Set the check for the existence of the target as POC A and the brute-force as POC B. Before this invention, the user needed to add the following POC C. The part in {} requires the user to copy the implementation of POC A and B into POC C. This is equivalent to writing a redundant piece of code.

[0111] Execute {the implementation of POC A}

[0112] if the website exists:

[0113] Execute {the implementation of POC B}

[0114] else:

[0115] Detect that the target does not exist and do not execute;

[0116] However, in this application, POC A and POC B can be directly reused without adding POC C. The final flow graph is described as "flow: POC A && POC B". In this way, a new flow definition is added, and the control branch is implemented through the && symbol. Only when POC A is executed successfully can POC B continue to execute; otherwise, POC B will not execute.

[0117] Rule two, loop:

[0118] Example: Brute-force all domain names found in the SSL request for the request. First, use the SSL request to find all domain names, and then brute-force all domain names. Set the SSL request as POC A and the brute-force as POC B. Before this invention, the user needed to add the following POC C. The execution result of POC A contains all domain name fields, and POC B receives the domain name parameter and executes. Set is responsible for setting the domain name parameter to a parameter recognizable by POC B. The part in {} requires the user to copy the implementation of POC A and B into POC C. This is equivalent to writing a redundant piece of code.

[0119] All domain names = Execute {the implementation of POC A}

[0120] for domain name in all domain names:

[0121] set (domain name, new domain name)

[0122] {the implementation of POC B}(new domain name)

[0123] However, this application can directly reuse POC A and POC B without adding a new POC C. The final flow diagram is described as "flow:

[0124] All domain names = Execute POC A

[0125] for domain name in all domain names:

[0126] set(domain name, new domain name)

[0127] POC B(new domain name)"

[0128] Add a new flow definition, implement the control branch through the for symbol. The execution result of POC A contains all domain name fields. POC B receives the domain name parameter and executes. Set is responsible for setting the domain name parameter to a parameter recognizable by POC B.

[0129] Rule three, named call:

[0130] As described in rules one and two, POC A and POC B do not need to be re-implemented to write an additional redundant code, and can be directly called by name. This rule can quickly implement a complex and efficient workflow.

[0131] Rule four, set parameter passing:

[0132] As described in rules one and two, Set is responsible for setting the domain name parameter to a parameter recognizable by POC B. Set helps users pass parameters between POCs. POC B depends on the domain name parameter of POC A, and sets the domain name to a new domain name parameter recognizable by POC B through set.

[0133] Rule five, log:

[0134] Through the log statement, the current POC execution status or POC result can be displayed for viewing, etc., helping users quickly and conveniently locate problems found during the POC customization process.

[0135] Rule six, deduplication:

[0136] Through the dedupe statement, deduplication of POC results can be achieved. For example, in rule two, if there are duplicate domain names among all domain names, through dedupe, the duplicate domain names can be removed. Suppose it is {domain name 1, domain name 2, domain name 3, domain name 3} before removal, and it becomes {domain name 1, domain name 2, domain name 3} after deduplication

[0137] Rule seven, skip:

[0138] As in Rule 1, it is divided into two steps, POC A and POC B. By adding an internal statement in the implementation of POC A, the execution result of POC A can be regarded as the intermediate content of the flow graph execution. Users may not care about the execution result of POC A but are more concerned about the execution result of POC B. Therefore, through this internal statement, users can be helped to screen out the useless intermediate result, that is, the execution result of POC A, and view the result of POC B more friendly.

[0139] The whole process includes: constructing a POC library. Starting to customize POC, including responsible POC. Constructing a target POC library and carrying out vulnerability scanning work through the POC library. Invoking flow graph rules. Constructing the responsible POC. Through the syntax rules provided by the circulation rule module, the responsible POC can be constructed quickly and efficiently without adding additional redundant POC. Configuring scanning. Through the configuration module on the user side, the global scanning parameter configuration work for vulnerability scanning can be realized. It includes whether to scan the entire POC library or specific scanning. The scheduler module on the server side obtains the user configuration from the configuration module and completes the configuration preparation work before scanning. After the scheduler module loads the user configuration, it loads POC instances from the POC library. POC instances include simple POC and complex POC. When the scheduler module executes a POC containing flow graph rule statements, it needs to call the flow graph engine module to parse the flow graph rule language. As detailed in the flow graph engine module description, after the parsing of the flow graph rule language is completed, the execution of the POC begins. If the POC does not contain flow graph rule statements, this step is skipped. After the scheduler module finishes the parsing by the flow graph engine, it will perform the specific execution of the POC. The specific execution is completed by the execution engine. For example, the TCP engine is responsible for the execution of TCP POC statements, the HTTP engine is responsible for the execution of HTTP POC statements, and the DNS engine is responsible for the execution of DNS POC statements. After the execution engine finishes the execution, it returns the execution result to the scheduler. The scheduling engine calls the analyzer. The analyzer is responsible for counting and analyzing all the execution results of the scheduler. It includes the execution status of the POC, the severity level of the vulnerability, the log, etc. After all POCs complete the vulnerability scanning, the analyzer generates a vulnerability report and reports it to the user.

[0140] For the specific implementation of each of the above steps, reference can be made to the previous embodiments, which will not be elaborated here.

[0141] To facilitate the better implementation of the vulnerability scanning method provided in the embodiments of the present application, the embodiments of the present application also provide a device based on the above vulnerability scanning method. The meanings of the nouns are the same as those in the above vulnerability scanning method, and the specific implementation details can refer to the description in the method embodiments.

[0142] Please refer to Figure 5 , Figure 5The figure is a schematic structural diagram of a vulnerability scanning device provided by an embodiment of the present application, and the vulnerability scanning device is applied to a computer device. The vulnerability scanning device may include an acquisition unit 601, a conversion unit 602, a vulnerability scanning unit 603, etc.

[0143] The acquisition unit 601 is configured to acquire a flow graph description, where the flow graph description is obtained by compiling the concept verification names of multiple concept verifications in a proof-of-concept library according to flow graph rules;

[0144] The conversion unit 602 is configured to convert the flow graph description into a syntax tree, where the syntax tree includes the concept verification names of each concept verification and the execution rules between each concept verification;

[0145] The vulnerability scanning unit 603 is configured to call each concept verification for vulnerability scanning according to the execution rules in the syntax tree to obtain a scanning result.

[0146] In some embodiments, the conversion unit 602 includes:

[0147] A lexical analysis subunit is configured to perform lexical analysis on the flow graph description to obtain a plurality of lexical units;

[0148] A screening subunit is configured to screen out the rule lexical units corresponding to the flow graph rules and each concept verification name from the plurality of lexical units;

[0149] A first determination subunit is configured to determine the execution rules corresponding to each rule lexical unit;

[0150] A syntax analysis subunit is configured to perform syntax analysis on the plurality of lexical units to construct a syntax tree for the plurality of concept verification names through the execution rules to obtain a syntax tree.

[0151] In some embodiments, the vulnerability scanning unit 603 includes:

[0152] A conversion subunit is configured to convert the syntax tree into a plurality of execution codes, and each execution code conforms to the execution rules;

[0153] An execution subunit is configured to execute each execution code according to the execution rules;

[0154] A call subunit is configured to, if any target concept verification name in the concept verification names is included in the currently executed target execution code, call the target concept verification corresponding to the target concept verification name for vulnerability scanning until each execution code is executed, to obtain a scanning result.

[0155] In some embodiments, the call subunit is configured to:

[0156] The target proof-of-concept method of the target proof-of-concept for obtaining the target proof-of-concept name;

[0157] Determine the target execution engine corresponding to the target proof-of-concept method according to the preset mapping relationship between the proof-of-concept method and the execution engine;

[0158] Invoke the target proof-of-concept through the target execution engine to perform vulnerability scanning.

[0159] In some embodiments, each proof-of-concept includes sub-proofs-of-concept with different scan object types. The calling subunit is further configured to:

[0160] Obtain the specified target scan object type;

[0161] Determine the target sub-proof-of-concept corresponding to the target scan object type in the target proof-of-concept;

[0162] Invoke the target sub-proof-of-concept through the target execution engine to perform vulnerability scanning.

[0163] In some embodiments, the calling subunit is further configured to:

[0164] Obtain the current load ratio of the target execution engine;

[0165] If the current load ratio is greater than or equal to the preset load ratio, perform real-time detection of the load ratio of the target execution engine;

[0166] When it is detected that the load ratio of the target execution engine is less than the preset load ratio, execute the step of invoking the target sub-proof-of-concept through the target execution engine to perform vulnerability scanning.

[0167] In some embodiments, the calling subunit is further configured to:

[0168] When the duration when the load ratio of the target execution engine is greater than or equal to the preset load ratio reaches the preset duration, generate a prompt message for prompting that the vulnerability scanning times out.

[0169] For the specific implementation of each of the above units, reference may be made to the previous embodiments and will not be elaborated here.

[0170] As can be seen from the above, in the embodiment of the present application, the acquisition unit 601 acquires a flow graph description, which is obtained by compiling the concept verification names of multiple concept verifications in the proof-of-concept library according to the flow graph rules; the conversion unit 602 converts the flow graph description into a syntax tree, and the syntax tree includes the concept verification names of each concept verification and the execution rules between each concept verification; the vulnerability scanning unit 603 calls each concept verification for vulnerability scanning according to the execution rules in the syntax tree to obtain a scanning result. Compared with the related art, when it comes to the combined use of some POCs in the POC library, it is necessary to recompile the specific implementation code of these POCs. In the embodiment of the present application, through the flow graph description, the combined logic of multiple POCs is represented in an abstract manner of flow graph rules, so that the computer device converts the flow graph description into a syntax tree, intuitively presenting the execution rules between POCs in a tree form, and then calling each POC for vulnerability scanning in turn, avoiding recompiling the POCs stored in the POC library, and improving the reusability of POCs and the vulnerability scanning efficiency.

[0171] For the specific implementation of each of the above units, reference may be made to the previous embodiments, which will not be elaborated here.

[0172] Refer to Figure 6 , Figure 6 FIG. 1000 is a block diagram of a part of a computer device 1000 acting as a server for implementing an embodiment of the present disclosure. The computer device 1000 may vary greatly due to configuration or performance differences, and may include one or more central processing units (CPUs) 622 (for example, one or more processors) and a memory 632, and one or more storage media 630 (for example, one or more mass storage devices) storing application programs 642 or data 644. Among them, the memory 632 and the storage media 630 may be transient storage or persistent storage. The program stored in the storage media 630 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the server 600. Further, the central processing unit 622 may be configured to communicate with the storage media 630 and execute a series of instruction operations in the storage media 630 on the server 600.

[0173] The computer device 1000 may further include one or more power supplies 626, one or more wired or wireless network interfaces 650, one or more input / output interfaces 658, and / or one or more operating systems 641, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0174] The central processing unit 622 in the computer device 1000 can be used to execute the vulnerability scanning method of the embodiments of the present disclosure. For example:

[0175] Obtain a flow graph description, where the flow graph description is obtained by compiling the proof-of-concept names of multiple proofs of concept in the proof-of-concept library according to the flow graph rules;

[0176] Convert the flow graph description into a syntax tree, where the syntax tree includes the proof-of-concept names of each proof of concept and the execution rules between each proof of concept;

[0177] Call each proof of concept for vulnerability scanning according to the execution rules in the syntax tree to obtain a scanning result.

[0178] The embodiments of the present disclosure also provide a computer-readable storage medium. The computer-readable storage medium is used to store program codes, and the program codes are used to execute the vulnerability scanning methods of the foregoing various embodiments.

[0179] The embodiments of the present disclosure also provide a computer program product. The computer program product includes a computer program. The processor of the computer device reads and executes the computer program, so that the computer device executes to implement the above-mentioned vulnerability scanning method. For example:

[0180] Obtain a flow graph description, where the flow graph description is obtained by compiling the proof-of-concept names of multiple proofs of concept in the proof-of-concept library according to the flow graph rules;

[0181] Convert the flow graph description into a syntax tree, where the syntax tree includes the proof-of-concept names of each proof of concept and the execution rules between each proof of concept;

[0182] Call each proof of concept for vulnerability scanning according to the execution rules in the syntax tree to obtain a scanning result.

[0183] In addition, the terms "include" and "comprise" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these process, method, product or device.

[0184] It should be understood that in this application, "at least one (item)" means one or more, and "a plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and both A and B exist at the same time. Among them, A and B can be singular or plural. The character " / " generally indicates that the associated objects before and after are in an "or" relationship. "At least one (one) of the following" or its similar expressions refer to any combination of these items, including any combination of single items (one) or plural items (ones). For example, at least one (one) of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0185] It should be understood that in the description of the embodiments of this application, the meaning of "a plurality (or multiple items)" is more than two. Understandings such as greater than, less than, exceeding, etc. do not include the present number, and understandings such as above, below, within, etc. include the present number.

[0186] In several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of units is only a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection to each other can be through some interfaces, and the indirect coupling or communication connection of devices or units can be in electrical, mechanical, or other forms.

[0187] The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they can be located in one place, or they can be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0188] In addition, each functional unit in the various embodiments of this application can be integrated into a processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0189] When an integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memories (ROM for short), random access memories (RAM for short), magnetic disks, or optical discs.

[0190] It should also be understood that the various embodiments provided in the embodiments of this application can be combined arbitrarily to achieve different technical effects.

[0191] In the embodiments of this application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works together with other related parts to achieve a predetermined goal, and can be fully or partially implemented by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of the overall module or unit that includes the function of this module or unit.

[0192] The above is a specific description of the embodiments of this application, but this application is not limited to the above embodiments. Those skilled in the art can also make various equivalent deformations or substitutions without departing from the spirit of this application, and these equivalent deformations or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A vulnerability scanning method, characterized in that: include: Obtain a flow graph description, where the flow graph description is obtained by compiling the concept verification names of multiple concept verifications in the concept verification library according to the flow graph rule; Converting the flow graph description into a syntax tree, wherein the syntax tree includes a concept verification name of each concept verification and an execution rule between each concept verification; Each of the concept verifications is called according to the execution rules in the syntax tree to perform vulnerability scanning and obtain a scanning result.

2. The vulnerability scanning method according to claim 1, characterized in that: The converting the flow graph description into a syntax tree comprises: Performing lexical analysis on the flow graph description to obtain a plurality of lexical units; Filtering out the rule lexical units corresponding to the flow graph rule from the plurality of lexical units, and filtering out each concept verification name; Determine the execution rule corresponding to each of the rule lexical units; The plurality of lexical units are subjected to grammatical analysis to construct a grammatical tree for the plurality of concept verification names according to the execution rules to obtain a grammatical tree.

3. The vulnerability scanning method according to claim 1 or 2, characterized in that: The step of calling each of the concept verifications according to the execution rules in the syntax tree to perform vulnerability scanning and obtaining scanning results includes: Converting the syntax tree into a plurality of execution codes, each of the execution codes conforming to the execution rule; Execute each of the execution codes according to the execution rules; If the currently executed target execution code includes any target concept verification name in the concept verification name, the target concept verification of the target concept verification name is called to perform vulnerability scanning until each of the execution codes is executed and the scanning result is obtained.

4. The vulnerability scanning method according to claim 3, characterized in that: The target concept verification of calling the target concept verification name to perform vulnerability scanning includes: Obtain a target concept verification method for a target concept verification of the target concept verification name; Determining a target execution engine corresponding to the target concept verification method according to a preset mapping relationship between the concept verification method and the execution engine; The target concept verification is called by the target execution engine to perform vulnerability scanning.

5. The vulnerability scanning method according to claim 4, characterized in that: Each of the concept verifications includes sub-concept verifications of different scan object types, and before the target concept verification is called by the target execution engine to perform vulnerability scanning, it also includes: Get the specified target scanning object type; The step of calling the target concept verification by the target execution engine to perform vulnerability scanning includes: Determine a target sub-concept verification corresponding to the target scanning object type in the target concept verification; The target sub-concept verification is called by the target execution engine to perform vulnerability scanning.

6. The vulnerability scanning method according to claim 5, characterized in that: Before the target execution engine calls the target sub-concept verification to perform vulnerability scanning, the method further includes: Obtaining the current load ratio of the target execution engine; If the current load ratio is greater than or equal to the preset load ratio, the load ratio of the target execution engine is detected in real time; When it is detected that the load proportion of the target execution engine is less than the preset load proportion, the step of performing vulnerability scanning by calling the target sub-concept verification through the target execution engine is executed.

7. The vulnerability scanning method according to claim 6, characterized in that: The method further comprises: When it is detected that the duration when the load ratio of the target execution engine is greater than or equal to the preset load ratio reaches a preset duration, a prompt message is generated, where the prompt message is used to prompt that the vulnerability scan has timed out.

8. A vulnerability scanning device, characterized in that: include: An acquisition unit is used to acquire a flow graph description, where the flow graph description is obtained by compiling concept verification names of multiple concept verifications in a concept verification library according to a flow graph rule; A conversion unit, configured to convert the flow graph description into a syntax tree, wherein the syntax tree includes a concept verification name of each concept verification and an execution rule between each concept verification; The vulnerability scanning unit is used to call each of the concept verifications according to the execution rules in the syntax tree to perform vulnerability scanning and obtain scanning results.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a plurality of instructions, and the instructions are suitable for being loaded by a processor to execute the vulnerability scanning method according to any one of claims 1 to 7.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the vulnerability scanning method according to any one of claims 1 to 7 is implemented.

Images