Vulnerability scanning system and method

Abstract

The invention discloses a vulnerability scanning system and method, and relates to the technical field of vulnerability detection, and the system comprises the steps that a front-end Web control module generates a request data packet according to plug-in basic information input by a user; the back-end scheduling module performs plug-in conversion on the request data packet, and a generated vulnerability detection plug-in is uploaded to a back-end database; calling a plug-in list of a back-end database according to the timing scanning signal, and sending the plug-in list to a back-end scanning engine; and the back-end scanning engine calls the vulnerability detection plug-in to perform vulnerability scanning on the back-end service subsystem according to the plug-in list to generate a vulnerability scanning result. The vulnerability detection plug-in is directly uploaded to the back-end database, and the back-end scanning engine calls the back-end service subsystem to perform vulnerability scanning, so that the vulnerability scanning process is simplified, the complex identity authentication process can be bypassed for the event-type vulnerability in the online banking service flow, the security monitoring can be continuously and automatically performed, and the vulnerability detection efficiency is improved. And the vulnerability detection effect is improved.

Description

Technical Field

[0001] The present application relates to the technical field of vulnerability detection, and in particular to a vulnerability scanning system and method. Background Art

[0002] In the vulnerability detection field, the basic modules of similar tools currently consist of plug-in modules and engine modules. Plugin modules can be divided into two types: programming language plug-ins and YAML (Yet Another Markup Language) format plug-ins. During operation, it is necessary to pre-specify a list of URLs or IP addresses to test or attack, and then select a vulnerability plug-in to attack and exploit. This technical solution mainly targets general vulnerability detection and exploitation in mainstream third-party components.

[0003] However, in online banking environments, most security testing involves business security testing, which constantly exposes various security risks and vulnerabilities. These vulnerabilities are typically event-based. Detecting event-based vulnerabilities requires identity authentication, credential transfer, or unauthorized access verification. However, this process becomes particularly complex when obtaining permissions, resulting in limited vulnerability detection effectiveness. Summary of the Invention

[0004] The main purpose of this application is to provide a vulnerability scanning system and method, which aims to solve the technical problem that event-type vulnerabilities in the online banking business environment become particularly complicated to obtain permissions during the detection process, resulting in poor vulnerability detection results.

[0005] To achieve the above objectives, the present application proposes a vulnerability scanning system, which includes: a front-end Web control module, a back-end scheduling module, and a back-end scanning engine;

[0006] The front-end Web control module is used to generate a request data packet according to the basic information of the plug-in input by the user, and send the request data packet to the back-end scheduling module;

[0007] The backend scheduling module is used to convert the request data packet into a plug-in, generate a corresponding vulnerability detection plug-in, and upload the vulnerability detection plug-in to the backend database;

[0008] The backend scheduling module is further configured to call the plug-in list of the backend database according to the timing scanning signal, and send the plug-in list to the backend scanning engine;

[0009] The backend scanning engine is used to call the vulnerability detection plug-in according to the plug-in list to perform vulnerability scanning on the backend business subsystem and generate vulnerability scanning results.

[0010] In one embodiment, the backend scheduling module is further configured to perform routing conversion on the request data packet and generate an access address of the backend business subsystem;

[0011] The backend scheduling module is further configured to extract user information from the request data packet and use the user information as a credential header to construct an access traffic packet corresponding to the backend business subsystem;

[0012] The backend scheduling module is further configured to perform plug-in conversion according to the access address and the access traffic packet to generate a vulnerability detection plug-in corresponding to the request data packet;

[0013] The back-end scheduling module is also used to upload the vulnerability detection plug-in to the back-end database for storage.

[0014] In one embodiment, the backend scheduling module is further configured to extract header parameters from the request data packet, wherein the header parameters include a uniform resource locator and a Host header field;

[0015] The backend scheduling module is further configured to simulate the routing conversion operation of the gateway through the routing table based on the header parameters, and determine the subsystem to be matched corresponding to the header parameters in the backend business subsystem;

[0016] The backend scheduling module is further configured to rewrite the header parameters to generate an access address of the subsystem to be aligned.

[0017] In one embodiment, the front-end Web control module is further configured to, upon receiving a user's request to add a new plug-in, display a plug-in form page to the user, so that the user can fill in basic plug-in information and user information based on the plug-in form page;

[0018] The front-end Web control module is further used to verify the integrity of the basic information of the plug-in and generate a verification result;

[0019] The front-end Web control module is further configured to encapsulate the plug-in basic information and the user information to obtain a request data packet when the verification result is integrity passed;

[0020] The front-end Web control module is further configured to send the request data packet to the back-end scheduling module.

[0021] In one embodiment, the vulnerability scanning system further includes: an alarm push module;

[0022] The alarm push module is used to pull vulnerability scan results from the backend database and determine whether there is an event-type vulnerability in the vulnerability scan results.

[0023] The alarm push module is further configured to detect event-type vulnerabilities when there are event-type vulnerabilities in the vulnerability scan results, and determine vulnerability location information and vulnerability repair suggestions for the event-type vulnerabilities;

[0024] The alarm push module is also used to push the vulnerability location information and the vulnerability repair suggestion to the work person in charge for alarm.

[0025] In one embodiment, the vulnerability scanning system further includes: a timing module;

[0026] The timing module is used to generate a timing scanning signal at a preset time point and send the timing scanning signal to the back-end scheduling module;

[0027] The backend scheduling module is further configured to pull a plug-in list from the backend database according to the timing scanning signal, wherein the plug-in list includes plug-in information of the vulnerability detection plug-in;

[0028] The backend scheduling module is further configured to send the plug-in information to the backend scanning engine.

