A method and apparatus for verifying the coverage of network boundary security policies

By building multiple HTTP requests and verification policies, the problem of inaccurate and inflexible network boundary asset verification is solved, and more accurate and flexible WAF protection coverage verification is achieved, ensuring the accuracy and rapid deployment of verification results.

CN118972179BActive Publication Date: 2024-12-17BEIJING CHAITIN TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411449134.1
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-10-17
Publication Date
2024-12-17
Estimated Expiration
2044-10-17

AI Technical Summary

Technical Problem

When verifying whether network boundary assets are protected by WAF, there are problems such as different levels and tools of different security service personnel, inconsistent test results, and inability to flexibly adjust WAF configuration characteristics, resulting in insufficient verification and insufficient coverage.

Method used

By constructing multiple different HTTP requests and verification policies, sending HTTP requests for normal and attack tasks to the website to be verified, comparing the response code and judging whether the response contains WAF configuration features, ensuring the accuracy and flexibility of the verification results.

Benefits of technology

It improves the accuracy and flexibility of network boundary security policy coverage verification, ensures the speed and convenience of the verification process, and can more comprehensively cover the protection of network boundary assets.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN118972179B_ABST
    Figure CN118972179B_ABST
Patent Text Reader

Abstract

The present invention discloses a verification method and device for network boundary security policy coverage, and relates to the technical field of network security. The method includes: sending a normal http request to the web address of a website to be verified, and if the http request is not disconnected, it is recorded as a first response; sending an http request carrying an attack task to the web address of the website to be verified, and if the http request is not disconnected, it is recorded as a second response; judging whether the second response contains a user configuration feature that triggers WAF, otherwise comparing whether the first response and the second response are the same, if yes, waiting for a predetermined time and sending a normal http request again, if the http request is not disconnected, it is a third response; judging whether the third response contains a user configuration feature that triggers WAF, otherwise comparing whether the first response and the third response are the same, otherwise determining whether the website to be verified has WAF protection. The present invention makes the verification result more accurate, the verification method more flexible, and the solution deployment faster and more convenient.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a method and device for verifying network boundary security policy coverage. Background Art

[0002] With the iteration of security technology and products, users have deployed various WAF security devices. However, as the scale of users' assets continues to increase, how to ensure that all border assets (devices that provide entry points to the core network of enterprises or service providers, such as: office network border routers, firewalls, VPNs, websites, etc.) have been protected by deployed WAF devices is an issue that users urgently need to solve. The traditional way is for users to find dedicated network security service personnel to perform manual or automated testing on the border assets provided by customers, but this testing method has the following disadvantages:

[0003] (1) Different security service personnel have different levels and use different tools, so the test results will vary;

[0004] (2) Different security service personnel use different test attack requests and test different points, which results in failure to fully cover the border assets;

[0005] (3) It is impossible to flexibly adjust the WAF configuration features according to the customer's environment to perform more flexible coverage verification of the customer's boundary assets. Summary of the invention

[0006] In view of the above-mentioned defects or deficiencies in the prior art, the present invention provides a method and device for verifying the coverage of network boundary security policies. By constructing multiple different http requests and verification strategies, the network boundary security policy coverage (i.e., whether the network boundary assets are protected by WAF) is verified, so that the verification results are more accurate, the verification method is more flexible, and the solution deployment is faster and more convenient.

[0007] In one aspect of the present invention, a method for verifying the coverage of a network boundary security policy is provided, comprising the following steps: step 1, sending a normal http request to the web address of a website to be verified, if the http request is not disconnected, the received http response is recorded as a first response; step 2, sending an http request carrying an attack task to the web address of the website to be verified, if the http request carrying the attack task is not disconnected, the received http response is recorded as a second response; step 3, judging whether the second response contains a user configuration feature that triggers WAF, if it does not contain the user configuration feature that triggers WAF, comparing whether the response codes of the first response and the second response are the same, if the response codes of the two are the same, waiting for a predetermined time and sending a normal http request again, if the http request is not disconnected, the received http response is recorded as a third response; step 4, judging whether the third response contains a user configuration feature that triggers WAF, if it does not contain the user configuration feature that triggers WAF, comparing whether the response codes of the first response and the third response are the same, if the response codes of the two are different, it is determined that the website to be verified has WAF protection.

