Vulnerability testing method and equipment

Abstract

The invention discloses a vulnerability test method and equipment, and belongs to the technical field of network security. A first request message sent by a terminal to a server is obtained through a gateway device. Obtaining a content abstract of the first request message, wherein the content abstract comprises data operation information of the first request message for the server; and determining a vulnerability scanning range according to the data operation information. The vulnerability scanning range comprises one or more vulnerability types matched with the data operation information. And sending the test message to the server through the gateway equipment. The test message is generated according to the test load corresponding to the vulnerability type in the vulnerability scanning range. According to the method and the device, the vulnerability type possibly appearing in the server is judged according to the data operation information of the request message for the server, and the vulnerability test is performed on the server in a targeted manner by adopting the vulnerability load corresponding to the vulnerability type possibly appearing in the server, so that the generation of redundant test messages can be reduced, and the vulnerability test efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to a vulnerability testing method and device. Background Art

[0002] Vulnerability scanning is an important type of network security technology. Vulnerability scanning can identify and detect whether there are known vulnerabilities in computers, networks or applications. Current vulnerability scanning technologies mainly include active scanning and passive scanning. Among them, active scanning is a method of simulating the behavior of attackers and actively sending test messages carrying attack payloads to the server to detect and exploit vulnerabilities in the server's application. However, the current active scanning process usually generates a large number of redundant test messages, resulting in low vulnerability testing efficiency. Summary of the invention

[0003] The present application provides a vulnerability testing method and device, which can improve the efficiency of vulnerability testing.

[0004] In the first aspect, a vulnerability testing method is provided. A vulnerability testing device obtains a first request message sent by a terminal to a server through a gateway device. The gateway device is deployed between the terminal and the server. The vulnerability testing device obtains a content summary of the first request message, and the content summary includes data operation information of the first request message for the server. The vulnerability testing device determines a vulnerability scanning range based on the data operation information. The vulnerability scanning range includes one or more vulnerability types that match the data operation information. The vulnerability testing device sends a test message to the server through the gateway device. The test message is generated based on a test load corresponding to a vulnerability type within the vulnerability scanning range. The test message is used to test whether a server has a vulnerability.

[0005] The present application determines the possible vulnerability types of the server based on the data operation information of the server in the request message, and then uses the vulnerability load corresponding to the possible vulnerability type of the server to perform vulnerability testing on the server in a targeted manner, thereby reducing the testing of irrelevant vulnerability types and reducing the generation of redundant test messages, thereby improving the efficiency of vulnerability testing.

[0006] Optionally, a method for implementing the vulnerability testing device to obtain a content summary of the first request message includes: the vulnerability testing device inputs the message content of the first request message into the traffic analysis model to obtain a content summary output by the traffic analysis model. The traffic analysis model is a large language model trained using a first training corpus. The first training corpus includes multiple sample request messages. The sample request message is annotated with field segmentation information, and the field segmentation information is used to distinguish between a request header and a request body in the sample request message.

[0007] This application uses sample request messages annotated with field segmentation information to train a large language model, which can enhance the language segmentation capability of the large language model for request messages, thereby improving the traffic analysis efficiency of the large language model. By training the large language model as a traffic analysis model for request messages, the traffic analysis model can be guided to obtain the content summary of the request message, thereby improving the efficiency and reliability of obtaining the content summary of the request message.

[0008] Optionally, the plurality of sample request messages include one or more of a hypertext transfer protocol (HTTP) request message, a hypertext transfer protocol secure (HTTPs) request message, a simple network management protocol (SNMP) request message, a multipurpose Internet mail extensions (MIME) request message, or a simple object access protocol (SOAP) request message. For an HTTP request message or an HTTPs request message, the field segmentation information is used to distinguish between a request line, a request header, and a request body.

[0009] Optionally, for an HTTP request message or an HTTPs request message, the field segmentation information is also used to distinguish a request method, a request uniform resource locator (URL) and a protocol version in the request line.

[0010] This application further divides and annotates the fields in the request lines of HTTP request messages and HTTPs request messages, which serve as the training corpus of the large language model, so that the traffic analysis model obtained after training can realize the language segmentation capability of the request messages at a finer granularity, thereby further improving the efficiency of traffic analysis.

[0011] Optionally, the parameters in the request body of the sample request message are marked with a risk tag, and the risk tag is used to indicate that the corresponding parameter has a vulnerability attack risk or does not have a vulnerability attack risk. The request body of the first request message includes one or more parameters, and the content summary of the first request message also includes the risk tag corresponding to the one or more parameters. The vulnerability testing device uses the test load to replace the content of the target parameter in the request body of the first request message to obtain a test message. Among them, the target parameter is a parameter among the one or more parameters that has a vulnerability attack risk.

[0012] This application trains a large language model so that the traffic analysis model obtained after training has the ability to identify the risks of parameters in request messages. In this way, by guiding the traffic analysis model to output the risk tags of the parameters in the request body of the request message, parameters that do not pose a risk of vulnerability attacks do not need to participate in vulnerability scanning, which can reduce the number of redundant test messages and thus improve vulnerability testing efficiency.

[0013] Optionally, the data operation information includes one or more data operation instructions. Each data operation instruction includes a data operation action and an operation object type for which the data operation action is directed. The data operation action includes a query operation, a write operation, a modify operation, or a delete operation. The operation object type includes, but is not limited to, text, a table, a picture, a compressed package, an extensible markup language, or a file.

[0014] Optionally, a vulnerability testing device determines a vulnerability scanning range according to data operation information in an implementation manner, including: the vulnerability testing device obtains the vulnerability type corresponding to each data operation indication in the data operation information based on the vulnerability correspondence relationship. The vulnerability correspondence relationship includes the correspondence between the data operation action, the operation object type and the vulnerability type. The vulnerability testing device uses at least one vulnerability type among all the acquired vulnerability types as the vulnerability scanning range.

[0015] This application presets vulnerability correspondences, filters and screens vulnerability types for server data operations based on request messages, thereby obtaining vulnerability types that match the data operations, which can improve vulnerability detection efficiency.

[0016] Optionally, the vulnerability correspondence also includes a vulnerability weight of the vulnerability type, and the vulnerability weight is used to describe the probability that a vulnerability of the vulnerability type exists in a computer device in a scenario where a data operation action corresponding to the vulnerability type and an operation defined by the operation object type occur. An implementation method in which the vulnerability testing device uses at least one vulnerability type among all acquired vulnerability types as a vulnerability scanning range includes: the vulnerability testing device performs the following steps for each vulnerability type among all vulnerability types to obtain a weighted vulnerability weight for each vulnerability type: obtaining the vulnerability weight of the vulnerability type under all corresponding data operation indications in the data operation information, thereby calculating the weighted vulnerability weight of the vulnerability type. The vulnerability testing device uses the vulnerability types among all vulnerability types whose weighted vulnerability weights are greater than the weight threshold as the vulnerability scanning range.

[0017] This application analyzes the types of vulnerabilities that may occur under the data operations of the request message, and takes the vulnerability types with a higher probability as the vulnerability scanning scope. While ensuring the comprehensiveness of the vulnerability test, the vulnerability scanning scope is narrowed as much as possible to further improve the efficiency of the vulnerability test.

[0018] Optionally, after sending the test message to the server through the gateway device, the vulnerability testing device further obtains a first response message sent by the server to the test message through the gateway device. If the first response message includes an expected result corresponding to the test load, the vulnerability testing device determines that the server has a vulnerability, and the expected result reflects that the test load is executed successfully.

[0019] Optionally, the vulnerability testing device obtains a second response message sent by the server to the terminal through the gateway device. The second response message is a response message to the second request message sent by the terminal to the server. The vulnerability testing device obtains a sensitive information identification result output by the sensitive information identification model by inputting the content of the response body in the second response message into the sensitive information identification model. The sensitive information identification result is used to indicate whether sensitive information is contained. The sensitive information identification model is a large language model trained using a second training corpus. The second training corpus is a text corpus containing sensitive information. The vulnerability testing device determines whether the second response message contains sensitive information based on the sensitive information identification result.

