Vulnerability processing method, device, equipment, storage medium and program product

Abstract

This application provides a vulnerability handling method, apparatus, device, storage medium, and program product, relating to the fintech field or other related fields. The method includes: responding to an original access request from a target service, obtaining the request content from the original access request; detecting whether a vulnerability to be patched exists in the request content; if a vulnerability to be patched exists, calling the target patching plugin corresponding to the vulnerability from among multiple vulnerability patching plugins, and using the target patching plugin to patch the request content to obtain a patched access request; and sending the patched access request to the target service so that the target service executes the patched access request. The method of this application can directly identify and trigger vulnerability patching, shorten the vulnerability patching window, and achieve zero-downtime maintenance.

Description

Technical Field

[0001] This application relates to the field of financial technology or other related fields, and in particular to a vulnerability handling method, apparatus, device, storage medium and program product. Background Technology

[0002] High-performance in-memory databases are widely used in banking operations for various critical business scenarios, such as transaction caching, session management, and real-time risk control. Therefore, ensuring their stability and security is paramount. Any vulnerabilities in database services, such as unauthorized access or buffer overflows, can be exploited by malicious attackers. Consequently, timely and effective vulnerability patching is crucial for the target database services supporting banking operations to guarantee the robust operation of the financial system.

[0003] Currently, traditional technical methods for patching vulnerabilities in services such as databases mainly rely on global upgrades and manual intervention: First, a global database version upgrade is performed, which means replacing the old version running online with the new version file that has patched the vulnerabilities; Second, when an immediate upgrade is not possible, manual monitoring and patching by the security team is relied upon, which means that after vulnerabilities are discovered through security scanning tools or manual inspections, operations and maintenance personnel log into each server and harden it by modifying configuration files (such as renaming or disabling high-risk commands) or deploying network firewall rules.

[0004] However, the above-mentioned remediation methods have the following problems: global upgrades usually require restarting the service, which will cause business interruption, and version compatibility testing is complex and costly to implement; manual monitoring and manual repair are inefficient and slow to respond, which makes the vulnerability remain exploitable for a long time. Summary of the Invention

[0005] This application provides a vulnerability handling method, apparatus, device, storage medium, and program product to solve the technical problem that traditional vulnerability repair methods rely on global upgrades or manual monitoring and repair, resulting in a long window period from vulnerability discovery to repair.

[0006] Firstly, this application provides a vulnerability handling method, the method comprising:

[0007] In response to the original access request to the target service, obtain the request content in the original access request;

[0008] Check if there are any vulnerabilities to be patched in the requested content;

[0009] In the case of the vulnerability to be repaired, the target repair plugin corresponding to the vulnerability to be repaired is called among multiple vulnerability repair plugins, and the request content is repaired by the target repair plugin to obtain the repaired access request.

[0010] The repaired access request is sent to the target service so that the target service executes the repaired access request.

[0011] Secondly, this application provides a vulnerability management system, the system comprising:

[0012] The user management module is used to obtain the authentication information input by the user and determine whether the user has plugin management permissions based on the authentication information.

[0013] If the user has plugin management permissions, then the plugin management instruction input by the user is obtained. The plugin management instruction is used to instruct the vulnerability repair plugin in the preset plugin library to perform a target update operation.

[0014] The vulnerability management service module is used to perform the target update operation on the vulnerability patching plugin in response to the plugin management command.

[0015] Thirdly, this application provides a vulnerability repair device, the device comprising:

[0016] The interception module is used to, in response to the original access request of the target service, obtain the request content in the original access request;

[0017] The detection module is used to detect whether there are any vulnerabilities to be fixed in the requested content;

[0018] The repair module is used to call the target repair plugin corresponding to the vulnerability to be repaired among multiple vulnerability repair plugins when the vulnerability to be repaired exists, and to repair the request content through the target repair plugin to obtain a repaired access request.

[0019] The repaired access request is sent to the target service so that the target service executes the repaired access request.

[0020] Fourthly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0021] The memory stores computer-executed instructions;

[0022] The processor executes computer execution instructions stored in the memory to implement the method as described in the first aspect.

[0023] Fifthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in the first aspect.

[0024] In a sixth aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect.

[0025] The vulnerability handling methods, apparatus, devices, storage media, and program products provided in this application have the following technical effects:

[0026] 1. This method immediately retrieves the request content and checks for vulnerabilities when an access request reaches the target service (such as a database service). If a vulnerability (such as a high-risk command) is found, a plugin is invoked to fix it in real time. Compared to traditional remediation methods that require waiting for global upgrades or manual intervention, this method embeds vulnerability handling into the request processing chain. When an access request contains a vulnerability, the method's checking steps can directly identify and trigger the remediation of the vulnerability, shortening the vulnerability remediation window.

[0027] 2. Traditional remediation methods often require restarting the target service to fix vulnerabilities through global upgrades, resulting in business interruption. This method fixes vulnerabilities through plugins, eliminating the need to restart the target service and achieving zero-downtime maintenance. Attached Figure Description

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

[0029] Figure 1 Flowchart of the vulnerability handling method provided in the embodiments of this application Figure 1 ;

[0030] Figure 2 Flowchart of the vulnerability handling method provided in the embodiments of this application Figure 2 ;

[0031] Figure 3 A schematic diagram of a vulnerability management system provided in an embodiment of this application;

[0032] Figure 4 This is a schematic diagram of the vulnerability repair device architecture provided in the embodiments of this application;

[0033] Figure 5 This is a schematic diagram of the electronic device structure provided in an embodiment of this application.

[0034] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0035] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0036] It should be noted that the vulnerability handling methods, devices, equipment, storage media, and program products provided in this application can be used in the fintech field, or in any field other than fintech. The application fields of the vulnerability handling methods, devices, equipment, storage media, and program products in this application are not limited.

[0037] To address the problem that traditional vulnerability remediation methods rely on global upgrades or manual monitoring and repair, resulting in a long window period from vulnerability discovery to remediation, this application's technical concept is as follows: When an access request to the target service is received, the request content is obtained, and then the request content is checked for vulnerabilities. If a vulnerability exists in the request content, the corresponding vulnerability remediation plugin is invoked to repair the vulnerability in the request content, and the access request with the repaired vulnerability is sent to the target service. In other words, access requests sent to the target service are intercepted in real time, and if a vulnerability is detected in the access request, the corresponding repair plugin is invoked to repair it, thereby overcoming the problem of long vulnerability remediation window periods in existing technologies.

[0038] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0039] Example 1

[0040] Figure 1 Flowchart of the vulnerability handling method provided in the embodiments of this application Figure 1 This method can be applied to servers, such as... Figure 1 As shown, the method includes:

[0041] S101. In response to the original access request of the target service, obtain the request content in the original access request;

[0042] In this step, the server can run as a proxy or gateway for the target service, which could be, for example, a database service or an API service.

[0043] The server listens on the ports exposed by the target service at the network layer. Once it receives a raw access request from a client to access the target service, the server can parse and reassemble the raw request according to the communication protocol used by the target service (such as HTTP), extracting the original, unmodified request content. This request content can specifically include command strings or API endpoints, a complete list of parameters, request headers, authentication tokens, and message bodies, among other raw data. The server can then encapsulate the extracted request content into an internal request object and attach a unique tracking ID for subsequent processing.

[0044] S102. Check if there are any vulnerabilities to be patched in the request content;

[0045] In this step, the server can first perform deep semantic parsing on the request content. For example, for a database query request, the result of semantic parsing can be the specific operation command (such as SELECT, UPDATE), the target data table or key of the operation, and the conditions and parameter values ​​attached to the operation.

[0046] Next, based on the results of semantic parsing, the server can construct a behavior graph. The purpose of this behavior graph is to infer a series of system state changes that may be triggered if the original access request is executed by the target service, including but not limited to: data reading range, data modification range, new resource creation, system call chain, and network access behavior.

[0047] After acquiring the behavioral graph, the server can determine whether the request content contains vulnerabilities that need to be patched based on a pre-defined set of security policy rules. Specifically, the rules in the security policy rule set determine the presence of vulnerabilities based on behavioral patterns. For example, one rule in the security policy rule set might be: "Prohibit any operation that attempts to traverse all keys in the entire database," and another rule might be: "Access to password fields must be accompanied by strong encryption." The server compares the constructed behavioral graph with the rules in the security policy rule set. If any node or path in the behavioral graph violates any rule in the security policy rule set, the server determines that the request content contains a vulnerability that needs to be patched. At this point, the server can generate a vulnerability report, which specifies the violated policy rule, the potential harm, and the severity level of the vulnerability.