[0008] Furthermore, the step 1 also includes confirming that the website to be verified is not online if the http request is disconnected.

[0009] Furthermore, the step 2 also includes determining that the website to be verified has WAF protection if the http request carrying the attack task is disconnected.

[0010] Furthermore, the step three also includes determining that the website to be verified has WAF protection if the second response contains a user configuration feature that triggers the WAF.

[0011] Furthermore, the step three also includes determining that the website to be verified has WAF protection if the response codes of the first response and the second response are different.

[0012] Furthermore, the step three also includes determining that the website to be verified has WAF protection if the http request sent again after waiting for a predetermined time is disconnected.

[0013] Furthermore, the step four also includes determining that the website to be verified has WAF protection if the third response contains a user configuration feature that triggers the WAF.

[0014] Furthermore, the step four also includes determining that there is no WAF protection for the website to be verified if the response codes of the first response and the third response are the same.

[0015] In another aspect of the present invention, a verification device for network boundary security policy coverage is provided, comprising: a first module, configured to send a normal http request to the web address of the website to be verified, and if the http request is not disconnected, the received http response is recorded as the first response; a second module, configured to send an http request carrying an attack task to the web address of the website to be verified, and if the http request carrying the attack task is not disconnected, the received http response is recorded as the second response; a third module, configured to determine whether the second response contains a user configuration that triggers the WAF The fourth module is configured to determine whether the third response contains the user configuration feature that triggers WAF. If it does not contain the user configuration feature that triggers WAF, then compare whether the response codes of the first response and the second response are the same. If the response codes of the two are the same, wait for a predetermined time and then send a normal http request again. If the http request is not disconnected, the received http response is recorded as the third response. The fourth module is configured to determine whether the third response contains the user configuration feature that triggers WAF. If it does not contain the user configuration feature that triggers WAF, then compare whether the response codes of the first response and the third response are the same. If the response codes of the two are different, it is determined that the website to be verified has WAF protection.

[0016] Furthermore, the first module is further configured to confirm that the website to be verified is not online if the http request is disconnected;

[0017] Furthermore, the second module is further configured to determine that the website to be verified has WAF protection if the http request carrying the attack task is disconnected;

[0018] Furthermore, the third module is further configured to determine that the website to be verified has WAF protection if the second response contains a user configuration feature that triggers WAF; if the response codes of the first response and the second response are different, it is determined that the website to be verified has WAF protection; if the http request sent again after waiting for a predetermined time is disconnected, it is determined that the website to be verified has WAF protection;

[0019] Furthermore, the fourth module is further configured to determine that WAF protection exists for the website to be verified if the third response contains user configuration features that trigger WAF; if the response codes of the first response and the third response are the same, determine that WAF protection does not exist for the website to be verified.

[0020] The present invention provides a method and device for verifying network boundary security policy coverage, which can verify network boundary security policy coverage in a more flexible, comprehensive and accurate manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Other features, objects and advantages of the present application will become more apparent by reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0022] Figure 1 This is a first flow chart of a method for verifying network boundary security policy coverage provided by an embodiment of the present application;

[0023] Figure 2 This is a second flow diagram of a method for verifying network boundary security policy coverage provided by an embodiment of the present application;

[0024] Figure 3 It is a structural schematic diagram of a network boundary security policy coverage verification device provided by an embodiment of the present application;

[0025] Figure 4 It is a schematic diagram of the structure of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0026] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0027] The terms used in the embodiments of the present invention are only for the purpose of describing specific embodiments, and are not intended to limit the present invention. The singular forms "a", "said" and "the" used in the embodiments of the present invention and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings.

[0028] It should be understood that although the terms first, second, third, etc. may be used to describe the acquisition modules in the embodiments of the present invention, the acquisition modules should not be limited to these terms. These terms are only used to distinguish the acquisition modules from each other.

[0029] The word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrases "if it is determined" or "if (stated condition or event) is detected" may be interpreted as "when it is determined" or "in response to determining" or "when detecting (stated condition or event)" or "in response to detecting (stated condition or event)", depending on the context.