[0029] In one embodiment, the backend scanning engine is further configured to update the local plug-in library according to the plug-in information to obtain a plurality of local updated plug-ins;

[0030] The backend scanning engine is further configured to enable multi-threaded synchronous execution of the multiple local update plug-ins;

[0031] The local update plug-in is used to initiate an interface request to the backend business subsystem according to user information, perform a vulnerability scan on the backend business subsystem according to a preset scanning strategy based on the interface request, and transmit the generated vulnerability scan results back to the backend scanning engine;

[0032] The backend scanning engine is further configured to return the vulnerability scanning result to the backend scheduling module;

[0033] The backend scheduling module is further configured to insert the vulnerability scanning result into the backend database for storage.

[0034] In addition, to achieve the above-mentioned purpose, the present application also proposes a vulnerability scanning method, which is applied to a vulnerability scanning system, wherein the vulnerability scanning system includes a front-end Web control module, a back-end scheduling module, and a back-end scanning engine; the method includes:

[0035] The front-end Web control module generates a request data packet according to the basic information of the plug-in input by the user, and sends the request data packet to the back-end scheduling module;

[0036] The backend scheduling module converts the request data packet into a plug-in, generates a corresponding vulnerability detection plug-in, and uploads the vulnerability detection plug-in to the backend database;

[0037] The backend scheduling module calls the plug-in list of the backend database according to the timing scanning signal, and sends the plug-in list to the backend scanning engine;

[0038] The backend scanning engine calls the vulnerability detection plug-in according to the plug-in list to perform vulnerability scanning on the backend business subsystem and generate vulnerability scanning results.

[0039] In one embodiment, the backend scheduling module converts the request data packet into a plug-in, generates a corresponding vulnerability detection plug-in, and uploads the vulnerability detection plug-in to the backend database, including:

[0040] The back-end scheduling module performs routing conversion on the request data packet and generates an access address of the back-end business subsystem;

[0041] The backend scheduling module extracts the user information of the request data packet and uses the user information as a credential header to construct an access traffic packet corresponding to the backend business subsystem;

[0042] The backend scheduling module performs plug-in conversion according to the access address and the access traffic packet to generate a vulnerability detection plug-in corresponding to the request data packet;

[0043] The back-end scheduling module uploads the vulnerability detection plug-in to the back-end database for storage.

[0044] In one embodiment, the step of performing routing conversion on the request data packet by the backend scheduling module to generate an access address of the backend service subsystem includes:

[0045] The backend scheduling module extracts header parameters from the request data packet, wherein the header parameters include a uniform resource locator and a Host header field;

[0046] The backend scheduling module simulates the routing conversion operation of the gateway through the routing table based on the header parameters, and determines the subsystem to be matched corresponding to the header parameters in the backend business subsystem;

[0047] The backend scheduling module rewrites the header parameters to generate an access address of the subsystem to be aligned.

[0048] One or more technical solutions proposed in this application have at least the following technical effects: the vulnerability scanning system of this application includes: a front-end Web control module, a back-end scheduling module and a back-end scanning engine; the front-end Web control module is used to generate a request data packet based on the basic plug-in information input by the user, and send the request data packet to the back-end scheduling module; the back-end scheduling module is used to convert the request data packet into a plug-in, generate a corresponding vulnerability detection plug-in, and upload the vulnerability detection plug-in to the back-end database; the back-end scheduling module is also used to call the plug-in list of the back-end database according to the timed scanning signal, and send the plug-in list to the back-end scanning engine; the back-end scanning engine is used to call the vulnerability detection plug-in according to the plug-in list to perform a vulnerability scan on the back-end business subsystem and generate a vulnerability scanning result.

[0049] Since this application directly uploads the vulnerability detection plug-in to the back-end database and performs vulnerability scanning on the back-end business subsystem through the back-end scanning engine, the vulnerability scanning process is simplified. For event-type vulnerabilities in online banking business traffic, the complex identity authentication process can be bypassed, and continuous and automated security monitoring can be performed, thereby improving the vulnerability detection effect. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0051] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0052] Figure 1 Module diagram provided for the first embodiment of the vulnerability scanning system of this application;

[0053] Figure 2 The overall call flow chart provided for the vulnerability scanning system of this application;

[0054] Figure 3 A flowchart of the first embodiment of the vulnerability scanning method of this application is provided;

[0055] Figure 4 Schematic diagram of the plug-in conversion process provided for the vulnerability scanning method of this application.

[0056] The realization of the objectives, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0057] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0058] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0059] The present application embodiment provides a vulnerability scanning system, referring to Figure 1 , Figure 1 This is a module diagram provided for the first embodiment of the vulnerability scanning system of this application.

[0060] In this embodiment, the vulnerability scanning system includes: a front-end Web control module 10 , a back-end scheduling module 20 and a back-end scanning engine 30 .

[0061] The front-end Web control module 10 is used to generate a request data packet according to the basic information of the plug-in input by the user, and send the request data packet to the back-end scheduling module 20.

[0062] It should be noted that the basic information of the plug-in is the data content provided by the user for vulnerability detection, which may include the definition of a specific vulnerability type, plug-in name, plug-in description, writing date, etc.

[0063] It is understandable that the request data packet encapsulates various instructions and data content related to generating a vulnerability detection plug-in, which can be identified and processed by the back-end scheduling module, so that the back-end scheduling module can perform plug-in conversion based on this information.

[0064] It should be understood that the front-end web control module is the part of the vulnerability scanning system that directly interacts with users. It provides a web-based interface through which users can enter basic plug-in information. The front-end web control module primarily facilitates interaction with relevant web pages, including functions such as adding and uploading plug-ins, querying plug-in lists, querying scan progress, and querying scan results. This module also involves interaction with the back-end scheduling module.