[0020] This application uses text corpus containing preset sensitive information to train a large language model, so that the sensitive information recognition model obtained after training has the ability to recognize sensitive information. The sensitive information recognition model performs language analysis on the message content, and the recognition accuracy of sensitive information in the response message is high, and is not limited to the format of the response message, and has low application limitations.

[0021] Optionally, the text corpus in the second training corpus is annotated with the category of the contained sensitive information. The sensitive information identification result is used to indicate whether sensitive information is contained, including: the sensitive information identification result is used to indicate that sensitive information is not contained, or the sensitive information identification result is used to indicate the category of the contained sensitive information.

[0022] This application trains a large language model so that the sensitive information recognition model obtained after training has the ability to recognize and classify sensitive information. The sensitive information recognition model can identify the category of sensitive information in a fine-grained manner, which helps to achieve rapid vulnerability location and vulnerability repair.

[0023] Optionally, the categories of sensitive information include one or more of keys, user passwords, user accounts, user identity information or user communication addresses.

[0024] In a second aspect, a vulnerability testing device is provided. The vulnerability testing device includes multiple functional modules, and the multiple functional modules interact with each other to implement the method in the first aspect and its various embodiments. The multiple functional modules can be implemented based on software, hardware, or a combination of software and hardware, and the multiple functional modules can be arbitrarily combined or divided based on specific implementations.

[0025] In a third aspect, a vulnerability testing device is provided, comprising: a memory, a network interface, and at least one processor. The memory is used to store program instructions, and after the at least one processor reads the program instructions stored in the memory, the vulnerability testing device executes the method in the first aspect and its various embodiments.

[0026] In a fourth aspect, a computer-readable storage medium is provided, on which instructions are stored. When the instructions are executed by a processor, the method in the above-mentioned first aspect and its various embodiments is implemented.

[0027] In a fifth aspect, a computer program product is provided, including a computer program, which, when executed by a processor, implements the method in the above-mentioned first aspect and its various embodiments.

[0028] In a sixth aspect, a chip is provided, the chip including a programmable logic circuit and / or program instructions, and when the chip is running, the method in the above-mentioned first aspect and its various embodiments is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 It is a schematic diagram of an SNMP request message annotated with field segmentation information provided in an embodiment of the present application;

[0030] Figure 2It is a schematic diagram of a MIME request message annotated with field segmentation information provided in an embodiment of the present application;

[0031] Figure 3 It is a schematic diagram of a SOAP request message annotated with field segmentation information provided in an embodiment of the present application;

[0032] Figure 4 It is a schematic diagram of an HTTP request message or HTTPs request message annotated with field segmentation information provided in an embodiment of the present application;

[0033] Figure 5 It is a schematic diagram of an HTTP request message annotated with field segmentation information provided in an embodiment of the present application;

[0034] Figure 6 It is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0035] Figure 7 It is a hardware structure diagram of a vulnerability testing device provided in an embodiment of the present application;

[0036] Figure 8 It is a flowchart of a vulnerability testing method provided by an embodiment of the present application;

[0037] Fig. 9 It is a structural schematic diagram of a vulnerability testing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0038] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below in conjunction with the accompanying drawings.

[0039] Vulnerability testing is an important technology in the field of network security. Through vulnerability testing, vulnerabilities in network-based assets (such as firewalls, routers, World Wide Web (Web) servers, application servers, etc.) can be discovered, so that network security vulnerabilities and system misconfigurations can be repaired in a timely manner according to the discovered vulnerabilities, thereby effectively preventing hackers from exploiting vulnerabilities to launch network attacks and taking precautions before they occur. Vulnerability scanning is currently the most commonly used vulnerability testing technology.

[0040] Current vulnerability scanning technologies include active scanning and passive scanning. Active scanning is a method of simulating the behavior of an attacker and actively sending test messages carrying attack payloads to the server to detect and exploit vulnerabilities in the server's application. Passive scanning is a method of detecting and identifying vulnerabilities in the server's application by analyzing the traffic from the server.

[0041] Most of the existing active scanning solutions use predefined attack patterns or attack payloads. For example, they simply determine the backend language or development framework used by the application to be tested, and then use the predefined attack patterns or attack payloads to batch replace the parameters in the test message, which will result in a large number of redundant test messages, resulting in low vulnerability testing efficiency.

[0042] Based on this, the present application proposes a technical solution for active scanning. By analyzing the message content of the request message sent by the terminal to the server, the data operation information of the request message for the server is determined, and then the vulnerability type matching the data operation information is selected as the vulnerability scanning range, and then the test load corresponding to the vulnerability type within the vulnerability scanning range is used to generate a test message. The specific technical solution is as follows: a request message sent by the terminal to the server is obtained through a gateway device. The gateway device is deployed between the terminal and the server. A content summary of the request message is obtained, and the content summary includes the data operation information of the request message for the server. The vulnerability scanning range is determined according to the data operation information, and the vulnerability scanning range includes one or more vulnerability types matching the data operation information. A test message is sent to the server through a gateway device. The test message is generated according to the test load corresponding to the vulnerability type within the vulnerability scanning range. The test message is used to test whether the server has a vulnerability. Among them, the vulnerability type matching the data operation information refers to the vulnerability type that may appear in the scenario defined by the data operation information. The present application determines the possible vulnerability types of the server based on the data operation information of the server in the request message, and then uses the vulnerability load corresponding to the possible vulnerability type of the server to perform vulnerability testing on the server in a targeted manner, thereby reducing the testing of irrelevant vulnerability types and reducing the generation of redundant test messages, thereby improving the efficiency of vulnerability testing.

[0043] In some embodiments, an existing large language model (LLM) is used as a basic model, and the large language model is used as a basic specialized training to be a traffic analysis model for request messages, so that the traffic analysis model can obtain a corresponding content summary based on the message content analysis of the input request message. In this way, by inputting the message content of the request message into the traffic analysis model, the content summary of the request message output by the traffic analysis model can be obtained. Among them, a large language model refers to a deep learning model trained using a large amount of text data, which can generate natural language text or understand the meaning of language text. The large language model can handle a variety of natural language tasks, such as text classification, question and answer, or dialogue.

[0044] The traffic analysis model in the present application is a large language model trained using a first training corpus. The first training corpus includes multiple sample request messages. The sample request message is annotated with field segmentation information, and the field segmentation information is used to distinguish the request header and the request body in the sample request message. Among them, the request header is composed of a key-value pair, which is used to carry an indication of the characteristics of the request message itself, such as where the request message comes from, where the destination of the request message is, or what data type the request body of the request message uses, etc. The request body is used to carry request data. The present application uses sample request messages annotated with field segmentation information to train a large language model, which can enhance the large language model's ability to segment the language of request messages, thereby improving the traffic analysis efficiency of the large language model.

[0045] Optionally, a traffic analysis model is obtained by fine-tuning the large language model using the first training corpus. Fine-tuning training refers to further training on a specific task based on an existing model to adapt to the specific data and requirements of the task. For example, the specific task in this application is a traffic analysis task, the specific data of the task is a request message, and the requirement of the task is to analyze the content summary of the request message, including analyzing the data operation information of the request message for the server.

[0046] In addition, when obtaining the message summary of the request message through the traffic analysis model, in addition to inputting the message content of the request message to be analyzed into the traffic analysis model, it is also necessary to input guidance information into the traffic analysis model, and the guidance information is used to guide the traffic analysis model to perform the task of analyzing the message content to output the content summary. The present application improves the efficiency and reliability of obtaining the content summary of the request message by training a large language model specialized into a traffic analysis model for request messages and guiding the traffic analysis model to obtain the content summary of the request message.

[0047] Optionally, the multiple sample request messages include one or more of HTTP request messages, HTTPs request messages, SNMP request messages, MIME request messages, or SOAP request messages. Among them, SNMP request messages, MIME request messages, and SOAP request messages include request headers and request bodies. For these three request messages, the marked field segmentation information can be used to distinguish between the request header and the request body. HTTP request messages and HTTPs request messages include request lines, request headers, and request bodies. For these two request messages, the marked field segmentation information can be used to distinguish between the request lines, request headers, and request bodies. For example, Figures 1 to 4 They are schematic diagrams of a sample request message annotated with field segmentation information provided in an embodiment of the present application. Figure 1 It is an SNMP request message marked with field separation information. Figure 2It is a MIME request message marked with field separation information. Figure 3 It is a SOAP request message marked with field separation information. Figure 4 It is an HTTP request message or HTTPs request message marked with field separation information.