[0030] It should be noted that the directional words such as "upper", "lower", "left", and "right" described in the embodiments of the present invention are described at the angles shown in the drawings and should not be understood as limiting the embodiments of the present invention. In addition, in the context, it should also be understood that when it is mentioned that an element is formed "on" or "under" another element, it can not only be formed directly "on" or "under" another element, but also be formed "on" or "under" another element indirectly through an intermediate element.

[0031] The present application provides a verification method for network boundary security policy coverage to automatically verify whether the boundary assets have WAF protection, which greatly improves the accuracy and effectiveness of the verification results and makes the verification process more flexible. The boundary assets of the present application refer to devices that provide entry points to the core network of an enterprise or service provider, including office network boundary routers, edge gateways, firewalls, VPNs, website servers, business servers, etc., which are distributed at the edge of the network and are intelligent devices that collect and process data. The verification process of the present invention is explained below using a website as an example.

[0032] See also Figure 1 , 2 The network boundary security policy coverage verification method of this embodiment is used on the client side. By selecting the target environment in the client, the boundary policy coverage of all assets in the current environment can be verified, thereby verifying whether these assets have been protected by the WAF security device. The network boundary security policy coverage verification method specifically includes the following steps:

[0033] Step S101, sending a normal http request to the web address of the website to be verified, if the http request is not disconnected, the received http response is recorded as the first response.

[0034] Specifically, the user's boundary asset list contains all the device web addresses, and the user can select any web address to verify whether the device has WAF protection. Since the web address in the boundary asset list may be an invalid website or the website has been offline, this step selects a website web address to be verified in the user's boundary asset list, and sends a normal http request to the web address of the website to be verified, without carrying any attack tasks, to test whether a network connection with the web address can be established normally. If the normal http request is disconnected, it can be determined that the website to be verified is not online or has been offline; if the normal http request is not disconnected, the received http response is recorded as the first response.

[0035] Step S102, sending an http request carrying an attack task to the web address of the website to be verified, if the http request carrying the attack task is not disconnected, the received http response is recorded as the second response.

[0036] Specifically, after the connection with the above web address is established, an http request carrying a network attack task is sent to the above web address of the website to be verified. If the http request carrying the network attack task is disconnected at this time, it can be determined that the website to be verified has WAF protection. If the http request is not disconnected, the client will inevitably receive an http response, and the received http response is recorded as the second response.

[0037] Step S103, determine whether the second response contains the user configuration feature that triggers WAF. If it does not contain the user configuration feature that triggers WAF, compare whether the response codes of the first response and the second response are the same. If the response codes of the two are the same, wait for a predetermined time and then send a normal http request again. If the http request is not disconnected, the received http response is recorded as the third response.

[0038] Specifically, after implementing step S102, it is continued to determine whether the second response contains user configuration features that trigger WAF. It should be noted that the configuration feature refers to the content that triggers WAF interception in the URL or request body of the http request carrying the attack task, such as XSS characters or SQL injection characters. In this case, if the current website to be verified has been configured with WAF protection, an interception page will be returned to the client. The present invention determines whether the current request is intercepted by WAF by identifying some features carried in the interception page.

[0039] Optionally, configure common features on the market as identification features for WAF protection on the interception page. Common identification features for WAF protection include:

[0040] (1) AliYunDun WAF: The intercepted page will contain the keyword feature "errors.aliyun.com" and return a 405 status code;

[0041] (2) Huawei Cloud WAF: The intercepted pages contain the keyword feature "HuaweiCloudWAF", and the corresponding HTTP Header Cookie contains the keyword feature "HWWAFSESTIME";

[0042] (3) Safedog WAF: The intercepted pages contain keyword features such as “www.safedog.cn”, “security.safedog.cn”, and “Please log in to Safedog”.

[0043] More preferably, in order to flexibly adjust the WAF configuration features according to the environment on the customer side, set user-defined configuration features (ie, user configuration features) in the interception page, for example:

[0044] (1) Return to the customized page;

[0045] (2) Custom status code, that is, not using the default HTTP status code of WAF.