[0048] If a vulnerability remains to be patched, execute S103;

[0049] In the absence of any vulnerabilities to be patched, the original access request is sent to the target service so that the target service executes the original access request.

[0050] S103. Call the target repair plugin corresponding to the vulnerability to be repaired among multiple vulnerability repair plugins, and repair the request content through the target repair plugin to obtain the repaired access request.

[0051] Specifically, the server can be configured with a plugin registry. Each vulnerability remediation plugin stored in this registry is identified by the type of policy rule violation it can fix (i.e., the rule in the security policy rule set). Based on the identification information of the policy rule violated in the vulnerability report of the request content generated in S102, the server can query the plugin registry to find one or more vulnerability remediation plugins that can handle this type of vulnerability and identify them as the target remediation plugin.

[0052] The server invokes the target repair plugin and can perform repair processing within an isolated repair sandbox that simulates the target service environment. It should be noted that this repair sandbox provides a simulated interface to the target service API and accepts the original request content as input.

[0053] Within the repair sandbox, repair processes can be implemented in various ways. For example, a plugin can rewrite an insecure global scan request as a request with pagination parameters and security restrictions; a plugin can inject encryption logic for a request lacking encryption. Ultimately, the target repair plugin generates one or more modified access requests within the repair sandbox.

[0054] During the verification phase, the remediation sandbox can simulate the execution of modified access requests generated by the target remediation plugin and reapply the vulnerability checking methods in S102 to verify whether the modified access requests still violate the rules in the security policy rule set. The verification phase can be executed iteratively multiple times until a "clean" request that no longer triggers any security policy rules is generated, i.e., the remediated access request.

[0055] S104. Send the repaired access request to the target service so that the target service can execute the repaired access request.