[0048] For HTTP request messages and HTTPs request messages, the request line further includes a request method, a request URL (also called a request path), and a protocol version. Optionally, for HTTP request messages or HTTPs request messages, field segmentation information is also used to distinguish the request method, request URL, and protocol version in the request line. Request methods include GET, POST, HEAD, DELETE, or PUT, etc. For example, for an HTTP request message or HTTPs request message that uses a GET request method, the request body is empty. For an HTTP request message or HTTPs request message that uses a POST request method, the request body includes one or more parameters. This application mainly uses HTTP request messages as an example for illustration. For example, Figure 5 This is a schematic diagram of an HTTP request message annotated with field segmentation information provided by an embodiment of the present application. The present application further divides and annotates the fields in the request line of the HTTP request message and the HTTPs request message, which are the training corpus of the large language model, so that the traffic analysis model obtained after training can realize the language segmentation capability of the request message at a finer granularity, thereby further improving the efficiency of traffic analysis.

[0049] Optionally, the fields in the request header of the request message can also be further divided and labeled, aiming to further enhance the language segmentation capability of the traffic analysis model. For example, the field segmentation information is also used to distinguish the indication of the data type of the request body in the request header, so that the traffic analysis model obtained after training can more accurately analyze the request data in the request body according to the data type. For example, if the indication of the data type of the request body in the request header of an HTTP request message is "Content-Type:application / json", it means that the data in the request body of the HTTP request message is in the json format, that is, the request body includes a json string. For another example, if the indication of the data type of the request body in the request header of an HTTP request message is "Content-Type:text / html", it means that the data in the request body of the HTTP request message is in the html format.

[0050] Optionally, the parameters in the request body of the sample request message are marked with a risk tag, which is used to indicate that the corresponding parameters have a vulnerability attack risk or do not have a vulnerability attack risk. The present application trains a large language model so that the traffic analysis model obtained after training has the ability to identify the risks of the parameters in the request message. In this way, by guiding the traffic analysis model to output the risk tags of the parameters in the request body of the request message, parameters that do not have a vulnerability attack risk do not need to participate in vulnerability scanning, which can reduce the number of redundant test messages, thereby improving vulnerability testing efficiency. For example, please continue to refer to Figure 5 ,The parameter "submit" in the request body is marked with a risk-free tag, indicating that the parameter "submit" does not have the risk of vulnerability attacks.

[0051] In addition, most of the existing passive scanning solutions analyze the traffic data, including request headers, response codes, cookies (referring to data stored on the user's local terminal), form data, response bodies, response headers, and match a series of regular expressions and other rules defined based on known vulnerability patterns and common security issues. When a rule is matched, the corresponding request message or response message will be marked and a corresponding alarm will be generated. Since the main alarms in Web passive scanning are concentrated on sensitive information leakage, the current Web passive scanning mainly detects whether the response message contains sensitive information. The current mainstream sensitive information detection methods include information entropy detection, which calculates the information entropy of the data in the response body of the response message and compares the calculated information entropy with the set information entropy threshold to determine whether the response message contains sensitive information. Among them, information entropy is used to reflect the uncertainty of data. The higher the information entropy, the greater the uncertainty of the data. Conversely, the lower the information entropy, the smaller the uncertainty of the data. However, the information entropy detection method is only applicable to sensitive information generated by the standard, usually with a high false negative rate, and has a high requirement for the segmentation of the response message. It is generally applicable to formatted response messages and has high application limitations.

[0052] Based on this, the present application provides a technical solution for passive scanning. By defining a sensitive information baseline, a large language model is used as a basis for specialized training as a sensitive information recognition model for response messages, so that the sensitive information recognition model can identify whether sensitive information is contained based on the content of the response body of the input response message. In this way, by inputting the content of the response body in the response message from the server into the sensitive information recognition model, the sensitive information recognition result output by the sensitive information recognition model can be obtained. The sensitive information recognition result is used to indicate whether sensitive information is contained. Further, it is determined whether the response message contains sensitive information based on the sensitive information recognition result.

[0053] The sensitive information identification model in the present application is a large language model trained with a second training corpus. The second training corpus is a text corpus containing sensitive information. Optionally, the sensitive information identification model is obtained by fine-tuning the large language model with the second training corpus. The present application uses a text corpus containing preset sensitive information to train a large language model, so that the sensitive information identification model obtained after training has the ability to identify sensitive information. By performing language analysis on the message content through the sensitive information identification model, compared with the above-mentioned information entropy detection method, the recognition accuracy of sensitive information in the response message is higher, and is not limited to the format of the response message, and has low application limitations.

[0054] In addition, when using the sensitive information identification model to determine whether the response body of a response message contains sensitive information, in addition to inputting the content of the response body of the response message to be identified into the sensitive information identification model, it is also necessary to input guidance information into the sensitive information identification model. The guidance information is used to guide the sensitive information identification model to perform the task of determining whether the input content contains sensitive information to output a determination result.

[0055] Optionally, the text corpus in the second training corpus is annotated with the category of sensitive information contained therein. Accordingly, the sensitive information identification result is used to indicate whether sensitive information is contained, including: the sensitive information identification result is used to indicate that sensitive information is not contained, or the sensitive information identification result is used to indicate the category of sensitive information contained. That is to say, in the case where the response body of the response message contains sensitive information, the sensitive information identification result output by the sensitive information identification model not only indicates that sensitive information is contained, but also indicates the category of sensitive information contained. The present application trains a large language model so that the sensitive information identification model obtained after training has the ability to identify and classify sensitive information. The sensitive information identification model can identify the category of sensitive information in a fine-grained manner, which helps to achieve rapid vulnerability location and vulnerability repair.

[0056] Optionally, the categories of sensitive information include, but are not limited to, one or more of a key, a user password, a user account, a user identity information, and a user communication address. The user communication address is, for example, an email address or a mobile phone number. Optionally, the sensitive information also includes some other authentication credentials, which are not described in detail in this application.

[0057] The following is a detailed introduction to the technical solution of this application from multiple angles, including application scenarios, hardware equipment, software devices, and method flows.

[0058] The following is an example of an application scenario of the embodiment of the present application.

[0059] For example, Figure 6 is a schematic diagram of an application scenario provided by an embodiment of the present application. Figure 6As shown, the application scenario includes a gateway device, a terminal, and one or more service servers. Optionally, the application scenario also includes a vulnerability testing device. Figure 6 Each device in the application scenario shown is introduced separately.

[0060] (1) Terminal

[0061] The terminal is, for example, a server, a host, a personal computer, a mobile phone or a workstation, etc. In some embodiments, the terminal is installed with a browser software or an application client, and the terminal sends a request message through the browser software or the application client to access the service server. Optionally, the terminal is located in the Internet.

[0062] (2) Business Server

[0063] The business server is used to provide services to terminals or other devices. For example, the business server is a web server, which is used to respond to HTTP requests from the browser software in the terminal, generate and return HTTP responses, and thus provide the terminal with the resources required to access the web page. In another example, the business server is other application servers, such as game servers, file servers, database servers, search engine servers, instant messaging servers, etc. The business server is used to respond to business processing requests from application clients in the terminal, thereby providing background services for the application.

[0064] (3) Gateway device

[0065] The gateway device is deployed between the terminal and the service server. In the process of vulnerability testing of the service server, the gateway device is used to obtain the messages exchanged between the terminal and the service server, send test messages to the service server, and receive response messages from the service server for the test messages. The gateway device is deployed, for example, between the enterprise network and the Internet. The enterprise network includes switches and service servers. The service server is connected to the switch. The switch is used to forward the data transmitted between the service server and the gateway device.

[0066] (4) Vulnerability testing equipment

[0067] The vulnerability testing device is connected to the gateway device through a network. The vulnerability testing device is used to interact with the gateway device to support the vulnerability testing process. For example, the vulnerability testing device is used to determine the vulnerability scanning scope, transmit the test payload, and verify the response message.

[0068] Optionally, in Figure 6In the application scenario shown, the vulnerability testing device collects the traffic between the terminal and the service server from the gateway device by setting a traffic probe on the gateway device or by using traffic sniffing. Alternatively, the vulnerability testing device can also collect the traffic between the terminal and the service server from the switch by setting a traffic probe on the switch or by using traffic sniffing. Alternatively, in the case where a proxy server is deployed in front of the service server, the traffic between the terminal and the service server can also be provided to the vulnerability testing device by means of traffic mirroring through the proxy server. Optionally, the proxy server is a firewall device working in proxy mode. For example, in a special test scenario, the tester can connect the vulnerability testing device to the proxy server deployed between the test terminal and the service server, and mirror the messages interacting between the test terminal and the service server to the vulnerability testing device through the proxy server.

[0069] It is worth mentioning that Figure 6 This is an example of a separate setting of a gateway device and a vulnerability testing device. In other embodiments, the gateway device and the vulnerability testing device are physically integrated. For example, the vulnerability testing device is a functional module inside the gateway device. For example, the physical entity of the vulnerability testing device is a service board, and by setting the service board in the gateway device, the gateway device integrates the vulnerability testing function.

[0070] In such Figure 6 In the application scenario shown, the gateway device can act as a communication bridge between the service server and the terminal. In the process of interaction between the service server and the terminal, the gateway device is responsible for forwarding the messages exchanged between the service server and the terminal. Specifically, the service server and the terminal communicate in the form of request and response. The process of the service server processing a request sent by the terminal includes the following steps 1 to 6.

[0071] Step 1: The user performs an operation on the terminal. In response to the user's operation, the terminal accesses the Internet application service (such as search engine service, instant messaging application, etc.) on the service server through a browser or other client.

[0072] Step 2: The terminal sends a request message to the service server. The request message corresponds to a protocol such as HTTP, HTTPs, SNMP, MIME or SOAP. The request message is sent by the terminal and arrives at the gateway device.

[0073] Step 3: After receiving the request message, the gateway device parses the content of the request message, determines that the sender of the request message is the terminal, and the destination of the request message is the service server, and then forwards the request message to the service server.

[0074] Step 4: After receiving the request message, the service server processes the request message, generates a response message based on the processing result, and returns the response message to the terminal.

[0075] Step 5: When the response message is sent from the service server to the terminal, the response message will pass through the gateway device. After the gateway device parses and processes the response message, it forwards the response message to the terminal through the original route.

[0076] Step 6: After the terminal receives the response message, a request response process is completed.

[0077] The hardware structure of the embodiment of the present application is described below with examples.

[0078] For example, Figure 7 It is a hardware structure diagram of a vulnerability testing device 700 provided in an embodiment of the present application. Figure 7 The vulnerability testing device 700 shown is, for example, Figure 1 The gateway device or vulnerability testing device in the application scenario shown. Figure 7 As shown, the vulnerability testing device 700 includes a processor 701 and a memory 702 , and the memory 701 and the memory 702 are connected via a bus 703 . Figure 7 The processor 701 and the memory 702 are described as being independent of each other. Optionally, the processor 701 and the memory 702 are integrated together.

[0079] The memory 702 is used to store computer programs, including operating systems and program codes. The memory 702 is a storage medium of various types, such as read-only memory (ROM), random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM), flash memory, optical storage, register, optical disk storage, optical disk storage, magnetic disk or other magnetic storage devices.