[0046] That is to say, when customizing user configuration features, customers can customize their own status codes. Customers can also customize pages, and the response content of the page can contain fixed descriptions or pictures. Among them, the fixed text description is, for example, "Sorry, your access is blocked because the URL you visited may pose a security threat to the website." Customers can also customize a picture or logo related to the company and provide the md5 value of the specific picture in the configuration feature.

[0047] Further, if the second response contains a user configuration feature that triggers WAF, it can be determined that the website to be verified has WAF protection. If the second response does not contain a user configuration feature that triggers WAF, the response codes of the first response and the second response are compared to see if they are the same. It should be noted that the response code refers to a status code returned by a website when an http request is sent to a website, which is commonly referred to as an http status code. The inventor of the present application has found through a large number of attack experiments that a normal http request and an http request carrying an attack task sometimes obtain normal http responses on a website with WAF protection, that is, the response codes / status codes of the two are sometimes the same, and even some websites may directly jump to the homepage of the website, that is, return the page of a normal website. However, sometimes the page or status code / response code returned by the http request carrying the attack task and the normal http request on the website with WAF protection will be slightly different, for example: when sending a normal http request, the status code / response code is usually 200, but when sending an http request carrying the attack task, the website with WAF protection will return a status code / response code of 301 or 302. Therefore, when the response codes of a normal http request and an http request with an attack task are the same, it does not mean that the website to be verified does not have WAF protection; when the response codes of a normal http request and an http request with an attack task are different, it means that the website to be verified has WAF protection. In this way, by comparing whether the response codes of the first response and the second response are the same, it can be determined whether the website to be verified has WAF protection. For example: if the response codes of the first response and the second response are different, it can be determined that the website to be verified has WAF protection.

[0048] Furthermore, if the response codes of the first response and the second response are the same, further verification is required. It should be noted that, because an attack request has been sent before, a website with WAF protection sometimes does not intercept the attack request sent for the first time, but returns an ordinary http response like a normal request, but will make a special response to the next request. In order to increase the accuracy of the verification, this embodiment sends a normal request again after the first attack request, so that the response of the website during the first http request (i.e., the first response in front) and the response of the website when the http request is sent again after the attack request is sent (i.e., the third response in the back) are compared to see if there are differences in the response content, and some clues can be found. Specifically, after waiting for a predetermined time (for example: the response time of the IP-blocking WAF is tens of seconds, which can be set to 30 seconds), the client sends a normal http request to the web address of the website to be verified again. If the http request sent again is disconnected, it can be determined that the website to be verified has WAF protection. The reason for this is that if attack requests are sent frequently, the WAF device will directly block the IP address of the current client. If the IP address is blocked, the IP address of the current client will be intercepted by the WAF even if it sends a normal request. Therefore, this embodiment tries to delay for a period of time before initiating the next request to avoid the IP being blocked, but even if there is a delay, the IP may be blocked, that is, if the normal http request is disconnected, it means that the IP is blocked, which means that the website has WAF protection. Furthermore, if the normal http request sent again is not disconnected, the http response received by the client is recorded as the third response.

[0049] Step S104, determining whether the third response contains user configuration features that trigger WAF. If it does not contain user configuration features that trigger WAF, comparing whether the response codes of the first response and the third response are the same. If the response codes of the two are different, determining that the website to be verified has WAF protection.

[0050] This step is used to verify the difference between the two response codes when there was an attack request before and when there was no attack request before, and determine the WAF protection status based on the difference. Specifically, first determine whether the third response contains user configuration features that trigger WAF. If it contains user configuration features that trigger WAF, it is determined that the website to be verified has WAF protection. If the third response does not contain user configuration features that trigger WAF, compare whether the response codes of the first response and the third response are the same. If the response codes of the two are different, it can be determined that the website to be verified has WAF protection. If the response codes of the two are the same, it can be determined that the website to be verified does not have WAF protection (because the response codes are the same when there was an attack request before and when there was no attack request before, which means that there is basically no WAF protection).

[0051] The above steps S101 - S104 are explained below with an actual example.

[0052] Assume that the user wants to perform a WAF protection test on the website with the web address http: / / www.xxx.com.