[0056] In this step, the server reserializes the patched access request into the original protocol format (such as HTTP or the database's corresponding serialization protocol) that the target service can recognize. Then, the server sends the patched access request as a network endpoint to the target service. After receiving and executing the patched access request, the target service returns the execution result. The server finally returns this execution result to the original client, thus completing the vulnerability detection and patching without the user's awareness.

[0057] Figure 1 The method shown has the following technical effects:

[0058] 1. This method immediately retrieves the request content and checks for vulnerabilities when an access request reaches the target service (such as a database service). If a vulnerability (such as a high-risk command) is found, a plugin is invoked to fix it in real time. Compared to traditional remediation methods that require waiting for global upgrades or manual intervention, this method embeds vulnerability handling into the request processing chain. When an access request contains a vulnerability, the method's checking steps can directly identify and trigger the remediation of the vulnerability, shortening the vulnerability remediation window.

[0059] 2. Traditional remediation methods often require restarting the target service to fix vulnerabilities through global upgrades, resulting in business interruption. This method fixes vulnerabilities through plugins, eliminating the need to restart the target service and achieving zero-downtime maintenance.

[0060] Figure 2 Flowchart of the vulnerability handling method provided in the embodiments of this application Figure 2 This method can be applied to a plugin management module, which can be implemented on a server-side basis. For example... Figure 3 As shown, the method includes:

[0061] S201. Obtain the version information of the target service;

[0062] In this step, the target service can be, for example, a database service instance that needs to be managed. Specifically, the process of obtaining its version information is as follows:

[0063] When the database server starts, its integrated plugin management module is loaded first. This module, as a database module, runs in the same process space as the main database service program. After loading, the plugin management module can call internal interfaces provided by the database service to obtain the detailed version number of the current database service as version information. This version number is a formatted string, such as "6.0.16" or "7.0.12," identifying the current database service's functionality and the scope of potential security vulnerabilities. The version information obtained by the plugin management module is stored in memory.

[0064] S202. Send the version information to the preset plugin library and obtain the vulnerability repair plugin corresponding to the version information returned by the preset plugin library.

[0065] In this step, the plugin management module can encapsulate the version information obtained in step S201 into a data packet and send it to the vulnerability management system through a secure network connection such as HTTPS protocol. The vulnerability management system is the management terminal of the preset plugin library. The vulnerability management system uses the version information to perform a query operation, queries the vulnerability repair plugins corresponding to the current version number of the database service, and transmits the corresponding vulnerability repair plugins from the preset plugin library to the database server through the network.

[0066] By utilizing the version information of the target service, the vulnerability patching plugin corresponding to that version can be obtained, making the obtained vulnerability patching plugin compatible with the current version of the target service.

[0067] Optionally, the version information is sent to a preset plugin library to obtain the vulnerability patching plugins corresponding to the version information returned by the preset plugin library, including:

[0068] Step 1: Obtain the identification information of the plugins installed on the target service;

[0069] Specifically, on the database server side, the plugin management module can first collect the status information of locally installed plugins. This status information is typically stored in the local storage of the local database vulnerability plugins, for example, in the form of a manifest file (such as JSON or XML format). This manifest file records the identification information of all successfully loaded vulnerability patching plugins. This identification information includes, but is not limited to: the plugin name, the CVE number of the vulnerability patched by the plugin (a standardized number used to uniquely identify a specific security vulnerability), and the plugin version number. The plugin management module obtains the exact plugin installation status of the current database service by reading and parsing this manifest file.

[0070] Step 2: Send the version information and identification information to the preset plugin library so that the preset plugin library can determine the vulnerability repair plugin that is different from the installed plugin and corresponds to the version information based on the version information and identification information.

[0071] Subsequently, the plugin management module encapsulates the identification information and the version information (database service version number) obtained in S201 into a structured data request message, and sends the data request message to the vulnerability management system through a secure network channel such as HTTPS, so that the vulnerability management system can determine the version of the database service and the existing plugins of the database service.

[0072] After receiving a data request message, the vulnerability management system can first query the vulnerability list in the vulnerability management database. Based on the received database service version information, it can match the version range field of the vulnerability management database to filter out all vulnerability fix plugin records applicable to the specific database service version. These records include, but are not limited to, complete information such as the name, CVE number, and plugin version of the candidate plugin.

[0073] Next, the vulnerability management system compares the filtering results from the previous step with the identification information (list of installed plugins) reported by the database service. From all vulnerability patching plugins applicable to the current version of the database service, plugins with the same version number that are already installed on the database service are excluded. Specifically, the vulnerability management system can, for example, compare the vulnerability patching plugin name and plugin version number one by one, retaining only those plugins that fall into the following categories:

[0074] New plugin: Applicable to this version of the database service, but no new version of the plugin is yet installed on the server.

[0075] Update plugin: Applicable to this database version, and the server already has an older version installed, but the platform provides a plugin with the same name and updated version number.

[0076] Finally, the vulnerability management system generates a list of vulnerability patching plugins that need to be distributed or updated.

[0077] Step 3: Obtain the vulnerability repair plugins returned by the preset plugin library.

[0078] The vulnerability management system retrieves the corresponding plugin files from a pre-defined plugin library based on the identified list of vulnerability remediation plugins. These plugin files can be, for example, compiled dynamic link library files. The system then sends these plugin files back to the database server over the network. Upon receiving these plugin files, the database server saves them to local storage and the plugin management module dynamically loads them into memory, completing the update or installation of the vulnerability remediation plugins.

[0079] The above method for obtaining vulnerability patching plugins through version information and identification information has the following technical effects:

[0080] By sending identification information to a pre-defined plugin library, the vulnerability patching plugin that differs from the already installed plugin and corresponds to its version information can be identified. This avoids repeatedly distributing the latest version of the plugin that is already available on the target service, reducing the amount of data transmitted over the network, lowering bandwidth consumption, and reducing server-side computational overhead (such as the overhead of downloading, verifying, and loading plugins). Simultaneously, it avoids conflicts or errors that might result from repeatedly loading the same version of the plugin.

[0081] S203. In response to the original access request to the target service, obtain the request content in the original access request;

[0082] When a database client (e.g., an application) initiates a data operation request (e.g., the SET command) to the target database service, this data operation request is the original access request. The loaded plugin management module intercepts this original access request and identifies the complete content of the request, including but not limited to command verbs (e.g., KEYS, SET) and command parameters (e.g., *).

[0083] S204. Among the feature information of multiple candidate vulnerabilities, determine whether there is target feature information that matches the request content;

[0084] The plugin management module can configure a feature information database for candidate vulnerabilities. This database comes from all loaded vulnerability repair plugins. Each vulnerability repair plugin defines the feature information of the vulnerabilities it can repair. These features can exist in the form of rules, for example: for unauthorized access vulnerabilities, the feature is "the request does not carry authentication information"; for command injection vulnerabilities, the feature is "the command string contains a specific dangerous pattern or character sequence".

[0085] The plugin management module compares the request content obtained in step S203 with all candidate feature information in the feature information database. The comparison process can employ methods such as string matching, regular expression engines, or syntax analysis algorithms. If the request content matches the feature rules of one or more vulnerabilities, it is determined that target feature information exists, meaning that the original access request may be attempting to exploit a known vulnerability.

[0086] By utilizing candidate vulnerability signature information and matching request content, the efficiency of vulnerability detection can be improved and the response time of access requests can be shortened.

[0087] Because the feature database of candidate vulnerabilities can contain complex exploitation patterns, such as specific command sequences, parameter combinations, or abnormal access frequencies, comparison based on the feature database of candidate vulnerabilities can accurately identify complex and varied attack methods, reducing the probability of false positives and false negatives.

[0088] Optionally, among the feature information of multiple candidate vulnerabilities, determine whether there is target feature information that matches the request content, including:

[0089] Step 1: Extract the command name and command parameters from the request content;

[0090] In this step, the plugin management module can input the original access request into the built-in parser, which parses the original access request character by character, identifying the start and end of the command and the boundaries of each parameter.

[0091] After parsing, the request content of the access request is converted into a data representation of an abstract syntax tree or parameter list to extract the command name and command parameters.

[0092] Step 2: Match the command name and command parameters with the feature information according to preset rules to determine whether there is target feature information that matches the command name and command parameters.

[0093] Specifically, each vulnerability remediation plugin can be associated with one or more sets of predefined matching rules, which allow vulnerability characteristics to be described using structured data formats. For example, matching rules could be:

[0094] Command name constraint: Specifies the commands that must be matched;

[0095] Parameter existence check: Checks whether a parameter exists at a specific location;

[0096] Logical judgment of parameter values: Perform logical operations on the values ​​of parameters;

[0097] Combining conditions: Using logical operators (AND, OR, NOT) to combine multiple simple conditions to form complex matching logic.

[0098] The plugin management module uses the command name and command parameter list obtained in step one to traverse the matching rules corresponding to all loaded plugins. It compares these rules with the command name and command parameter list. If all conditions of a certain rule or a group of rules are satisfied by the command name and command parameter list, it is determined that there is target feature information that matches the request content, that is, the vulnerability to be fixed is discovered.

[0099] By utilizing command names and parameters to identify target characteristics, vulnerability identification accuracy can be enhanced, reducing the risk of missed detections. Matching is performed using pre-defined rules; when a new vulnerability emerges, operations personnel only need to define and deploy new matching rules without modifying the code. Furthermore, because pre-defined rules can support complex logical combinations, they can describe complex attack scenarios.

[0100] Optionally, the command name and command parameters are matched with feature information according to preset rules to determine whether there is target feature information that matches the command name and command parameters, including:

[0101] Check if there is any feature information matching the command name. If so, identify the feature information matching the command name as the target feature information, and / or...

[0102] Check if there is any feature information that matches the pattern of the command parameters. If so, identify the feature information that matches the pattern of the command parameters as the target feature information.

[0103] Specifically, the preset rules are the matching logic recorded in the feature information database of candidate vulnerabilities, and are divided into the following two categories:

[0104] Precise matching rules based on command names: For database commands that themselves pose a security risk, the feature information is directly defined as the specific command name. For example, for high-risk commands such as KEYS and FLUSHALL that may cause service blockage, the feature information is the command string itself.

[0105] Command parameter pattern-based pattern matching rules: These rules determine whether a command's safety depends on the pattern of its command parameters. Feature information is defined as pattern rules to describe dangerous parameter characteristics, for example:

[0106] Wildcard pattern: For example, for the KEYS command, the characteristic of dangerous parameters may be defined as the pattern "*", which means that any parameter may cause service performance problems due to traversing all keys.

[0107] Regular expression patterns: For more complex injection attacks, the feature information can be regular expressions, used to match whether the parameters contain specific malicious code sequences or abnormal structures.

[0108] When the original access request sent by the database client is intercepted by the plugin management module, the module parses it to obtain the command name (such as SET, GET, KEYS) and command parameters (such as user:1000:name,*,"malicious\0script"). Then, the plugin management module matches the following two paths:

[0109] Command name exact match search path: The plugin management module uses the parsed command name as the key to search in the feature information database. If a feature information that exactly matches the command name exists, that feature information is identified as the first target feature information. Searching for target feature information by command name matching is relatively fast because the matching process is a direct search based on a hash table or similar data structure, resulting in low time complexity.

[0110] Command parameter pattern matching search path: The plugin management module detects command parameters and compares them with all parameter pattern rules in the feature information database. If the command parameter matches a certain preset pattern rule (for example, the parameter of the KEYS command is *, which matches the wildcard pattern rule), then the feature information corresponding to this pattern rule is determined as the target feature information.

[0111] The plugin management module can perform both of the above matching paths simultaneously, or execute any one of the matching paths individually.

[0112] The above-mentioned method for determining target feature information divides the matching of feature information into two paths: command name matching and parameter pattern matching. Accurate command name matching can avoid misjudging safe commands as dangerous operations simply because command parameters are similar, thus reducing the risk of false alarms. The command parameter pattern matching mechanism can effectively identify advanced attack methods (such as command injection and buffer overflow attacks) with legitimate command names but malicious parameters, solving the problem of insufficient coverage of single command name matching and improving the vulnerability detection rate.

[0113] If no target feature information is available, the original access request will be sent to the target service so that the target service can execute the original access request.

[0114] If target feature information exists, execute S205 to determine if there is a vulnerability to be fixed in the request content. In the preset mapping table, find the target repair plugin corresponding to the target feature information. The preset mapping table is used to indicate the correspondence between feature information and vulnerability repair plugin.

[0115] After confirming the existence of a vulnerability to be patched, the plugin management module can configure a preset mapping table to establish a correspondence between vulnerability feature information and vulnerability patching plugins. For example, the feature "command is KEYS and parameter is *" can be mapped to the patching plugin cve-2023-12345-fix.so. The plugin management module uses the target feature information determined in step S204 as the key to search the preset mapping table and locate the target patching plugin specifically designed to patch this particular vulnerability. This plugin has already been downloaded and loaded into memory in step S202.

[0116] S206. Obtain the call address of the target repair plugin from the preset mapping table, and call the target repair plugin to repair the requested content through the call address to obtain the repaired access request.

[0117] Specifically, the preset mapping table not only records the identity of the vulnerability patching plugin, but may also contain the call address of the plugin's entry function. Based on this call address, the plugin management module invokes the target patching plugin's specific processing function. This function performs patching processing on the original access request content. The patching strategies include, but are not limited to:

[0118] Execution Denied: Directly interrupts the request and returns an error message to the client; suitable for high-risk vulnerability exploitation attempts.

[0119] Rewrite command: Modify dangerous parameters in the request and replace them with safe equivalent parameters;

[0120] Injected authentication: Automatically adds the necessary authentication tokens for unauthorized requests;

[0121] Log recording: Records details of security incidents for auditing and analysis.

[0122] After the repair process is completed, a secure post-repair access request is obtained.

[0123] Steps S205-S206 have the following technical effects:

[0124] Step S205 allows for precise matching of the target repair plugin with the specific vulnerability to be repaired by searching for the target repair plugin corresponding to the target feature information in a preset mapping table. Furthermore, the mapping table can be used to quickly determine the target repair plugin.

[0125] Step S206 directly calls the call address of the target patching plugin recorded in the preset mapping table. This direct call mechanism based on memory address eliminates the complex query process, allows for immediate vulnerability patching, and has minimal impact on the overall performance of the target service in processing requests.

[0126] S207. Send the repaired access request to the target service so that the target service can execute the repaired access request.

[0127] This step can be referred to in the aforementioned embodiments, and will not be repeated here.

[0128] Figure 3 This is a schematic diagram of a vulnerability management system provided in an embodiment of this application, such as... Figure 4 As shown, the system 30 includes:

[0129] User management module 301 is used to obtain the authentication information entered by the user and to determine whether the user has plugin management permissions based on the authentication information.

[0130] If the user has plugin management permissions, the plugin management command input by the user is obtained. The plugin management command is used to instruct the vulnerability repair plugin in the preset plugin library to perform target update operation.

[0131] The vulnerability management service module 302 is used to perform target update operations on vulnerability patching plugins in response to plugin management instructions.

[0132] Specifically, the core functions of the user management module 30 include identity verification and permission authentication:

[0133] When a user (such as an administrator) tries the system or uses a tool (such as a command-line tool), the user management module 301 can obtain the authentication information entered by the user through its provided graphical interface or command-line interface. The authentication information may include, for example, a username and password.

[0134] The transmission of authentication information can be encrypted using the HTTPS / TLS 1.3 protocol. After receiving the authentication information, the user management module 301 enters the authentication phase. Specifically, it queries the user list in the vulnerability management database for the corresponding username and uses the BCrypt algorithm to verify the input password against the encrypted password stored in the database. Simultaneously, the user management module 301 supports multi-factor authentication and can implement account lockout policies (e.g., locking the account for 15 minutes after 5 consecutive failed login attempts). It should be noted that BCrypt is an adaptive hash algorithm specifically designed for secure password storage. Its core advantage lies in actively increasing the computational time complexity and resource consumption, thereby resisting brute-force attacks. Specifically, BCrypt automatically generates a random "salt" during the hashing process. This salt is mixed with the password for hash calculation, and the salt value is directly stored in the final hash result. Therefore, even if two users have the same password, their hash values ​​will be completely different, preventing rainbow table attacks. BCrypt is based on a variation of the Blowfish encryption algorithm and performs multiple rounds of complex encryption operations on the password and salt combination. BCrypt also features an adjustable work factor, which (usually represented by a cost value) determines the strength of the hash calculation. As computer hardware performance improves, simply increasing the cost value can increase the time required to crack the hash, thus maintaining security.

[0135] After successful authentication, the user management module 301 can determine whether the user has plugin management permissions. The permission authentication process can be based on the user role and permission details field in the user list. Role permissions can build a multi-level permission system, such as administrator, auditor, and ordinary user, and can be set so that only administrators or users with corresponding operation permissions have plugin management permissions.

[0136] If a user is identified as having plugin management privileges, the user management module 301 will allow that user to access the plugin management function. The user can input specific plugin management commands through the system's visual interface or command-line tool. Specifically, this command is used to instruct the target to update the vulnerability repair plugins in the preset plugin library. The target update operation includes, but is not limited to: adding new vulnerability repair plugins, updating the version of existing plugins, or deleting outdated plugins. The command includes the identification information of the target plugin (such as plugin name, CVE number, version number) and the type of operation to be performed.

[0137] After confirming that a user has plugin management permissions, the user management module 301 can pass the obtained plugin management instructions to the vulnerability management service module 302. The vulnerability management service module 302 responds to the instructions by performing target update operations. First, the vulnerability management service module 302 can interact with the vulnerability management database according to the instructions to add, delete, and modify the vulnerability list. For example, when adding a new plugin, the vulnerability management service module 302 can insert a new record into the vulnerability list, filling in fields such as the plugin name, vulnerability CVE number, and the range of database versions containing the vulnerability.

[0138] Next, if the plugin management command is to add or update a plugin, the vulnerability management service module 302 can save or overwrite the new plugin file in the specified location of the plugin library; if the command is to delete, the corresponding plugin file is removed from the plugin library.

[0139] After updating the vulnerability management database and plugin library, the vulnerability management service module 302 can traverse the list of database services it maintains. For each running database service in the list whose database version number falls within the scope of the plugin's influence, the vulnerability management service module 302 can send an update notification to the plugin management module of that database service. After receiving the update notification, the database service can download the new vulnerability patching plugin from the vulnerability management service module 302 and load it into memory. It will take effect without restarting the service, achieving zero-downtime maintenance.

[0140] Figure 4 This is a schematic diagram of the vulnerability remediation device architecture provided in the embodiments of this application, such as... Figure 5 As shown, the device 40 includes:

[0141] The interception module 401 is used to obtain the request content in the original access request in response to the original access request of the target service.

[0142] Detection module 402 is used to detect whether there are vulnerabilities to be fixed in the request content;

[0143] Repair module 403 is used to call the target repair plugin corresponding to the vulnerability to be repaired among multiple vulnerability repair plugins when there is a vulnerability to be repaired. The target repair plugin repairs the request content and obtains the repaired access request.

[0144] Send the repaired access request to the target service so that the target service can execute the repaired access request.

[0145] Figure 5 This is a schematic diagram of the electronic device structure provided in the embodiments of this application, such as... ​As shown, the device 50 includes at least one processor 501 and a memory 502. Optionally, the device 50 also includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0146] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0147] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0148] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0149] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0150] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0151] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0152] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0153] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0154] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0155] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0156] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0157] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0158] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A vulnerability handling method, characterized in that, The method includes: In response to the original access request to the target service, obtain the request content in the original access request; Check if there are any vulnerabilities to be patched in the requested content; In the case of the vulnerability to be repaired, the target repair plugin corresponding to the vulnerability to be repaired is called among multiple vulnerability repair plugins, and the request content is repaired by the target repair plugin to obtain the repaired access request. The repaired access request is sent to the target service so that the target service executes the repaired access request.