[0065] In the implementation, plugins need to be uploaded at the initial stage of the process. Two methods are supported: directly uploading the code plugin or automatically converting the data package into a code plugin before uploading. For code plugin conversion, the front-end web control module receives the basic plugin information entered by the user, encodes it according to a pre-set format, adds metadata such as the module identifier, and forms a request data package. The package is then sent to the back-end scheduling module.

[0066] In a feasible implementation manner, the front-end Web control module 10 described in this embodiment is also used to display a plug-in form page to the user when receiving a user's plug-in addition request, so that the user can fill in the plug-in basic information and user information based on the plug-in form page; the front-end Web control module 10 is also used to verify the integrity of the plug-in basic information and generate a verification result; the front-end Web control module 10 is also used to encapsulate the plug-in basic information and the user information when the verification result is integrity passed to obtain a request data packet; the front-end Web control module 10 is also used to send the request data packet to the back-end scheduling module 20.

[0067] It should be noted that a new plug-in request is a user-initiated request to add a new plug-in to the system. The plug-in form page is a specific page displayed by the front-end web control module for users to fill in basic plug-in-related information. This page allows users to enter basic plug-in information as well as their own information, serving as a medium for user input.

[0068] It is understandable that user information is the identity or contact information related to the user using the system, such as user name, contact information, etc.

[0069] It should be understood that integrity verification is an inspection operation performed by the front-end Web control module on the basic plug-in information filled in by the user. The inspection content may include whether the required items are filled in, whether the information format is correct, etc., to ensure that the obtained basic plug-in information is complete and valid.

[0070] In this implementation, for adding and uploading plugins, the front-end web control module provides a plugin form page where users fill in basic plugin information (e.g., plugin name, description, etc.) and user information, and then upload the plugin code file. The form is then used for integrity verification to ensure data integrity. The plugin basic information and user information are then encapsulated in JSON format and sent to the back-end scheduling module via an HTTP request. This integrity verification ensures information quality and improves the reliability and efficiency of the plugin addition process.

[0071] The backend scheduling module 20 is used to convert the request data packet into a plug-in, generate a corresponding vulnerability detection plug-in, and upload the vulnerability detection plug-in to the backend database.

[0072] It's important to note that vulnerability detection plugins are program components specifically designed to detect specific types of vulnerabilities, such as event-based vulnerabilities. Each vulnerability detection plugin includes basic plugin information, such as its name, description, channel and branch number, creation date, modification date, and author. It also includes the plugin's vulnerability detection code, which implements the basic vulnerability principle, HTTP packet sending process, and final vulnerability identification verification.

[0073] It's understood that the backend database serves as a storage system for vulnerability detection plug-ins generated by the backend scheduling module, forming a plug-in list. The backend database provides data support for the backend scheduling module and the backend scanning engine, streamlining the vulnerability scanning process on the post-login interface and the transmission of credential-related parameters such as tokens, ensuring the proper operation of the vulnerability scanning system.

[0074] It should be understood that the backend scheduling module performs the core scheduling and conversion tasks in the vulnerability scanning system. It can be built as a web application based on the Flask framework, serving as a bridge between the input of the front-end web control module and the back-end scanning engine. The back-end scheduling module not only handles the interaction and response of the front-end web control module's simple interface, but also receives relevant timing signals to initiate scanning tasks, triggering the scheduling and execution of the back-end scanning engine, ensuring that the entire vulnerability scanning system operates in an orderly manner according to pre-defined rules.

[0075] In the specific implementation, the back-end scheduling module can first parse the basic information of the plug-in in the request data packet, generate the vulnerability detection plug-in code according to predefined rules, perform function configuration and debugging, ensure the validity of the plug-in, and then upload it to the back-end database for storage.

[0076] In a feasible implementation manner, the back-end scheduling module 20 described in this embodiment is also used to perform routing conversion on the request data packet to generate an access address of the back-end business subsystem; the back-end scheduling module 20 is also used to extract user information of the request data packet, and use the user information as a credential header to construct an access traffic packet corresponding to the back-end business subsystem; the back-end scheduling module 20 is also used to perform plug-in conversion based on the access address and the access traffic packet to generate a vulnerability detection plug-in corresponding to the request data packet; the back-end scheduling module 20 is also used to upload the vulnerability detection plug-in to the back-end database for storage.

[0077] It should be noted that the back-end business subsystem is the back-end part of the entire online banking business system. For example, it is specifically responsible for processing a certain type of business data, executing specific business logic, etc. Different subsystems work together to complete the business needs of the back-end of the entire online banking business system.

[0078] It is understandable that the access address is an identifier used to access the backend business subsystem. Through the access address, the corresponding business subsystem can be accurately found to perform operations such as data interaction.

[0079] Specifically, in another feasible implementation manner, the back-end scheduling module 20 described in this embodiment is also used to extract header parameters from the request data packet, and the header parameters include a uniform resource locator and a Host header field; the back-end scheduling module 20 is also used to simulate the routing conversion operation of the gateway through the routing table based on the header parameters, and determine the subsystem to be matched corresponding to the header parameters in the back-end business subsystem; the back-end scheduling module 20 is also used to rewrite the header parameters to generate an access address of the subsystem to be matched.

[0080] It should be noted that the header parameters are important information related to the target address of the request contained in the request data packet, such as the Uniform Resource Locator (URL) and the Host header field.

[0081] The Uniform Resource Locator (URL) is used to identify the address of resources on the backend business subsystem and may include information such as protocol, domain name, path, etc. The Host header field is used to specify the host name to be accessed by the backend business subsystem.