[0053] Step 1: Send a normal http request, which is no different from the http request when accessing a website through a browser. The purpose is to check the connection status of the website. If the connection is successful, the http response is saved as response-1;

[0054] Step 2: Send an attack request to the above website. This attack request will carry some content that can obviously trigger WAF interception.

[0055] For example, XSS:

[0056] “ <style>.XSS{background-image:url("javascript:alert('XSS')");}< / style> ”,

[0057] Another example is SQL injection:

[0058] "extractvalue(1,concat(0x5c,(select database())))".

[0059] Then, determine whether the http request will be intercepted. If it is intercepted, it means that the website has

[0060] In WAF protection, if it is not intercepted, the http response is recorded as response-2.

[0061] Step 3: If the judgment still cannot be made, compare the response codes of response-1 and response-2 to see if they are the same. If the response codes are different, it can be determined that the website has WAF protection. If the response codes are the same, since normal http requests and abnormal http requests sometimes return the same http response, it is necessary to continue to make judgments. After waiting for 30 seconds, send a normal http request again and judge whether it is intercepted. If it is intercepted, it indicates that the website has WAF protection. If it is not intercepted, the http response is recorded as response-3.

[0062] Step 4: First, determine whether response-3 contains the user configuration features that trigger WAF. If so, it indicates that the website has WAF protection. Otherwise, compare whether the response codes of response-1 and response-3 are the same. If the response codes of the two are different, it can be directly determined that the website to be verified has WAF protection. If the response codes of the two are the same, no further verification is performed, and it can be directly determined that the website to be verified does not have WAF protection.

[0063] This embodiment verifies the coverage of the network boundary security policy (i.e., whether the network boundary assets are protected by WAF) by constructing multiple different http requests and verification strategies, so that the verification result is more accurate, the verification method is more flexible, and the solution deployment is faster and more convenient.

[0064] See also Figure 3 Another embodiment of the present application also provides a network boundary security policy coverage verification device 200, including a first module 201, a second module 202, a third module 203, and a fourth module 204. The verification device 200 can execute the network boundary security policy coverage verification method in the above method embodiment.

[0065] Specifically, the network boundary security policy coverage verification device 200 includes:

[0066] The first module is configured to send a normal http request to the web address of the website to be verified, and if the http request is not disconnected, the received http response is recorded as the first response;

[0067] The second module is configured to send an http request carrying an attack task to the web address of the website to be verified, and if the http request carrying the attack task is not disconnected, the received http response is recorded as a second response;

[0068] The third module is configured to determine whether the second response contains a user configuration feature that triggers the WAF. If the second response does not contain the user configuration feature that triggers the WAF, compare whether the response codes of the first response and the second response are the same. If the response codes of the two are the same, wait for a predetermined time and then send a normal http request again. If the http request is not disconnected, record the received http response as the third response.

[0069] The fourth module is configured to determine whether the third response contains user configuration features that trigger WAF. If it does not contain user configuration features that trigger WAF, compare whether the response codes of the first response and the third response are the same. If the response codes of the two are different, it is determined that the website to be verified has WAF protection.

[0070] Furthermore, the first module 201 is also configured to confirm that the website to be verified is not online if the http request is disconnected;

[0071] Furthermore, the second module 202 is also configured to determine that the website to be verified has WAF protection if the http request carrying the attack task is disconnected;

[0072] Further, the third module 203 is also configured to determine that the website to be verified has WAF protection if the second response contains a user configuration feature that triggers WAF; if the response codes of the first response and the second response are different, it is determined that the website to be verified has WAF protection; if the http request sent again after waiting for a predetermined time is disconnected, it is determined that the website to be verified has WAF protection;

[0073] Furthermore, the fourth module 204 is also configured to determine that the website to be verified has WAF protection if the third response contains user configuration features that trigger WAF; if the response codes of the first response and the third response are the same, determine that the website to be verified has no WAF protection.

[0074] It should be noted that the verification device 200 provided in this embodiment corresponds to a technical solution that can be used to execute various method embodiments, and its implementation principle and technical effects are similar to those of the method, which will not be repeated here.