2. The method according to claim 1, characterized in that, The detection of whether there are vulnerabilities to be patched in the request content includes: Among the feature information of multiple candidate vulnerabilities, determine whether there is target feature information that matches the request content; If the target feature information exists, then it is determined that the vulnerability to be repaired exists in the request content.

3. The method according to claim 2, characterized in that, Determining whether there is target feature information matching the request content among the feature information of multiple candidate vulnerabilities includes: Extract the command name and command parameters from the request content; The command name and command parameters are matched with the feature information according to preset rules to determine whether there is target feature information that matches the command name and command parameters.

4. The method according to claim 3, characterized in that, The step of matching the command name and command parameters with the feature information according to a preset rule to determine whether there is target feature information that matches the command name and command parameters includes: Check if any feature information matching the command name exists. If it does, then identify the feature information matching the command name as the target feature information, and / or... If a feature information matching the pattern of the command parameters exists, then the feature information matching the pattern of the command parameters is identified as the target feature information.

5. The method according to claim 2, characterized in that, The step of calling the target patching plugin corresponding to the vulnerability to be patched among multiple vulnerability patching plugins, and using the target patching plugin to patch the requested content, includes: In a preset mapping table, the target repair plugin corresponding to the target feature information is searched. The preset mapping table is used to indicate the correspondence between the feature information and the vulnerability repair plugin. The target repair plugin's call address is obtained from the preset mapping table, and the target repair plugin is invoked to repair the requested content using the call address.