[0082] It is understandable that the routing table is a data structure that stores routing information of various destinations in the backend business subsystem, defines how to forward incoming request packets to different backend business subsystems, and is used to assist the routing conversion operation of the simulation gateway.

[0083] It should be understood that the subsystem to be matched is a subsystem that is determined in the backend business subsystem based on the header parameters to match and interact with the request data packet.

[0084] Specifically, when a request packet is received, the URL, Host, and other header parameters in the request are checked, and then a matching rule is searched in the routing table. Based on the matching result, the backend business subsystem to which the request packet is forwarded is determined.

[0085] In this embodiment, by simulating the routing conversion operation of the gateway, the subsystem to be matched can be accurately determined, and then the header parameters are rewritten to generate the correct access address that the back-end subsystem can directly accept, thereby ensuring that the request can accurately reach the back-end business subsystem.

[0086] It is understandable that the credential header is the part used to place user information when constructing the access traffic packet. It is the identification part of the access traffic packet. Through this part, the back-end business subsystem can verify the visitor's identity and other related information.

[0087] The access traffic packet is a data packet containing user information (as a credential header) and is used to initiate an access request to the back-end business subsystem. It is the data carrier for interacting with the back-end business subsystem.

[0088] In this embodiment, when performing plug-in conversion, the back-end scheduling module extracts the header parameters (such as URL, Host and other parameters) in the request data packet, and then simulates the routing conversion operation of the gateway based on the routing table in the configuration file, rewrites the URL, and generates a direct access address for the back-end business subsystem, which is convenient for access and request in the plug-in. Then, the user information is used as the credential header of the request data packet to construct the access traffic packet of the back-end business subsystem. Finally, the plug-in code of the relevant request data packet is automatically generated based on the access address and the access traffic packet to generate a vulnerability detection plug-in. By directly sending packets to the back-end business system, the security vulnerabilities of the business can be automatically scanned and monitored, and the online banking channel, user number, enterprise number and other information can be automatically identified. The vulnerability detection script code is generated according to the vulnerability type to form a vulnerability detection plug-in, which improves the accuracy of the vulnerability detection plug-in generation as a whole.

[0089] The backend scheduling module 20 is further configured to call the plug-in list of the backend database according to the timing scanning signal, and send the plug-in list to the backend scanning engine 30 .

[0090] It should be noted that the scheduled scanning signal is a signal generated according to a preset time rule, which triggers the backend scheduling module to perform vulnerability scanning operations at a specific time interval or time point (such as 0:00 every day).

[0091] It is understandable that the plug-in list is a collection of plug-in information stored in the backend database, and may include a series of plug-in detailed information, such as the plug-in's identification, functional characteristics, etc.

[0092] The backend scanning engine 30 is used to call the vulnerability detection plug-in according to the plug-in list to perform vulnerability scanning on the backend business subsystem and generate vulnerability scanning results.

[0093] It should be noted that the vulnerability scanning results are obtained after the back-end scanning engine calls the vulnerability detection plug-in to scan the back-end business subsystem, which may include information such as whether there are vulnerabilities in the back-end business subsystem, the type, location and severity of the vulnerabilities.

[0094] It should be understood that the backend scanning engine is the execution unit of the vulnerability scanning system. Based on the plugin list sent by the backend scheduling module, it calls the corresponding vulnerability detection plugin to perform vulnerability scanning operations on the backend business subsystems. By running the vulnerability detection plugins in multiple threads, it can check various aspects of the business subsystem (such as network connectivity, system configuration, software vulnerabilities, etc.), finally generating vulnerability scan results and returning them to the backend scheduling module.

[0095] In its implementation, the backend scheduling module is activated based on a scheduled scan signal, retrieves a list of plugins from the backend database, and sends it to the backend scanning engine. Upon receiving the list, the backend scanning engine identifies the vulnerability detection plugin. It then uses the vulnerability detection plugin to perform a comprehensive vulnerability scan across all modules and interfaces of the backend business subsystem. Based on the detection results, it generates vulnerability scan results, including vulnerability location, type, and severity, and returns them to the backend scheduling module.

[0096] In another feasible implementation, the vulnerability scanning system described in this embodiment also includes: an alarm push module; the alarm push module is used to pull the vulnerability scanning results from the back-end database and determine whether there are event-type vulnerabilities in the vulnerability scanning results. The alarm push module is also used to detect the event-type vulnerability when there is an event-type vulnerability in the vulnerability scanning results, and determine the vulnerability location information and vulnerability repair suggestions of the event-type vulnerability; the alarm push module is also used to push the vulnerability location information and the vulnerability repair suggestions to the work person in charge for an alarm.

[0097] It is understandable that the alarm push module is responsible for sending alarms and push notifications to responsible persons for abnormal situations after the scan is completed, ensuring the timeliness of vulnerability discovery.

[0098] It should be noted that event-type vulnerabilities are vulnerabilities that require identity authentication, credential transfer, or unauthorized verification in the online banking environment.

[0099] It is understood that vulnerability location information refers to the specific location of the vulnerability in the backend business subsystem, such as the specific line number of a certain code segment or the specific parameter location of a configuration file. Vulnerability remediation suggestions are solutions or improvement measures for the discovered vulnerability.

[0100] In this implementation, the alarm push module specifically targets event-type vulnerabilities, and issues alarms and repair plan recommendations to relevant persons in charge as soon as the vulnerability is discovered, thereby promoting timely repair and closure of the vulnerability and preventing the recurrence of historical problems due to code changes or branch switching.