[0080] The processor 701 is a general-purpose processor or a special-purpose processor. The processor 701 may be a single-core processor or a multi-core processor. The processor 701 includes at least one circuit to execute the vulnerability testing method provided in the embodiment of the present application.

[0081] Optionally, the vulnerability testing device 700 further includes a network interface 704, which is connected to the processor 701 and the memory 702 via the bus 703. The network interface 704 enables the vulnerability testing device 700 to communicate with other devices. Figure 1 In the application scenario shown, the network interface 704 of the gateway device is used to communicate with the terminal and the service server to forward the messages exchanged between the service server and the terminal. Figure 6 In the vulnerability testing device in the application scenario shown, the network interface 704 is used to communicate with the gateway device to obtain the messages interacted between the service server and the terminal through the gateway device.

[0082] Optionally, the vulnerability testing device 700 further includes an input / output (I / O) interface 705, which is connected to the processor 701 and the memory 702 via the bus 703. The processor 701 can receive input commands or data, etc. via the I / O interface 705. The I / O interface 705 is used for the vulnerability testing device 700 to connect input devices, such as keyboards, mice, etc. Optionally, in some possible scenarios, the above-mentioned network interface 704 and the I / O interface 705 are collectively referred to as communication interfaces.

[0083] Optionally, the vulnerability testing device 700 further includes a display 706, which is connected to the processor 701 and the memory 702 via the bus 703. The display 706 can be used to display intermediate results and / or final results generated by the processor 701 executing the vulnerability testing method provided in the embodiment of the present application, such as vulnerability warnings, etc. In a possible implementation, the display 706 is a touch display screen to provide a human-computer interaction interface.

[0084] The bus 703 is any type of communication bus for interconnecting the internal devices of the vulnerability testing device 700. For example, a system bus. The embodiment of the present application takes the above-mentioned devices inside the vulnerability testing device 700 being interconnected through the bus 703 as an example. Optionally, the above-mentioned devices inside the vulnerability testing device 700 are connected to each other in a communication manner other than the bus 703, for example, the above-mentioned devices inside the vulnerability testing device 700 are interconnected through a logical interface inside the vulnerability testing device 700.

[0085] The above devices may be arranged on independent chips, or at least partially or completely on the same chip. Whether to arrange each device independently on different chips or to integrate them on one or more chips often depends on the needs of product design. The embodiments of the present application do not limit the specific implementation form of the above devices.

[0086] Figure 7 The vulnerability testing device 700 shown is merely exemplary. During implementation, the vulnerability testing device 700 includes other components, which are not listed one by one herein. Figure 7 The vulnerability testing device 700 shown can implement vulnerability testing on the server by executing all or part of the steps of the vulnerability testing method provided in the embodiment of the present application.

[0087] The following is an example of the method flow of the embodiment of the present application.

[0088] For example, Figure 8 It is a flowchart of a vulnerability testing method 800 provided in an embodiment of the present application.

[0089] Optionally, the deployment scenario of the gateway device, terminal, server, and vulnerability testing device involved in method 800 is as follows: Figure 6 For example, combining Figure 6 From the perspective of method 800, the gateway device is Figure 6 The gateway device in method 800 is Figure 6 The terminal in method 800 is Figure 6 Any business server in the method 800, the vulnerability testing device is Figure 6 Vulnerability testing equipment in.

[0090] Figure 8 In the example, the gateway device and the vulnerability testing device are two separate hardware devices. When the gateway device and the vulnerability testing device are integrated into the same hardware device (such as integrated into the gateway device), the following steps performed by the vulnerability testing device are actually performed by the gateway device. Figure 8 The gateway devices, terminals, servers and vulnerability testing equipment in the system have the following features: Figure 7 The hardware structure shown.

[0091] Step 801: The vulnerability testing device obtains a first request message sent by a terminal to a server through a gateway device.

[0092] In the process of transmitting messages between the terminal and the server, the gateway device acts as a bridge for communication between the terminal and the server, and all messages exchanged between the terminal and the server will reach the gateway device, that is, the gateway device can obtain the messages exchanged between the terminal and the server. The first request message is any request message sent by the terminal to the server. The source address of the first request message is the Internet Protocol (IP) address of the terminal, and the destination address is the IP address of the server. The terminal generates and sends the first request message, and the gateway device receives the first request message from the terminal.

[0093] Optionally, during the process of the vulnerability testing device performing the vulnerability test, the vulnerability testing device collects all traffic passing through the gateway device.

[0094] Step 802: The vulnerability testing device obtains a content summary of the first request message, where the content summary includes data operation information of the first request message for the server.