6. The method according to claim 1, characterized in that, Before obtaining the request content in the original access request in response to the original access request of the target service, the method further includes: Obtain the version information of the target service; The version information is sent to a preset plugin library, and the vulnerability repair plugin corresponding to the version information returned by the preset plugin library is obtained.

7. The method according to claim 6, characterized in that, The step of sending the version information to a preset plugin library and obtaining the vulnerability patching plugin corresponding to the version information returned by the preset plugin library includes: Obtain the identification information of the plugins installed on the target service; The version information and the identification information are sent to the preset plugin library so that the preset plugin library can determine the vulnerability repair plugin that is different from the installed plugin and corresponds to the version information based on the version information and the identification information; Obtain the vulnerability repair plugin returned by the preset plugin library.

8. A vulnerability management system, characterized in that, The system includes: The user management module is used to obtain the authentication information input by the user and determine whether the user has plugin management permissions based on the authentication information. If the user has plugin management permissions, then the plugin management instruction input by the user is obtained. The plugin management instruction is used to instruct the vulnerability repair plugin in the preset plugin library to perform a target update operation. The vulnerability management service module is used to perform the target update operation on the vulnerability patching plugin in response to the plugin management command.

9. A vulnerability repair device, characterized in that, The device includes: The interception module is used to, in response to the original access request of the target service, obtain the request content in the original access request; The detection module is used to detect whether there are any vulnerabilities to be fixed in the requested content; The repair module is used to call the target repair plugin corresponding to the vulnerability to be repaired among multiple vulnerability repair plugins when the vulnerability to be repaired exists, and to repair the request content through the target repair plugin to obtain a repaired access request. The repaired access request is sent to the target service so that the target service executes the repaired access request.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images