[0101] In the technical solution provided by this embodiment, plugins need to be uploaded during the initial phase of the process. Two methods are supported: direct upload of the code plugin and automatic conversion of a data packet into a code plugin before uploading. For code plugin conversion, the front-end web control module receives the basic plugin information entered by the user, encodes the information according to a pre-set format, adds metadata such as the module identifier, and forms a request data packet. The packet is then sent to the back-end scheduling module. The back-end scheduling module first parses the plugin information in the request data packet, generates the vulnerability detection plugin code according to predefined rules, configures and debugs the plugin functionality, and, after ensuring its validity, uploads and stores it in the back-end database. The back-end scheduling module then activates according to a scheduled scan signal, retrieves a list of plugins from the back-end database, and sends it to the back-end scanning engine. Upon receiving the plugin list, the back-end scanning engine identifies the vulnerability detection plugin from the list. The vulnerability detection plugin then performs a comprehensive vulnerability scan on all modules and interfaces of the back-end business subsystem. Based on the results, vulnerability scan results are generated, including vulnerability location, type, and severity, and returned to the back-end scheduling module. Since this embodiment targets event-type vulnerabilities in online banking business traffic, it directly sends a package to the back-end business system and uploads the vulnerability detection plug-in to the back-end database. For event-type vulnerabilities in online banking business traffic, it simplifies the vulnerability scanning process of the post-login interface and the transmission of credential-related parameters such as tokens, bypassing the complex identity authentication process, and continuously and automatically performing security monitoring, thereby improving the vulnerability detection effect.

[0102] Based on the above embodiment 1 of the present application, the second embodiment of the present application is proposed. In the second embodiment of the present application, the same or similar contents as those of the above embodiment 1 can be referred to the above introduction and will not be repeated hereafter.

[0103] The vulnerability scanning system described in this example also includes: a timing module; the timing module is used to generate a timing scanning signal at a preset time point and send the timing scanning signal to the back-end scheduling module 20; the back-end scheduling module 20 is also used to pull a plug-in list from the back-end database according to the timing scanning signal, and the plug-in list includes plug-in information of the vulnerability detection plug-in; the back-end scheduling module 20 is also used to send the plug-in information to the back-end scanning engine 30.

[0104] It should be noted that the preset time point is the time point set in the vulnerability scanning system to trigger the vulnerability scan. For example, you can set 0:00 or 2:00 in the morning every day as the preset time point. The timing module generates a timing scan signal at this time point to start the vulnerability scan.

[0105] It is understandable that the plug-in information is information containing a detailed description of each vulnerability detection plug-in in the plug-in list, and is the basis for the back-end scanning engine to perform vulnerability scanning.

[0106] In this embodiment, the timing module is used to trigger the scanning process according to the preset time point, which does not require frequent manual intervention, improves the regularity and timeliness of the scanning, and helps the system to discover vulnerabilities in a timely manner.

[0107] Furthermore, the back-end scanning engine 30 described in this example is also used to update the local plug-in library according to the plug-in information to obtain multiple local update plug-ins; the back-end scanning engine 30 is also used to enable multi-threaded synchronous execution of the multiple local update plug-ins; the local update plug-in is used to initiate an interface request to the back-end business subsystem according to user information, and perform a vulnerability scan on the back-end business subsystem according to a preset scanning strategy based on the interface request, and return the generated vulnerability scanning results to the back-end scanning engine 30; the back-end scanning engine 30 is also used to return the vulnerability scanning results to the back-end scheduling module 20; the back-end scheduling module 20 is also used to insert the vulnerability scanning results into the back-end database for storage.

[0108] It's important to note that the local plugin library is a collection of plugins stored locally within the backend scanning engine. It's used to detect vulnerabilities in backend business subsystems and serves as the foundation for vulnerability scanning. Locally updated plugins are generated by the backend scanning engine after updating the local plugin library based on plugin information. These plugins provide vulnerability scanning capabilities for backend business subsystems.

[0109] It is understood that the interface request is a request to perform a vulnerability scan on the backend business subsystem. Through the interface request, the local update plug-in can access the specific interface of the backend business subsystem, perform vulnerability detection according to the preset scanning strategy, and obtain execution operations.

[0110] The preset scanning strategy is a pre-set scanning rule for how to perform vulnerability scanning on the back-end business subsystem before the vulnerability scan is performed. For example, it can specify the scanning order, the key scanning areas, and the types of vulnerabilities to be detected.

[0111] In this embodiment, the vulnerability detection plug-in will be saved in the vulnerability detection plug-in after uploading. The timing module will initiate a timing scan signal at 0:00 every day by default. After receiving the timing scan signal, the back-end scheduling module will pull the remote plug-in and update the local plug-in, and enable multi-threading to execute several plug-ins synchronously. During the execution of the plug-in, it will carry relevant user information and directly initiate one or more interface requests to the back-end business subsystem, eliminating the need to pass credential fields such as token and Sid. After the scan is completed, the vulnerability scan results are generated and inserted into the back-end database after processing by the back-end scheduling module. In this way, a complete vulnerability scanning process is constructed, and the use of multi-threaded synchronous execution improves the scanning efficiency, makes the vulnerability scan more targeted, and helps to discover and repair vulnerabilities in a timely manner.

[0112] For example, to help understand the implementation process of the vulnerability scanning system obtained by combining the above-mentioned embodiment 1 and embodiment 2, please refer to Figure 2 , Figure 2 The overall call flow chart provided for the vulnerability scanning system of this application, specifically:

[0113] At the initial stage of the process, you need to add a new plug-in and upload it through the front-end web control module. There are two ways to upload plug-ins: one is to directly upload the code plug-in; the other is to automatically convert the request data packet into a code plug-in before uploading.