[0095] Optionally, the vulnerability testing device obtains a content summary output by the traffic analysis model by inputting the message content of the first request message into the traffic analysis model. The traffic analysis model is a large language model trained using the first training corpus. The first training corpus includes multiple sample request messages. The sample request message is annotated with field segmentation information, and the field segmentation information is used to distinguish the request header and the request body in the sample request message. For example, the sample request message Figures 1 to 5 .

[0096] In the embodiment of the present application, by training the large language model with sample request messages marked with field segmentation information, the language segmentation capability of the large language model for the request messages can be enhanced, thereby improving the traffic analysis efficiency of the large language model.

[0097] Optionally, the request body of the first request message includes one or more parameters, and the content summary of the first request message also includes risk tags corresponding to the one or more parameters. The risk tag is used to indicate whether the corresponding parameter has a vulnerability attack risk or does not have a vulnerability attack risk.

[0098] In the embodiment of the present application, by training the large language model, the traffic analysis model obtained after training has the ability to identify the risks of parameters in the request message. In this way, by guiding the traffic analysis model to output the risk tags of the parameters in the request body of the request message, the parameters without vulnerability attack risks do not need to participate in the vulnerability scan, which can reduce the number of redundant test messages, thereby improving the efficiency of vulnerability testing.

[0099] Optionally, the data operation information includes one or more data operation instructions. Each data operation instruction includes a data operation action and an operation object type for which the data operation action is directed. Among them, the data operation action includes a query operation, a write operation, a modification operation or a delete operation. The operation object type includes but is not limited to text, a table, a picture, a compressed package, an extensible markup language (XML) or a file. If the operation object type for which the data operation action is directed cannot be obtained based on the message content of the request message, the operation object type for which the data operation action is directed is recorded as "data" by default. For example, the application programming interface (API) of the request message corresponds to a query operation, and the parameters in the request body include the query quantity and the query object. The data operation information of the request message for the server includes a data operation instruction, which can be expressed as: data→query operation. For another example, the API of the request message corresponds to a delete operation, and the parameter is a delete object. The data operation information of the request message for the server includes a data operation instruction, which can be expressed as: data→delete operation. If the type of the deleted object is a file, the data operation instruction can be expressed as: file→delete operation.

[0100] Step 803: The vulnerability testing device determines a vulnerability scanning scope according to the data operation information, where the vulnerability scanning scope includes one or more vulnerability types that match the data operation information.

[0101] The vulnerability types that match the data operation information refer to the vulnerability types that may occur in the scenarios defined by the data operation information. For example, the vulnerability types that may be involved in the data operation "data → delete operation" include structured query language (SQL) injection and command injection. For another example, the vulnerability types that may be involved in the data operation "file → delete operation" include deleting arbitrary files and command injection.

[0102] Optionally, an implementation of step 803 includes: the vulnerability testing device obtains the vulnerability type corresponding to each data operation indication in the data operation information based on the vulnerability correspondence relationship. Among them, a data operation indication may correspond to one or more vulnerability types. The vulnerability correspondence relationship includes the correspondence between the data operation action, the operation object type and the vulnerability type. The vulnerability testing device uses at least one vulnerability type among all the acquired vulnerability types as the vulnerability scanning range. Among them, all the vulnerability types acquired by the vulnerability testing device include the full set of vulnerability types corresponding to each data operation indication in the data operation information.

[0103] Optionally, vulnerability types include but are not limited to SQL injection, arbitrary file download, arbitrary file reading, cross-site scripting (XSS) attack, XML external entity injection (XXE), cross-site request forgery (CSRF), expression injection, template injection. Optionally, the vulnerability correspondence preset in the embodiment of the present application includes all vulnerability types.

[0104] The embodiment of the present application presets a vulnerability correspondence relationship, filters and screens the vulnerability type for the data operation of the server according to the request message, thereby obtaining the vulnerability type that matches the data operation, which can improve the vulnerability detection efficiency.

[0105] Optionally, the vulnerability correspondence also includes the vulnerability weight of the vulnerability type, that is, the vulnerability correspondence includes the correspondence between data operation actions, operation object types, vulnerability types and vulnerability weights. The vulnerability weight is used to describe the probability of a vulnerability of the vulnerability type existing in a computer device in a scenario where the data operation action corresponding to the vulnerability type and the operation limited by the operation object type occur. For example, a vulnerability correspondence is "deletion operation (data operation action), file (operation object type), delete any file (vulnerability type), 0.8 (vulnerability weight)", which means that the vulnerability type corresponding to the file deletion operation includes "delete any file", and the probability of the computer device having the vulnerability of "delete any file" in the scenario where the file deletion operation occurs is 0.8. The larger the vulnerability weight, the greater the possibility that the corresponding vulnerability type will appear under the corresponding data operation. For example, the vulnerability correspondence is shown in Table 1.

[0106] Table 1

[0107]

[0108] For example, referring to Table 1, the vulnerability weight of "command injection" under "file → delete operation" is 0.1, and the vulnerability weight of "delete arbitrary files" under "file → delete operation" is 0.8, which means that under the data operation of "file → delete operation", the probability of occurrence of the vulnerability type of "delete arbitrary files" is higher than the probability of occurrence of the vulnerability type of "command injection".

[0109] Optionally, the vulnerability testing device uses at least one vulnerability type among all the acquired vulnerability types as an implementation of the vulnerability scanning range, including: for each vulnerability type among all the vulnerability types acquired by the vulnerability testing device, the vulnerability testing device performs the following steps to obtain the weighted vulnerability weight of each vulnerability type: obtain the vulnerability weight of the vulnerability type under all corresponding data operation instructions in the data operation information, thereby calculating the weighted vulnerability weight of the vulnerability type. The vulnerability testing device uses the vulnerability type whose weighted vulnerability weight is greater than the weight threshold among all the vulnerability types as the vulnerability scanning range.

[0110] For example, the data operation information of the request message for the server includes two data operation instructions, "file→delete operation" and "text→delete operation". Based on Table 1, it can be seen that all vulnerability types obtained by the vulnerability testing device include deleting arbitrary files, command injection and SQL injection. Among them, the vulnerability weight of "deleting arbitrary files" under the file→delete operation is 0.8, and the vulnerability weight under the text→delete operation is 0, so the weighted vulnerability weight of "deleting arbitrary files" is 0.8. The vulnerability weight of "command injection" under the file→delete operation is 0.1, and the vulnerability weight under the text→delete operation is 0.1, so the weighted vulnerability weight of "command injection" is 0.2. The vulnerability weight of "SQL injection" under the file→delete operation is 0, and the vulnerability weight under the text→delete operation is 0.1, so the weighted vulnerability weight of "SQL injection" is 0.1. Assuming that the weight threshold is set to 0.5, the vulnerability scanning range finally determined by the vulnerability testing device only includes the vulnerability type of deleting arbitrary files.

[0111] In an embodiment of the present application, by analyzing and determining the types of vulnerabilities that may occur under the data operation of the request message, the vulnerability types that are more likely to occur are used as the vulnerability scanning range. While ensuring the comprehensiveness of the vulnerability test, the vulnerability scanning range is narrowed as much as possible to further improve the vulnerability testing efficiency.

[0112] Alternatively, the vulnerability testing device may also use all acquired vulnerability types (ie, the complete set of vulnerability types corresponding to each data operation indication in the data operation information) as the vulnerability scanning range.

[0113] Step 804: The vulnerability testing device sends a test message to the server through the gateway device. The test message is generated according to the test payload corresponding to the vulnerability type within the vulnerability scanning range.

[0114] This test message is used to test whether there is a vulnerability in the server. In the case where the vulnerability testing device and the gateway device are two independent devices, the test message is generated by the vulnerability testing device, or by the gateway device. For example, the vulnerability testing device stores test payloads corresponding to various vulnerability types. After determining the vulnerability scanning range, the vulnerability testing device obtains the test payload corresponding to the vulnerability type within the vulnerability scanning range, and then generates a test message based on the obtained test payload, or sends the obtained test payload to the gateway device, and the gateway device generates a test message. Alternatively, the gateway device stores test payloads corresponding to various vulnerability types. After determining the vulnerability scanning range, the vulnerability testing device sends the vulnerability type within the vulnerability scanning range to the gateway device, and then the gateway device obtains the test payload corresponding to the vulnerability type within the vulnerability scanning range, and generates a test message based on the obtained test payload.