[0075] See also Figure 4 Another embodiment of the present application further provides an electronic device 300 for implementing the network boundary security policy coverage verification method in the method embodiment. The electronic device 300 may include but is not limited to terminal devices such as PCs, servers, PDAs, and smart phones. Figure 4 The electronic device 300 shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0076] like Figure 4 As shown, the electronic device 300 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 to a random access memory (RAM) 303 to implement the method of the embodiment of the present invention. In the RAM 303, various programs and data required for the operation of the electronic device 300 are also stored. The processing device 301, the ROM 302, and the RAM 303 are connected to each other via a bus 305. An input / output (I / O) interface 304 is also connected to the bus 305.

[0077] Typically, the following devices may be connected to the I / O interface 304: an input device 306 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 307 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 308 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 309. The communication device 309 may allow the electronic device 300 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 4 The electronic device 300 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0078] The above description is only a preferred embodiment of the present invention. Those skilled in the art should understand that the scope of disclosure involved in the present invention is not limited to the technical solution formed by a specific combination of the above technical features, but also should cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present invention (but not limited to) to form a technical solution.

Claims

1. A method for verifying network boundary security policy coverage, characterized in that: The steps include: Step 1: Send a normal http request to the web address of the website to be verified. If the http request is not disconnected, the received http response is recorded as the first response; if the http request is disconnected, it is confirmed that the website to be verified is not online; Step 2: Send an http request carrying an attack task to the web address of the website to be verified. If the http request carrying the attack task is not disconnected, the received http response is recorded as the second response; if the http request carrying the attack task is disconnected, it is determined that the website to be verified has WAF protection; Step 3: determine whether the second response contains the user configuration feature that triggers WAF. If it does not contain the user configuration feature that triggers WAF, compare whether the response codes of the first response and the second response are the same. If the response codes of the two are the same, wait for a predetermined time and send a normal http request again. If the http request is not disconnected, record the received http response as the third response; if the second response contains the user configuration feature that triggers WAF, it is determined that the website to be verified has WAF protection; if the response codes of the first response and the second response are different, it is determined that the website to be verified has WAF protection; if the http request sent again after waiting for a predetermined time is disconnected, it is determined that the website to be verified has WAF protection; Step 4, determine whether the third response contains user configuration features that trigger WAF. If it does not contain user configuration features that trigger WAF, compare whether the response codes of the first response and the third response are the same. If the response codes of the two are different, determine that the website to be verified has WAF protection; if the third response contains user configuration features that trigger WAF, determine that the website to be verified has WAF protection; if the response codes of the first response and the third response are the same, determine that the website to be verified does not have WAF protection.

2. A network boundary security policy coverage verification device, characterized in that: include: The first module is configured to send a normal http request to the web address of the website to be verified, and if the http request is not disconnected, the received http response is recorded as the first response; if the http request is disconnected, it is confirmed that the website to be verified is not online; The second module is configured to send an http request carrying an attack task to the web address of the website to be verified, and if the http request carrying the attack task is not disconnected, the received http response is recorded as a second response; If the http request carrying the attack task is disconnected, it is determined that the website to be verified has WAF protection; The third module is configured to determine whether the second response contains a user configuration feature that triggers WAF. If it does not contain the user configuration feature that triggers WAF, compare whether the response codes of the first response and the second response are the same. If the response codes of the two are the same, wait for a predetermined time and send a normal http request again. If the http request is not disconnected, record the received http response as the third response; if the second response contains a user configuration feature that triggers WAF, it is determined that the website to be verified has WAF protection; if the response codes of the first response and the second response are different, it is determined that the website to be verified has WAF protection; if the http request sent again after waiting for a predetermined time is disconnected, it is determined that the website to be verified has WAF protection; The fourth module is configured to determine whether the third response contains user configuration features that trigger WAF. If it does not contain user configuration features that trigger WAF, compare whether the response codes of the first response and the third response are the same. If the response codes of the two are different, it is determined that WAF protection exists for the website to be verified; if the third response contains user configuration features that trigger WAF, it is determined that WAF protection exists for the website to be verified; if the response codes of the first response and the third response are the same, it is determined that WAF protection does not exist for the website to be verified.