[0114] During plugin conversion, the backend scheduling module extracts header parameters such as the URL and Host from the request packet. Based on the routing table in the configuration file, it simulates the gateway's routing conversion operation and rewrites the URL to generate a direct access address for the backend business subsystem, facilitating access and requests within the plugin. It also uses user information as the request credential header to construct the backend business subsystem's access traffic packet. Finally, it automatically generates the plugin code for the request packet. After uploading, the newly uploaded plugin is stored in the backend database. The scheduling module initiates a scheduled scan signal at midnight daily by default. Upon receiving the scheduled scan signal, the backend scheduling module schedules tasks for the backend scanning engine. The backend scanning engine retrieves plugins from the backend database and updates them locally, enabling multithreading to execute multiple plugins simultaneously. During plugin execution, the plugin carries user information and directly initiates one or more interface requests to multiple backend subsystems, eliminating the need to pass credential fields such as tokens and SIDs. After the scan is complete, the backend scanning engine returns the attack results to the backend scheduling module, which processes and inserts the results into the backend database. This triggers an alert notification indicating an anomaly, contacting the relevant personnel for attention and vulnerability remediation.

[0115] Finally, the plug-in list and scan results can be queried through the front-end Web control module, and the results are returned to the user in the back-end database for viewing.

[0116] refer to Figure 3 ,The above vulnerability scanning system proposes a vulnerability scanning method, Figure 3 The flowchart of the vulnerability scanning method embodiment 1 of the present application is provided. The method is applied to a vulnerability scanning system, which includes a front-end Web control module, a back-end scheduling module, and a back-end scanning engine.

[0117] In this embodiment, the vulnerability scanning method includes steps S10 to S40:

[0118] Step S10: The front-end Web control module generates a request data packet according to the basic information of the plug-in input by the user, and sends the request data packet to the back-end scheduling module.

[0119] It should be noted that the basic information of the plug-in is the data content provided by the user for vulnerability detection, which may include the definition of a specific vulnerability type, plug-in name, plug-in description, writing date, etc.

[0120] It is understandable that the request data packet encapsulates various instructions and data content related to generating a vulnerability detection plug-in, which can be identified and processed by the back-end scheduling module, so that the back-end scheduling module can perform plug-in conversion based on this information.

[0121] It should be understood that the front-end web control module is the part of the vulnerability scanning system that directly interacts with users. It provides a web-based interface through which users can enter basic plug-in information. The front-end web control module primarily facilitates interaction with relevant web pages, including functions such as adding and uploading plug-ins, querying plug-in lists, querying scan progress, and querying scan results. This module also involves interaction with the back-end scheduling module.

[0122] In the implementation, plugins need to be uploaded at the initial stage of the process. Two methods are supported: directly uploading the code plugin or automatically converting the data package into a code plugin before uploading. For code plugin conversion, the front-end web control module receives the basic plugin information entered by the user, encodes it according to a pre-set format, adds metadata such as the module identifier, and forms a request data package. The package is then sent to the back-end scheduling module.

[0123] Step S20: The backend scheduling module converts the request data packet into a plug-in, generates a corresponding vulnerability detection plug-in, and uploads the vulnerability detection plug-in to the backend database.

[0124] It's important to note that vulnerability detection plugins are program components specifically designed to detect specific types of vulnerabilities, such as event-based vulnerabilities. Each vulnerability detection plugin includes basic plugin information, such as its name, description, channel and branch number, creation date, modification date, and author. It also includes the plugin's vulnerability detection code, which implements the basic vulnerability principle, HTTP packet sending process, and final vulnerability identification verification.

[0125] It's understood that the backend database serves as a storage system for vulnerability detection plug-ins generated by the backend scheduling module, forming a plug-in list. The backend database provides data support for the backend scheduling module and the backend scanning engine, streamlining the vulnerability scanning process on the post-login interface and the transmission of credential-related parameters such as tokens, ensuring the proper operation of the vulnerability scanning system.

[0126] It should be understood that the backend scheduling module performs the core scheduling and conversion tasks in the vulnerability scanning system. It can be built as a web application based on the Flask framework, serving as a bridge between the input of the front-end web control module and the back-end scanning engine. The back-end scheduling module not only handles the interaction and response of the front-end web control module's simple interface, but also receives relevant timing signals to initiate scanning tasks, triggering the scheduling and execution of the back-end scanning engine, ensuring that the entire vulnerability scanning system operates in an orderly manner according to pre-defined rules.

[0127] In the specific implementation, the back-end scheduling module can first parse the basic information of the plug-in in the request data packet, generate the vulnerability detection plug-in code according to predefined rules, perform function configuration and debugging, ensure the validity of the plug-in, and then upload it to the back-end database for storage.

[0128] In a feasible implementation, step S20 of this embodiment may include steps S21 to S24:

[0129] In step S21, the backend scheduling module performs routing conversion on the request data packet and generates an access address for the backend business subsystem.

[0130] It should be noted that the back-end business subsystem is the back-end part of the entire online banking business system. For example, it is specifically responsible for processing a certain type of business data, executing specific business logic, etc. Different subsystems work together to complete the business needs of the back-end of the entire online banking business system.

[0131] It is understandable that the access address is an identifier used to access the backend business subsystem. Through the access address, the corresponding business subsystem can be accurately found to perform operations such as data interaction.

[0132] Specifically, in a feasible implementation, step S21 of this embodiment may include the following steps: the back-end scheduling module extracts header parameters from the request data packet, the header parameters including a uniform resource locator and a Host header field; the back-end scheduling module simulates the routing conversion operation of the gateway through a routing table based on the header parameters, and determines the subsystem to be matched corresponding to the header parameters in the back-end business subsystem; the back-end scheduling module rewrites the header parameters to generate an access address of the subsystem to be matched.

[0133] It should be noted that the header parameters are important information related to the target address of the request contained in the request data packet, such as the Uniform Resource Locator (URL) and the Host header field.