[0115] There are many ways to generate a test message, such as a vulnerability testing device or a gateway device using a test load to replace the field content of the first request message to obtain a test message, or reconstructing the test message according to the test load. The embodiment of the present application does not limit the method for generating a test message. Optionally, when the content summary of the first request message includes a risk mark corresponding to one or more parameters in the request body, the vulnerability testing device or the gateway device uses the test load to replace the content of the target parameter in the request body of the first request message to obtain a test message. Among them, the target parameter is a parameter that has a vulnerability attack risk among one or more parameters in the request body of the first request message. In this way, parameters that do not have a vulnerability attack risk no longer participate in vulnerability scanning, which can effectively reduce the number of redundant test messages, thereby improving vulnerability testing efficiency.

[0116] In an embodiment of the present application, the possible vulnerability types of the server are determined based on the data operation information of the request message on the server, and then the vulnerability load corresponding to the possible vulnerability type of the server is used to perform vulnerability testing on the server in a targeted manner, thereby reducing the testing of irrelevant vulnerability types and reducing the generation of redundant test messages, thereby improving the efficiency of vulnerability testing.

[0117] Furthermore, after sending the test message to the server through the gateway device, the vulnerability testing device continues to perform the following steps 805 to 806 to determine whether there is a vulnerability in the server.

[0118] Step 805: The vulnerability testing device obtains the first response message sent by the server to the test message through the gateway device.

[0119] After receiving the test message, the server obtains the test payload by parsing the test message. Optionally, the server parses the test payload and responds to the test payload, thereby generating a response message. In some embodiments, when the test message is an HTTP request message, the response message to the test message is an HTTP response message.

[0120] Step 806: If the first response message includes the expected result corresponding to the test payload, the vulnerability testing device determines that a vulnerability exists in the server.

[0121] The expected result reflects that the test payload was executed successfully. For example, if the test payload is whoami, the expected result corresponding to whoami is the username found by the server executing the whoami command. For example, the expected result corresponding to whoami includes keywords such as root, admin, and administrator. If the first response message includes root, admin, or administrator, it is determined that the server has a vulnerability.

[0122] In the embodiment of the present application, the data operation information of the request message for the server is determined by analyzing the message content of the request message sent by the terminal to the server, and then the vulnerability type matching the data operation information is selected as the vulnerability scanning range, and then the test load corresponding to the vulnerability type in the vulnerability scanning range is used to generate the test message. That is to say, in the embodiment of the present application, the vulnerability type that the server needs to test is screened out according to the data operation information of the request message for the server, which reduces the test of irrelevant vulnerability types and can reduce the generation of redundant test messages during the active scanning process, thereby improving the efficiency of vulnerability testing.

[0123] Optionally, after determining that a vulnerability exists in the server, the vulnerability testing device issues a vulnerability alarm to prompt operation and maintenance personnel to check and repair the vulnerability in a timely manner.

[0124] It is worth noting that the above steps 801 to 806 show the active scanning process of the vulnerability testing device for the server. Optionally, the vulnerability testing device also performs a passive scanning process for the server, and the specific implementation process is shown in the following steps 807 to 809.

[0125] Step 807: The vulnerability testing device obtains the second response message sent by the server to the terminal through the gateway device.

[0126] The second response message is a response message to the second request message sent by the terminal to the server. For example, the second request message is the same as the first request message, or the second request message is different from the first request message.

[0127] Step 808: The vulnerability testing device inputs the content of the response body in the second response message into the sensitive information identification model to obtain a sensitive information identification result output by the sensitive information identification model. The sensitive information identification result is used to indicate whether sensitive information is contained.

[0128] After the vulnerability testing device obtains the response message sent by the server to the terminal, it pre-processes the response message, splits the response code, response header and response body, and then inputs the content of the response body into the sensitive information recognition model. If the data type in the response body is json, the data in the response body is split according to key-value pairs, and then all the key-value pairs obtained by the split are input into the sensitive information recognition model so that the sensitive information recognition model can perform language analysis. If the data type in the response body is text, all the content of the response body is directly input into the sensitive information recognition model.

[0129] Among them, the sensitive information identification model is a large language model trained with the second training corpus. The second training corpus is a text corpus containing sensitive information. Optionally, the text corpus in the second training corpus is annotated with the category of the sensitive information contained. Accordingly, the sensitive information identification result is used to indicate whether sensitive information is contained, including: the sensitive information identification result is used to indicate that sensitive information is not contained, or the sensitive information identification result is used to indicate the category of the sensitive information contained. In an embodiment of the present application, by training the large language model, the sensitive information identification model obtained after training has the ability to identify and classify sensitive information. The sensitive information identification model can identify the category of sensitive information in a fine-grained manner, which helps to achieve rapid vulnerability location and vulnerability repair.

[0130] Optionally, the categories of sensitive information include, but are not limited to, one or more of keys, user passwords, user accounts, user identity information, and user communication addresses.

[0131] Step 809: The vulnerability testing device determines whether the second response message contains sensitive information based on the sensitive information identification result.

[0132] Optionally, after determining that the response message from the server contains sensitive information, the vulnerability testing device issues an information leakage alarm to prompt the operation and maintenance personnel to handle it in time. Optionally, the information leakage alarm includes the category of the leaked sensitive information. For example, if the response message includes "your password is Admin@123", the information leakage alarm issued by the vulnerability testing device indicates that the user password has been leaked.

[0133] In the embodiment of the present application, a large language model is trained using a text corpus containing preset sensitive information, so that the sensitive information recognition model obtained after training has the ability to recognize sensitive information. The sensitive information recognition model performs language analysis on the content of the response message, and the recognition accuracy of the sensitive information in the response message is high, and is not limited to the format of the response message, and has low application limitations.

[0134] The order of the steps of the above-mentioned vulnerability testing method provided in the embodiment of the present application can be appropriately adjusted, and the steps can also be increased or decreased accordingly according to the situation. Any technician familiar with the technical field can easily think of the method of change within the technical scope disclosed in this application, which should be covered within the scope of protection of this application. For example, the above-mentioned steps 801 to 806 show the active scanning process, and the above-mentioned steps 807 to 809 show the passive scanning process. In the embodiment of the present application, the vulnerability testing device can only execute the active scanning process, or it can only execute the passive scanning process, or it can execute the active scanning process and the passive scanning process. In the scenario where active scanning and passive scanning are combined, the vulnerability testing device can execute the passive scanning process on the basis of active scanning, for example, when the active scanning finds that the server has a vulnerability, the passive scanning process is executed again, or it can execute the active scanning process on the basis of passive scanning, for example, when the passive scanning finds that the server leaks sensitive information, the active scanning process is executed again, or it can execute the active scanning process and the passive scanning process at the same time.

[0135] In addition, the embodiment of the present application trains the large language model so that the large language model has the ability to segment the language of the request message, thereby realizing traffic analysis through the large language model to extract the message content summary. This concept can also be applied to the analysis and identification of attack traffic in the network, that is, to realize traffic analysis through the large language model to determine whether the message transmitted in the network belongs to attack traffic. For this implementation, the large language model can also be trained with specific training corpus, which will not be repeated in the embodiment of the present application.

[0136] The following is an example of a virtual device in an embodiment of the present application.

[0137] Fig. 9 Schematic diagram of a vulnerability testing device provided in an embodiment of the present application. Fig. 9 The vulnerability testing device of the structure shown is used to implement the method 800 described in the above embodiment. Optionally, Fig. 9 The vulnerability test equipment shown is Figure 6 Vulnerability testing equipment or gateway equipment in the application scenario shown. Fig. 9 As shown, the vulnerability testing device 900 includes an acquisition module 901 , a processing module 902 and a sending module 903 .