[0134] The Uniform Resource Locator (URL) is used to identify the address of resources on the backend business subsystem and may include information such as protocol, domain name, path, etc. The Host header field is used to specify the host name to be accessed by the backend business subsystem.

[0135] It is understandable that the routing table is a data structure that stores routing information of various destinations in the backend business subsystem, defines how to forward incoming request packets to different backend business subsystems, and is used to assist the routing conversion operation of the simulation gateway.

[0136] It should be understood that the subsystem to be matched is a subsystem that is determined in the backend business subsystem based on the header parameters to match and interact with the request data packet.

[0137] Specifically, when a request packet is received, the URL, Host, and other header parameters in the request are checked, and then a matching rule is searched in the routing table. Based on the matching result, the backend business subsystem to which the request packet is forwarded is determined.

[0138] In this embodiment, by simulating the routing conversion operation of the gateway, the subsystem to be matched can be accurately determined, and then the header parameters are rewritten to generate the correct access address that the back-end subsystem can directly accept, thereby ensuring that the request can accurately reach the back-end business subsystem.

[0139] Step S22: The backend scheduling module extracts the user information from the request packet and uses this information as a credential header to construct an access traffic packet corresponding to the backend business subsystem. Step S23: The backend scheduling module performs plugin conversion based on the access address and the access traffic packet, generating a vulnerability detection plugin corresponding to the request packet. Step S24: The backend scheduling module uploads the vulnerability detection plugin to the backend database for storage.

[0140] It is understandable that the credential header is the part used to place user information when constructing the access traffic packet. It is the identification part of the access traffic packet. Through this part, the back-end business subsystem can verify the visitor's identity and other related information.

[0141] The access traffic packet is a data packet containing user information (as a credential header) and is used to initiate an access request to the back-end business subsystem. It is the data carrier for interacting with the back-end business subsystem.

[0142] In this embodiment, when performing plug-in conversion, the back-end scheduling module extracts the header parameters (such as URL, Host and other parameters) in the request data packet, and then simulates the routing conversion operation of the gateway based on the routing table in the configuration file, rewrites the URL, and generates a direct access address for the back-end business subsystem, which is convenient for access and request in the plug-in. Then, the user information is used as the credential header of the request data packet to construct the access traffic packet of the back-end business subsystem. Finally, the plug-in code of the relevant request data packet is automatically generated based on the access address and the access traffic packet to generate a vulnerability detection plug-in. By directly sending packets to the back-end business system, the security vulnerabilities of the business can be automatically scanned and monitored, and the online banking channel, user number, enterprise number and other information can be automatically identified. The vulnerability detection script code is generated according to the vulnerability type to form a vulnerability detection plug-in, which improves the accuracy of the vulnerability detection plug-in generation as a whole.

[0143] Step S30: the backend scheduling module calls the plug-in list of the backend database according to the timing scanning signal, and sends the plug-in list to the backend scanning engine.

[0144] It should be noted that the scheduled scanning signal is a signal generated according to a preset time rule, which triggers the backend scheduling module to perform vulnerability scanning operations at a specific time interval or time point (such as 0:00 every day).

[0145] It is understandable that the plug-in list is a collection of plug-in information stored in the backend database, and may include a series of plug-in detailed information, such as the plug-in's identification, functional characteristics, etc.

[0146] Step S40: the backend scanning engine calls the vulnerability detection plug-in according to the plug-in list to perform vulnerability scanning on the backend business subsystem and generate vulnerability scanning results.

[0147] It should be noted that the vulnerability scanning results are obtained after the back-end scanning engine calls the vulnerability detection plug-in to scan the back-end business subsystem, which may include information such as whether there are vulnerabilities in the back-end business subsystem, the type, location and severity of the vulnerabilities.

[0148] It should be understood that the backend scanning engine is the execution unit of the vulnerability scanning system. Based on the plugin list sent by the backend scheduling module, it calls the corresponding vulnerability detection plugin to perform vulnerability scanning operations on the backend business subsystems. By running the vulnerability detection plugins in multiple threads, it can check various aspects of the business subsystem (such as network connectivity, system configuration, software vulnerabilities, etc.), finally generating vulnerability scan results and returning them to the backend scheduling module.

[0149] In its implementation, the backend scheduling module is activated based on a scheduled scan signal, retrieves a list of plugins from the backend database, and sends it to the backend scanning engine. Upon receiving the list, the backend scanning engine identifies the vulnerability detection plugin. It then uses the vulnerability detection plugin to perform a comprehensive vulnerability scan across all modules and interfaces of the backend business subsystem. Based on the detection results, it generates vulnerability scan results, including vulnerability location, type, and severity, and returns them to the backend scheduling module.

[0150] Other embodiments or specific implementation methods of the vulnerability scanning method of the present application can refer to the above-mentioned system embodiments and will not be repeated here.

[0151] The vulnerability scanning method provided in this application, applied to the vulnerability scanning system in the above-mentioned embodiments, can address the technical problem of poor vulnerability detection results caused by the complexity of obtaining permissions during the detection process of event-based vulnerabilities in online banking services. Compared with the prior art, the beneficial effects of the vulnerability scanning method provided in this application are the same as those of the vulnerability scanning system provided in the above-mentioned embodiments, and the other technical features of the vulnerability scanning method are the same as those disclosed in the above-mentioned embodiments, and are not further described here.

[0152] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the vulnerability scanning system and method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0153] The above description is only part of the embodiments of the present application and does not limit the scope of protection of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the scope of protection of the present application.

Claims