[0138] The acquisition module 901 is used to acquire the first request message sent by the terminal to the server through the gateway device, and the gateway device is deployed between the terminal and the server. The processing module 902 is used to obtain the content summary of the first request message, and the content summary includes the data operation information of the first request message for the server. The processing module 902 is also used to determine the vulnerability scanning range according to the data operation information, and the vulnerability scanning range includes one or more vulnerability types that match the data operation information. The sending module 903 is used to send a test message to the server through the gateway device. The test message is generated according to the test load corresponding to the vulnerability type within the vulnerability scanning range, and the test message is used to test whether there is a vulnerability in the server.

[0139] Here, please refer to the description in the previous method embodiment for the implementation process of the acquisition module 901, the processing module 902 and the sending module 903. For example, the acquisition module 901 adopts step 801 in method 800 to obtain the first request message sent by the terminal to the server through the gateway device; the processing module 902 adopts step 802 in method 800 to obtain the content summary of the first request message, and step 803 in method 800 determines the vulnerability scanning range according to the data operation information in the content summary; the sending module 903 adopts step 804 in method 800 to send a test message to the server through the gateway device. The embodiment of this application will not be repeated here.

[0140] Optionally, the processing module 902 is specifically used to obtain a content summary output by the traffic analysis model by inputting the message content of the first request message into the traffic analysis model, wherein the traffic analysis model is a large language model trained using a first training corpus, wherein the first training corpus includes a plurality of sample request messages, and the sample request messages are annotated with field segmentation information, and the field segmentation information is used to distinguish between a request header and a request body in the sample request message. Here, the implementation process of the processing module 902 may refer to the relevant description of step 802 in method 800.

[0141] Optionally, the plurality of sample request messages include one or more of HTTP request messages, HTTPs request messages, SNMP request messages, MIME request messages or SOAP request messages. For HTTP request messages or HTTPs request messages, the field segmentation information is used to distinguish between the request line, the request header and the request body.

[0142] Optionally, for an HTTP request message or an HTTPs request message, the field segmentation information is also used to distinguish a request method, a request uniform resource locator URL, and a protocol version in the request line.

[0143] Optionally, the parameters in the request body of the sample request message are marked with a risk tag, and the risk tag is used to indicate that the corresponding parameter has a vulnerability attack risk or does not have a vulnerability attack risk. The request body of the first request message includes one or more parameters, and the content summary of the first request message also includes risk tags corresponding to one or more parameters. Processing module 902 is also used to replace the content of the target parameter in the request body of the first request message with a test payload to obtain a test message, wherein the target parameter is a parameter in one or more parameters that has a vulnerability attack risk.

[0144] Optionally, the data operation information includes one or more data operation instructions, each data operation instruction includes a data operation action and an operation object type for the data operation action, wherein the data operation action includes a query operation, a write operation, a modification operation or a deletion operation, and the operation object type includes text, a table, a picture, a compressed package, an extensible markup language or a file.

[0145] Optionally, the processing module 902 is further configured to obtain, for each data operation indication in the data operation information, a vulnerability type corresponding to the data operation indication based on a vulnerability correspondence relationship, wherein the vulnerability correspondence relationship includes a correspondence relationship between a data operation action, an operation object type, and a vulnerability type; and use at least one vulnerability type among all the acquired vulnerability types as a vulnerability scanning range. Here, the implementation process of the processing module 902 may refer to the relevant description of step 803 in the method 800.

[0146] Optionally, the vulnerability correspondence also includes a vulnerability weight of the vulnerability type, and the vulnerability weight is used to describe the probability that a vulnerability of the vulnerability type exists in a computer device in a scenario where a data operation action corresponding to the vulnerability type and an operation defined by the operation object type occur. Processing module 902 is specifically used to perform the following steps for each vulnerability type among all vulnerability types to obtain a weighted vulnerability weight for each vulnerability type: obtain the vulnerability weight of the vulnerability type under all corresponding data operation instructions in the data operation information, thereby calculating the weighted vulnerability weight of the vulnerability type; and use the vulnerability type whose weighted vulnerability weight is greater than the weight threshold among all vulnerability types as the vulnerability scanning range. Here, the implementation process of processing module 902 can refer to the relevant description of step 803 in method 800.

[0147] Optionally, the acquisition module 901 is further used to acquire, through the gateway device, a first response message sent by the server to the test message. The processing module 902 is further used to determine that the server has a vulnerability if the first response message includes an expected result corresponding to the test load, and the expected result reflects that the test load is successfully executed. Here, the implementation process of the acquisition module 901 can refer to the relevant description of step 805 in method 800, and the implementation process of the processing module 902 can refer to the relevant description of step 806 in method 800.

[0148] Attached Fig. 9 The device embodiments described are merely illustrative. For example, the division of the modules is merely a logical function division. There may be other division methods in actual implementation. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. The functional modules in the various embodiments of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into one module. Fig. 9 The above modules can be implemented in the form of hardware or software functional units. For example, when software is used, the processing module 902 can be implemented by the attached Figure 7 The processor 701 in the processor 701 reads the program instructions stored in the memory 702 and generates a software function module to implement it. Fig. 9 The above modules can also be implemented by different hardware in the vulnerability testing device. For example, the processing module 902 is implemented by the attached Figure 7 The acquisition module 901 and the sending module 903 are implemented by a part of the processing resources in the processor 701 (for example, a core in a multi-core processor), and the acquisition module 901 and the sending module 903 are implemented by the attached Figure 7 The network interface 704 and the rest of the processing resources in the processor 701 (such as other cores in a multi-core processor) are used to complete the process. Obviously, the above functional modules can also be implemented in a combination of software and hardware. For example, the acquisition module 901 and the sending module 903 are implemented by hardware programmable devices, and the processing module 902 is a software functional module generated by the processor after reading the program instructions stored in the memory.

[0149] The embodiment of the present application also provides a vulnerability testing device, including: a memory, a network interface and at least one processor, wherein the memory is used to store program instructions, and after the at least one processor reads the program instructions stored in the memory, the vulnerability testing device executes the steps in the above method 800. Optionally, the hardware structure of the vulnerability testing device is as follows: Figure 7 shown.

[0150] The embodiment of the present application further provides a computer-readable storage medium, on which instructions are stored. When the instructions are executed by a processor, the steps in the above method 800 are implemented.

[0151] The embodiment of the present application further provides a computer program product, including a computer program, and when the computer program is executed by a processor, the steps in the above method 800 are implemented.

[0152] In the embodiments of the present application, the term traffic is also referred to as network traffic or data traffic. Traffic refers to data transmitted through a network at a given point in time. For example, the traffic received by a device at time point T refers to all messages received by the device at time point T.

[0153] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from other embodiments.

[0154] The terms "first" and "second" in the description and claims of the embodiments of the present application are used to distinguish different objects, rather than to describe the specific order of the objects, and cannot be understood as indicating or implying relative importance. For example, the first TCP message and the second TCP message are used to distinguish messages sent at different times, rather than to describe the specific order of the messages.

[0155] In the description of the embodiments of the present application, unless otherwise specified, "at least one" means one or more, and "plurality" means two or more.

[0156] A refers to B, which means that A is the same as B or A is a simple variant of B.

[0157] The term "and / or" in this application is only a description of the association relationship of associated objects, indicating the existence of three relationships. For example, A and / or B means: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0158] Optionally, in the above embodiments, all or part of the embodiments are implemented by software, hardware, firmware or any combination thereof. Optionally, when implemented using software, all or part of the embodiments are implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. Optionally, the computer is a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Optionally, the computer instructions are stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. Optionally, the computer-readable storage medium is any available medium that a computer can access or a data storage device such as a server or data center that contains one or more available media integrated. Optionally, the available medium is a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital video disk (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0159] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, a person of ordinary skill in the art should understand that it is still possible to modify the technical solutions described in the aforementioned embodiments, or to perform equivalent replacements on some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A vulnerability testing method, characterized in that: The method comprises: Acquire a first request message sent by a terminal to a server through a gateway device, wherein the gateway device is deployed between the terminal and the server; Obtaining a content summary of the first request message, wherein the content summary includes data operation information of the first request message for the server; Determining a vulnerability scanning scope according to the data operation information, wherein the vulnerability scanning scope includes one or more vulnerability types matching the data operation information; A test message is sent to the server through the gateway device, wherein the test message is generated according to a test load corresponding to a vulnerability type within the vulnerability scanning range, and the test message is used to test whether the server has a vulnerability.