1. A vulnerability scanning system, characterized in that: The system includes: a front-end Web control module, a back-end scheduling module and a back-end scanning engine; The front-end Web control module is used to generate a request data packet according to the basic information of the plug-in input by the user, and send the request data packet to the back-end scheduling module; The backend scheduling module is used to convert the request data packet into a plug-in, generate a corresponding vulnerability detection plug-in, and upload the vulnerability detection plug-in to the backend database; The backend scheduling module is further configured to call the plug-in list of the backend database according to the timing scanning signal, and send the plug-in list to the backend scanning engine; The backend scanning engine is used to call the vulnerability detection plug-in according to the plug-in list to perform vulnerability scanning on the backend business subsystem and generate vulnerability scanning results.

2. The system according to claim 1, wherein The backend scheduling module is further configured to perform routing conversion on the request data packet and generate an access address for the backend business subsystem; The backend scheduling module is further configured to extract user information from the request data packet and use the user information as a credential header to construct an access traffic packet corresponding to the backend business subsystem; The backend scheduling module is further configured to perform plug-in conversion according to the access address and the access traffic packet to generate a vulnerability detection plug-in corresponding to the request data packet; The back-end scheduling module is also used to upload the vulnerability detection plug-in to the back-end database for storage.

3. The system according to claim 2, wherein: The backend scheduling module is further configured to extract header parameters from the request data packet, wherein the header parameters include a uniform resource locator and a Host header field; The backend scheduling module is further configured to simulate the routing conversion operation of the gateway through the routing table based on the header parameters, and determine the subsystem to be matched corresponding to the header parameters in the backend business subsystem; The backend scheduling module is further configured to rewrite the header parameters to generate an access address of the subsystem to be aligned.

4. The system according to claim 1, wherein: The front-end Web control module is further configured to, upon receiving a user's request to add a new plug-in, display a plug-in form page to the user, so that the user can fill in basic plug-in information and user information based on the plug-in form page; The front-end Web control module is further used to verify the integrity of the basic information of the plug-in and generate a verification result; The front-end Web control module is further configured to encapsulate the plug-in basic information and the user information to obtain a request data packet when the verification result is integrity passed; The front-end Web control module is further configured to send the request data packet to the back-end scheduling module.

5. The system according to claim 1, wherein: The vulnerability scanning system further includes: an alarm push module; The alarm push module is used to pull vulnerability scan results from the backend database and determine whether there is an event-type vulnerability in the vulnerability scan results. The alarm push module is further configured to detect event-type vulnerabilities when there are event-type vulnerabilities in the vulnerability scan results, and determine vulnerability location information and vulnerability repair suggestions for the event-type vulnerabilities; The alarm push module is also used to push the vulnerability location information and the vulnerability repair suggestion to the work person in charge for alarm.

6. The system according to any one of claims 1 to 5, characterized in that The vulnerability scanning system further includes: a timing module; The timing module is used to generate a timing scanning signal at a preset time point and send the timing scanning signal to the back-end scheduling module; The backend scheduling module is further configured to pull a plug-in list from the backend database according to the timing scanning signal, wherein the plug-in list includes plug-in information of the vulnerability detection plug-in; The backend scheduling module is further configured to send the plug-in information to the backend scanning engine.

7. The system according to claim 6, wherein: The backend scanning engine is further configured to update the local plug-in library according to the plug-in information to obtain a plurality of local updated plug-ins; The backend scanning engine is further configured to enable multi-threaded synchronous execution of the multiple local update plug-ins; The local update plug-in is used to initiate an interface request to the backend business subsystem according to user information, perform a vulnerability scan on the backend business subsystem according to a preset scanning strategy based on the interface request, and transmit the generated vulnerability scan results back to the backend scanning engine; The backend scanning engine is further configured to return the vulnerability scanning result to the backend scheduling module; The back-end scheduling module is further configured to insert the vulnerability scanning result into the back-end database for storage.

8. A vulnerability scanning method, characterized in that: The method is applied to a vulnerability scanning system, which includes a front-end Web control module, a back-end scheduling module, and a back-end scanning engine; the method includes: The front-end Web control module generates a request data packet according to the basic information of the plug-in input by the user, and sends the request data packet to the back-end scheduling module; The backend scheduling module converts the request data packet into a plug-in, generates a corresponding vulnerability detection plug-in, and uploads the vulnerability detection plug-in to the backend database; The backend scheduling module calls the plug-in list of the backend database according to the timing scanning signal, and sends the plug-in list to the backend scanning engine; The backend scanning engine calls the vulnerability detection plug-in according to the plug-in list to perform vulnerability scanning on the backend business subsystem and generate vulnerability scanning results.

9. The method according to claim 8, wherein The backend scheduling module converts the request data packet into a plug-in, generates a corresponding vulnerability detection plug-in, and uploads the vulnerability detection plug-in to the backend database, including: The back-end scheduling module performs routing conversion on the request data packet and generates an access address of the back-end business subsystem; The backend scheduling module extracts the user information of the request data packet and uses the user information as a credential header to construct an access traffic packet corresponding to the backend business subsystem; The backend scheduling module performs plug-in conversion according to the access address and the access traffic packet to generate a vulnerability detection plug-in corresponding to the request data packet; The back-end scheduling module uploads the vulnerability detection plug-in to the back-end database for storage.

10. The method according to claim 9, wherein The backend scheduling module performs routing conversion on the request data packet to generate an access address of the backend business subsystem, including: The backend scheduling module extracts header parameters from the request data packet, wherein the header parameters include a uniform resource locator and a Host header field; The backend scheduling module simulates the routing conversion operation of the gateway through the routing table based on the header parameters, and determines the subsystem to be matched corresponding to the header parameters in the backend business subsystem; The backend scheduling module rewrites the header parameters to generate an access address of the subsystem to be aligned.

Images