2. The method according to claim 1, characterized in that The obtaining of the content summary of the first request message includes: By inputting the message content of the first request message into the traffic analysis model, the content summary output by the traffic analysis model is obtained, the traffic analysis model is a large language model trained using a first training corpus, the first training corpus includes multiple sample request messages, the sample request messages are marked with field segmentation information, and the field segmentation information is used to distinguish between a request header and a request body in the sample request message.

3. The method according to claim 2, characterized in that The multiple sample request messages include one or more of a Hypertext Transfer Protocol (HTTP) request message, a Hypertext Transfer Security (HTTPS) request message, a Simple Network Management Protocol (SNMP) request message, a Multipurpose Internet Mail Extensions (MIME) request message, or a Simple Object Access Protocol (SOAP) request message; For the HTTP request message or the HTTPs request message, the field segmentation information is used to distinguish the request line, the request header and the request body.

4. The method according to claim 3, characterized in that: For the HTTP request message or the HTTPs request message, the field segmentation information is also used to distinguish the request method, request uniform resource locator URL and protocol version in the request line.

5. The method according to any one of claims 2 to 4, characterized in that: The parameters in the request body of the sample request message are marked with risk tags, and the risk tags are used to indicate whether the corresponding parameters have vulnerability attack risks or do not have vulnerability attack risks; The request body of the first request message includes one or more parameters, the content summary also includes risk tags corresponding to the one or more parameters, and the method further includes: The test payload is used to replace the content of the target parameter in the request body of the first request message to obtain the test message, wherein the target parameter is a parameter among the one or more parameters that has a vulnerability attack risk.

6. The method according to any one of claims 1 to 5, characterized in that: The data operation information includes one or more data operation instructions, each of which includes a data operation action and an operation object type targeted by the data operation action, wherein the data operation action includes a query operation, a write operation, a modification operation or a deletion operation, and the operation object type includes text, a table, a picture, a compressed package, an extensible markup language or a file.

7. The method according to claim 6, characterized in that Determining the vulnerability scanning scope according to the data operation information includes: For each data operation instruction in the data operation information, obtaining a vulnerability type corresponding to the data operation instruction based on a vulnerability correspondence relationship, wherein the vulnerability correspondence relationship includes a correspondence relationship between a data operation action, an operation object type, and a vulnerability type; At least one vulnerability type among all acquired vulnerability types is used as the vulnerability scanning range.

8. The method according to claim 7, characterized in that The vulnerability correspondence also includes a vulnerability weight of the vulnerability type, and the vulnerability weight is used to describe the probability that a vulnerability of the vulnerability type exists in a computer device under a scenario where a data operation action corresponding to the vulnerability type and an operation defined by an operation object type occur. The method of using at least one vulnerability type among all acquired vulnerability types as the vulnerability scanning range includes: For each vulnerability type among all the vulnerability types, the following steps are performed to obtain a weighted vulnerability weight of each vulnerability type: obtaining the vulnerability weight of the vulnerability type under all corresponding data operation instructions in the data operation information, thereby calculating the weighted vulnerability weight of the vulnerability type; The vulnerability types whose weighted vulnerability weights are greater than a weight threshold among all the vulnerability types are used as the vulnerability scanning scope.

9. The method according to any one of claims 1 to 8, characterized in that: After sending the test message to the server through the gateway device, the method further includes: Acquire, through the gateway device, a first response message sent by the server to the test message; If the first response message includes the expected result corresponding to the test payload, it is determined that a vulnerability exists in the server, and the expected result reflects that the test payload is executed successfully.

10. A vulnerability testing device, characterized in that: include: memory, a network interface and at least one processor, The memory is used to store program instructions. After the at least one processor reads the program instructions stored in the memory, the vulnerability testing device performs the following operations: Acquire a first request message sent by a terminal to a server through a gateway device, wherein the gateway device is deployed between the terminal and the server; Obtaining a content summary of the first request message, wherein the content summary includes data operation information of the first request message for the server; Determining a vulnerability scanning scope according to the data operation information, wherein the vulnerability scanning scope includes one or more vulnerability types matching the data operation information; A test message is sent to the server through the gateway device, wherein the test message is generated according to a test load corresponding to a vulnerability type within the vulnerability scanning range, and the test message is used to test whether the server has a vulnerability.

11. The device according to claim 10, characterized in that After the program instructions are read by the at least one processor, the vulnerability testing device performs the following operations: By inputting the message content of the first request message into the traffic analysis model, the content summary output by the traffic analysis model is obtained, the traffic analysis model is a large language model trained using a first training corpus, the first training corpus includes multiple sample request messages, the sample request messages are marked with field segmentation information, and the field segmentation information is used to distinguish between a request header and a request body in the sample request message.

12. The device according to claim 11, characterized in that The multiple sample request messages include one or more of a Hypertext Transfer Protocol (HTTP) request message, a Hypertext Transfer Security (HTTPS) request message, a Simple Network Management Protocol (SNMP) request message, a Multipurpose Internet Mail Extensions (MIME) request message, or a Simple Object Access Protocol (SOAP) request message; For the HTTP request message or the HTTPs request message, the field segmentation information is used to distinguish the request line, the request header and the request body.

13. The device according to claim 12, characterized in that For the HTTP request message or the HTTPs request message, the field segmentation information is also used to distinguish the request method, request uniform resource locator URL and protocol version in the request line.

14. The device according to any one of claims 10 to 13, characterized in that The parameters in the request body of the sample request message are marked with risk tags, and the risk tags are used to indicate whether the corresponding parameters have vulnerability attack risks or do not have vulnerability attack risks; The request body of the first request message includes one or more parameters, the content summary also includes risk tags corresponding to the one or more parameters, and after the program instructions are read by the at least one processor, the vulnerability testing device further performs the following operations: The test payload is used to replace the content of the target parameter in the request body of the first request message to obtain the test message, wherein the target parameter is a parameter among the one or more parameters that has a vulnerability attack risk.

15. The device according to any one of claims 10 to 14, characterized in that The data operation information includes one or more data operation instructions, each of which includes a data operation action and an operation object type targeted by the data operation action, wherein the data operation action includes a query operation, a write operation, a modification operation or a deletion operation, and the operation object type includes text, a table, a picture, a compressed package, an extensible markup language or a file.

16. The device according to claim 15, characterized in that After the program instructions are read by the at least one processor, the vulnerability testing device performs the following operations: For each data operation instruction in the data operation information, obtaining a vulnerability type corresponding to the data operation instruction based on a vulnerability correspondence relationship, wherein the vulnerability correspondence relationship includes a correspondence relationship between a data operation action, an operation object type, and a vulnerability type; At least one vulnerability type among all acquired vulnerability types is used as the vulnerability scanning range.

17. The device according to claim 16, characterized in that The vulnerability correspondence also includes a vulnerability weight of the vulnerability type, and the vulnerability weight is used to describe the probability that a vulnerability of the vulnerability type exists in the computer device under a scenario where a data operation action corresponding to the vulnerability type and an operation defined by an operation object type occur. After the program instruction is read by the at least one processor, the vulnerability testing device performs the following operations: For each vulnerability type among all the vulnerability types, the following steps are performed to obtain a weighted vulnerability weight of each vulnerability type: obtaining the vulnerability weight of the vulnerability type under all corresponding data operation instructions in the data operation information, thereby calculating the weighted vulnerability weight of the vulnerability type; The vulnerability types whose weighted vulnerability weights are greater than a weight threshold among all the vulnerability types are used as the vulnerability scanning scope.

18. The device according to any one of claims 10 to 17, characterized in that After the program instructions are read by the at least one processor, the vulnerability testing device further performs the following operations: Acquire, through the gateway device, a first response message sent by the server to the test message; If the first response message includes the expected result corresponding to the test payload, it is determined that a vulnerability exists in the server, and the expected result reflects that the test payload is executed successfully.

19. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed by a processor, the method according to any one of claims 1 to 9 is implemented.

Images