Web cache poisoning vulnerability detection method and device, electronic equipment and medium

Abstract

The invention relates to a Web cache poisoning vulnerability detection method and device, electronic equipment and a medium. The method comprises the following steps: acquiring a cache key of a Web cache server; generating a to-be-verified standard request according to a cache key of the Web cache server, and performing various variation tests on the to-be-verified standard request to obtain a plurality of varied attack requests; and verifying the plurality of mutated attack requests to obtain a verification result, judging the verification result based on a preset authentication condition, and if the verification result meets the preset authentication condition, judging that the attack request is an available poisoning request. Therefore, the cache poisoning attack test cases covering various forms are generated for different parts of the request, various types of cache poisoning attack vulnerabilities existing in the URL are comprehensively and systematically detected, various potential cache poisoning attacks and novel cache poisoning attacks are avoided, and the cache poisoning attack test efficiency is improved. And security personnel can be helped to better detect and protect cache poisoning attacks aiming at own websites.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a Web cache poisoning vulnerability detection method, device, electronic equipment and medium. Background Art

[0002] A cache poisoning attack is an attack that exploits the difference in request processing between a network cache and an origin server, tricking the server into generating an erroneous response that is cached by the cache server, causing the victim to be unable to obtain the response normally. For example, an attacker can craft a malicious URL that exploits the difference in URL path resolution between the cache and the origin server to trick the cache into storing a dynamic response. The attacker can then request the same URL to access the cached response, thereby gaining unauthorized access to private information.

[0003] In the related art, attack behaviors are usually detected, and cache poisoning attacks are defended by identifying whether malicious cache poisoning behaviors occur on the network system.

[0004] However, the above technical means cannot detect potential exploitable vulnerabilities in the target system and are prone to missed detection errors, which need to be solved urgently. Summary of the invention

[0005] The present invention provides a Web cache poisoning vulnerability detection method, device, electronic device and medium to solve the problem that the detection of attack behavior in the related art cannot detect potential vulnerabilities in the target system and is prone to missed detection errors. It can comprehensively and systematically detect various types of cache poisoning attack vulnerabilities existing in URLs, avoid multiple potential cache poisoning attacks and various new cache poisoning attacks, and help security personnel better detect and protect their own websites from cache poisoning attacks.

[0006] To achieve the above object, a first embodiment of the present invention provides a method for detecting a Web cache poisoning vulnerability, comprising the following steps:

[0007] Get the cache key of the web cache server;

[0008] Generate a standard request to be verified according to the cache key of the Web cache server, and perform multiple mutation tests on the standard request to be verified to obtain multiple mutated attack requests;

[0009] The multiple mutated attack requests are verified to obtain verification results, and the verification results are determined based on preset authentication conditions. If the verification results meet the preset authentication conditions, the attack requests are determined to be exploitable poisoned requests.

[0010] According to an embodiment of the present invention, obtaining the cache key of the Web cache server includes:

[0011] Obtaining HTTP traffic and an RFC document, and generating a standard HTTP request according to the HTTP traffic and the RFC document;

[0012] Acquire multiple standard fields according to the standard HTTP request, and modify each standard field one by one to obtain multiple modified fields;

[0013] The cache key of the Web cache server is detected and obtained according to the multiple standard fields and the multiple modified fields.

[0014] According to an embodiment of the present invention, performing multiple variation tests on the standard request to be verified includes:

[0015] Based on a preset request line mutation strategy, mutate the request line of the standard request to be verified to obtain a first attack request;

[0016] Based on a preset request header mutation strategy, mutate the request header of the standard request to be verified to obtain a second attack request;

[0017] Based on a preset request body mutation strategy, mutate the request body of the standard request to be verified to obtain a third attack request;

[0018] Based on a preset request length variation strategy, performing a request length variation on the standard request to be verified to obtain a fourth attack request;

[0019] The multiple mutated attack requests are obtained according to the first attack request, the second attack request, the third attack request, and the fourth attack request.

[0020] According to an embodiment of the present invention, determining the verification result based on a preset authentication condition includes:

[0021] Obtain a first response according to the standard request to be verified, obtain a second response according to the mutated attack request, and determine whether the first response and the second response are consistent;

[0022] If the first response is inconsistent with the second response, re-obtaining the third response according to the standard request to be verified, and determining whether the second response is consistent with the third response and whether the third response hits the cache key;

[0023] If the second response is consistent with the third response and the third response hits the cache key of the Web cache server, the attack request is determined to be the exploitable poisoned request.

[0024] According to an embodiment of the present invention, after determining that the attack request is a poisoned request that can be exploited, the method further includes:

[0025] Based on all the exploitable poisoned requests, generating a cache poisoning attack request set;

[0026] The cache poisoning attack request set is output.

[0027] According to the Web cache poisoning vulnerability detection method proposed in the embodiment of the present invention, different parts of the HTTP request are detected in sequence, and after the cache key is detected, a mutation test is performed on the request generated according to the cache key, and a request is sent to the server according to the attack request generated by the mutation test, and it is determined whether it is an exploitable poisoned request based on the difference in the obtained response. Therefore, by generating cache poisoning attack test cases covering various forms for different parts of the request, various types of cache poisoning attack vulnerabilities existing in the URL are comprehensively and systematically detected, avoiding various potential cache poisoning attacks and new cache poisoning attacks, and helping security personnel to better detect and protect against cache poisoning attacks on their own websites.

[0028] To achieve the above object, a second embodiment of the present invention provides a Web cache poisoning vulnerability detection device, comprising:

[0029] The acquisition module is used to obtain the cache key of the Web cache server;

[0030] A mutation module, used for generating a standard request to be verified according to the cache key of the Web cache server, and performing multiple mutation tests on the standard request to be verified to obtain multiple mutated attack requests;

[0031] The determination module is used to verify the multiple mutated attack requests to obtain verification results, and determine the verification results based on preset authentication conditions. If the verification results meet the preset authentication conditions, the attack request is determined to be a poisoned request that can be exploited.

[0032] According to an embodiment of the present invention, the acquisition module is specifically used to:

[0033] Obtaining HTTP traffic and an RFC document, and generating a standard HTTP request according to the HTTP traffic and the RFC document;

[0034] Acquire multiple standard fields according to the standard HTTP request, and modify each standard field one by one to obtain multiple modified fields;

[0035] The cache key of the Web cache server is detected and obtained according to the multiple standard fields and the multiple modified fields.

[0036] According to one embodiment of the present invention, the mutation module is specifically used for:

[0037] Based on a preset request line mutation strategy, mutate the request line of the standard request to be verified to obtain a first attack request;

[0038] Based on a preset request header mutation strategy, mutate the request header of the standard request to be verified to obtain a second attack request;

[0039] Based on a preset request body mutation strategy, mutate the request body of the standard request to be verified to obtain a third attack request;

[0040] Based on a preset request length variation strategy, performing a request length variation on the standard request to be verified to obtain a fourth attack request;

[0041] The multiple mutated attack requests are obtained according to the first attack request, the second attack request, the third attack request, and the fourth attack request.

[0042] According to an embodiment of the present invention, the determination module is specifically used to:

[0043] Obtain a first response according to the standard request to be verified, obtain a second response according to the mutated attack request, and determine whether the first response and the second response are consistent;

[0044] If the first response is inconsistent with the second response, re-obtaining the third response according to the standard request to be verified, and determining whether the second response is consistent with the third response and whether the third response hits the cache key;

[0045] If the second response is consistent with the third response and the third response hits the cache key of the Web cache server, the attack request is determined to be the exploitable poisoned request.

[0046] According to an embodiment of the present invention, after determining that the attack request is a poisoned request that can be exploited, the determination module is further configured to:

[0047] Based on all the exploitable poisoned requests, generating a cache poisoning attack request set;

[0048] The cache poisoning attack request set is output.

[0049] According to the Web cache poisoning vulnerability detection device proposed in the embodiment of the present invention, by detecting different parts of the HTTP request in sequence, after detecting the cache key, a mutation test is performed on the request generated according to the cache key, a request is sent to the server according to the attack request generated by the mutation test, and it is determined whether it is an exploitable poisoned request based on the difference in the obtained response. Therefore, by generating cache poisoning attack test cases covering various forms for different parts of the request, various types of cache poisoning attack vulnerabilities existing in the URL are comprehensively and systematically detected, avoiding various potential cache poisoning attacks and new cache poisoning attacks, and helping security personnel to better detect and protect against cache poisoning attacks on their own websites.

[0050] To achieve the above objectives, a third aspect of the present invention provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the Web cache poisoning vulnerability detection method as described in the above embodiment.

[0051] To achieve the above objectives, a fourth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the Web cache poisoning vulnerability detection method as described in the above embodiments.

[0052] To achieve the above objectives, a fifth aspect of the present invention provides a computer program product, including a computer program. When the computer program is executed by a processor, it is used to implement the Web cache poisoning vulnerability detection method as described in the above embodiment.

[0053] Additional aspects and advantages of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] The above and / or additional aspects and advantages of the present invention will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0055] Figure 1 Schematic diagram of cache hit and cache poisoning attack principles;

[0056] Figure 2 A flowchart of a method for detecting a Web cache poisoning vulnerability provided by an embodiment of the present invention;

[0057] Figure 3 A schematic diagram of a flow chart of a cache checking algorithm provided according to a specific embodiment of the present invention;

[0058] Figure 4A schematic diagram of a flow chart of a request line mutation algorithm provided according to a specific embodiment of the present invention;

[0059] Figure 5 A schematic diagram of a flow chart of a request header mutation algorithm provided according to a specific embodiment of the present invention;

[0060] Figure 6 A schematic diagram of a flow chart of a special request header mutation algorithm provided according to a specific embodiment of the present invention;

[0061] Figure 7 A schematic diagram of a flow chart of a filter field blacklist mutation algorithm provided according to a specific embodiment of the present invention;

[0062] Figure 8 A schematic diagram of a flow chart of a request body mutation algorithm provided according to a specific embodiment of the present invention;

[0063] Fig. 9 A schematic diagram of a flow chart of a request length variation algorithm provided according to a specific embodiment of the present invention;

[0064] Fig.10 A schematic diagram of a flow chart of a cache poisoning determination algorithm provided according to a specific embodiment of the present invention;

[0065] Fig.11 A system architecture diagram of a Web cache poisoning vulnerability detection method provided according to a specific embodiment of the present invention;

[0066] Fig.12 A block diagram of a Web cache poisoning vulnerability detection device provided according to an embodiment of the present invention;

[0067] Fig.13 It is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present invention.

[0068] Among them, 10-Web cache poisoning vulnerability detection device; 100-acquisition module, 200-mutation module, 300-determination module; 1301-memory, 1302-processor, 1303-communication interface. DETAILED DESCRIPTION

[0069] Embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present invention, and should not be construed as limiting the present invention.

[0070] A Web cache poisoning vulnerability detection method, device, electronic device, and medium according to an embodiment of the present invention are described below with reference to the accompanying drawings.

[0071] Before introducing the Web cache poisoning vulnerability detection method according to the embodiment of the present invention, the principles of cache hit and cache poisoning attack are briefly introduced.

[0072] Specifically, if Figure 1 As shown, Figure 1 The following is a schematic diagram of the principles of cache hit and cache poisoning attacks. When a request initiated by a client has the same cache key as the previous request and the relevant Web resource object is valid in the cache device, a cache hit occurs and the cache device directly returns the cached requested resource. If the cache does not hit, the cache device will pull the resource from the backend source server and return it to the client; at the same time, the cache device will usually cache it effectively according to the Web resource cache time set by the source server. Obviously, the higher the cache hit rate of the service, the better the acceleration effect of the cache device on network performance. The cache key corresponds to each Web resource object in the cache one by one, that is, the cache key is the unique identifier of the Web resource object in the cache. According to RFC and the implementation of mainstream Web application vendors on the Internet, the cache key is usually composed of the request method, the request host name and the request URI. However, different Web application vendors may use certain headers as cache keys to implement some additional functions. Cache poisoning attack is an attack that exploits the difference in request processing between the network cache and the source server, inducing the server to generate an incorrect response and be cached by the cache server, resulting in the victim being unable to obtain the response normally. The figure is a basic model of a cache poisoning attack. Cache poisoning attacks are usually divided into the following four steps:

[0073] (1) The attacker sends a malicious HTTP request customized for the website to be attacked;

[0074] (2) The cache server does not identify and filter malicious requests and forwards the requests to the origin server;

[0075] (3) The malicious request triggers an exception on the source server, causing the server to return an abnormal or erroneous HTTP response, and the resource in the response is cached in the cache server;

[0076] (4) The normal request initiated by the victim hits the contaminated cache resources on the cache server, thus being attacked.

[0077] Based on the above principles, it is clear that cache hits, i.e. cache key matches, are the key to a successful cache poisoning attack. Therefore, to detect cache poisoning, you first need to determine which fields in the HTTP request make up the cache key. Subsequently, during the cache poisoning test, you can detect cache poisoning attacks by sending requests with the same cache key and determining whether the responses triggered by different requests are consistent. In summary, to detect cache poisoning attacks, you first need to find out which fields in the HTTP request make up a cache key so that subsequent tests can be performed more efficiently.

[0078] Therefore, the embodiment of the present invention proposes a Web cache poisoning vulnerability detection method, in which different parts of the HTTP request are detected in sequence, and after the cache key is detected, a mutation test is performed on the request generated according to the cache key, and a request is sent to the server according to the attack request generated by the mutation test, and it is determined whether it is an exploitable poisoned request based on the difference in the obtained response. Thus, the problem that the detection of attack behavior in the related technology cannot detect potential vulnerabilities in the target system and is prone to missed detection errors is solved. By generating cache poisoning attack test cases covering various forms for different parts of the request, various types of cache poisoning attack vulnerabilities in the URL are comprehensively and systematically detected, avoiding various potential cache poisoning attacks and new cache poisoning attacks, and helping security personnel to better detect and protect against cache poisoning attacks on their own websites.

[0079] Specifically, Figure 2 The present invention provides a flowchart of a method for detecting a Web cache poisoning vulnerability.

[0080] like Figure 2 As shown, the Web cache poisoning vulnerability detection method includes the following steps:

[0081] In step S201, a cache key of a Web cache server is obtained.

[0082] Specifically, the cache key is a unique identifier used to determine whether the resource requested by the user hits the edge cache content. Therefore, the embodiment of the present invention proposes a universal cache detection algorithm, which detects whether different parts of the HTTP request are a cache key in turn, and judges the header list of the HTTP request in turn to ensure that various different headers are covered to prevent missed detections.

[0083] As a possible implementation method, in some embodiments, obtaining the cache key of the Web cache server includes: obtaining HTTP traffic and RFC documents, and generating a standard HTTP request based on the Web cache poisoning vulnerability detection HTTP traffic and the Web cache poisoning vulnerability detection RFC documents; obtaining multiple standard fields based on the Web cache poisoning vulnerability detection standard HTTP request, and modifying each standard field one by one to obtain multiple modified fields; and obtaining the cache key of the Web cache poisoning vulnerability detection Web cache server based on the Web cache poisoning vulnerability detection multiple standard fields and the Web cache poisoning vulnerability detection multiple modified fields.

[0084] Specifically, the embodiment of the present invention needs to find which lines or header fields in the HTTP request are used as cache keys by the Web cache server. Therefore, it is necessary to first generate a standard HTTP request based on the HTTP traffic and the RFC document, and then modify each field of the standard request one by one, and send and compare the responses of the standard request and the modified request in turn to detect which HTTP request fields are cache keys.

[0085] For example, Figure 3 As shown, Figure 3 This is a flow chart of a cache checking algorithm provided according to a specific embodiment of the present invention. The cache checking algorithm comprises the following steps:

[0086] S301, start.

[0087] S302, input: URL.

[0088] S303, generate standard request 1.

[0089] S304, send request 1, and obtain response 1.

[0090] S305, determine if i<the maximum number of rows in request 1, if yes, execute step S306; if no, execute step S311.

[0091] S306, modify the content of the i-th line in request 1.

[0092] S307, send request 2, and obtain response 2.

[0093] S308, determine if response 1 ≠ response 2 and the cache identification header of response 2 == miss, if yes, execute step S309; ​​if no, execute step S310.

[0094] S309, adding the first row to the result.

[0095] S310, execute i=i+1, and return to execute S305.

[0096] S311, determine if i<header list length, if yes, execute step S312; if no, execute step S318.

[0097] S312, add the i-th header to be tested to request 1 to generate request 3.

[0098] S313, send request 3, and obtain response 3.

[0099] S314, adding the i-th header to be tested to request 1.

[0100] S315, determine if response 1 ≠ response 3 and the cache identification header of response 3 == miss, if yes, execute step S316; if no, execute step S317.

[0101] S316, adding the i-th head to be tested to the result.

[0102] S317, execute i=i+1, and return to execute step S311.

[0103] S318, output: cache key corresponding to the URL.

[0104] S319, end.

[0105] According to the above process, the cache verification algorithm proposed by the present invention includes a cache key detection function, which is specifically as follows:

[0106]

[0107]

[0108] Among them, the first step of this function is to generate a basic HTTP request and obtain the normal response generated by the basic request (line2-3). In the basic request generation step, some common HTTP request templates are generated based on expert knowledge and traffic analysis, in order to cover common Web requests through this template, such as simple HEAD requests, GET requests, and POST requests with data. In addition, in order to prevent these basic requests from being directly rejected by the target server, their data format needs to be similar to ordinary HTTP traffic. Common header fields will be added to the generated request, including Host, User-Agent, Cookie, Accept-Encoding, etc. Among them, the Host field will automatically adapt to the domain name of the target website. A series of basic HTTP requests can be obtained through this component.

[0109] The second step is to determine which HTTP lines in the generated basic request are cache keys (line 5-9). By traversing different lines in the request and making changes to different lines, and then comparing them with the previous verification request, we can determine whether the cache is hit. There are two specific modification methods. For the HTTP request line, make different changes to the three parts respectively. For the request method, traverse all the request methods specified in the RFC, such as GET, POST, HEAD, etc. For the path part, add different common parameters at the end; for the HTTP protocol version part, try different versions such as HTTP / 1.0, HTTP / 1.1 and HTTP / 2.0. For other HTTP request headers, change their value parts. Send the modified request to get the response. If the response is inconsistent with the previous response, and the cache identification fields in the response, such as X-Cache, Age, etc., show that the cache is not hit, it means that the modified part is a cache key.

[0110] The third step is to further determine whether other headers not in the basic request are the cache keys of the website (line 10-14). This is done by checking the header list consisting of all common headers collected and specific headers of different CDNs and servers one by one, adding the headers in the list to the standard headers one by one, and sending a request with the new header added to get a response. If the response is inconsistent with the previous response, and the cache identification fields in the response, such as X-Cache, Age, etc., show a cache miss, it means that the newly added header is a cache key for the URL.

[0111] Finally, the result of the cache key detection function is output (line 15).

[0112] In step S202, a standard request to be verified is generated according to a cache key of a Web cache server for detecting a Web cache poisoning vulnerability, and multiple mutation tests are performed on the standard request to be verified for detecting a Web cache poisoning vulnerability to obtain multiple mutated attack requests.

[0113] Specifically, after detecting the cache keys, HTTP standard requests to be verified are generated for vulnerability testing based on these cache keys, and mutation tests are performed on the standard requests to be verified. According to different mutation tests, the standard to be verified can generate a large number of mutated attack requests for subsequent detection of potential cache poisoning requests.

[0114] As a possible implementation method, in some embodiments, multiple mutation tests are performed on the standard request to be verified for the Web cache poisoning vulnerability detection, including: based on a preset request line mutation strategy, performing a request line mutation on the standard request to be verified for the Web cache poisoning vulnerability detection to obtain a first attack request; based on a preset request header mutation strategy, performing a request header mutation on the standard request to be verified for the Web cache poisoning vulnerability detection to obtain a second attack request; based on a preset request body mutation strategy, performing a request body mutation on the standard request to be verified for the Web cache poisoning vulnerability detection to obtain a third attack request; based on a preset request length mutation strategy, performing a request length mutation on the standard request to be verified for the Web cache poisoning vulnerability detection to obtain a fourth attack request; and obtaining multiple mutated attack requests for the Web cache poisoning vulnerability detection according to the first attack request for the Web cache poisoning vulnerability detection, the second attack request for the Web cache poisoning vulnerability detection, the third attack request for the Web cache poisoning vulnerability detection, and the fourth attack request for the Web cache poisoning vulnerability detection.

[0115] Specifically, first, a standard request containing all cache keys is generated, and then multiple mutation tests are performed on the standard request, including request line mutation, request header mutation, request body mutation, and request length mutation. This step will generate a large number of different attack requests for subsequent detection.

[0116] For example, the mutation test proposed in the embodiment of the present invention may include: request line mutation, request header mutation, request body mutation and request length mutation, among which the request header mutation can be divided into two different mutation test methods, including: request header mutation, special request header mutation and filter field blacklist mutation. These mutation tests will be described in detail below in combination with specific embodiments.

[0117] Among them, Figure 4 As shown, Figure 4 This is a flow chart of a request line mutation algorithm provided according to a specific embodiment of the present invention. The request line mutation algorithm includes the following steps:

[0118] S401, start.

[0119] S402, input: URL, standard request.

[0120] S403, determine if i<parameter list length, if yes, execute step S404; if no, execute step S408.

[0121] S404, adding the i-th parameter to the standard request.

[0122] S405, determine if a cache poisoning attack is detected, if yes, execute step S406; if no, execute step S407.

[0123] S406. Add the poisoned request to the result and continue with S407.

[0124] S407. Execute i = i + 1.

[0125] S408. Output: The set of requests that can cause cache poisoning attacks.

[0126] S409. End.

[0127] Among them, as Figure 5 shown, Figure 5 is a flowchart of the request header mutation algorithm provided according to a specific embodiment of the present invention. The request header mutation algorithm includes the following steps:

[0128] S501. Start.

[0129] S502. Input: URL, standard request.

[0130] S503. Determine if i < the length of the header list. If so, execute step S504; if not, execute step S508.

[0131] S504. Add the i-th header to the standard request.

[0132] S505. Determine if a cache poisoning attack is detected. If so, execute step S506; if not, execute step S507.

[0133] S506. Add the poisoned request to the result and continue with S507.

[0134] S507. Execute i = i + 1.

[0135] S508. Output: The set of requests that can cause cache poisoning attacks.

[0136] S509. End.

[0137] Among them, as Figure 6 shown, Figure 6 is a flowchart of the special request header mutation algorithm provided according to a specific embodiment of the present invention. The special request header mutation algorithm includes the following steps:

[0138] S601. Start.

[0139] S602. Input: URL, standard request.

[0140] S603. Determine if i < the length of the RFC-specified header list. If so, execute step S604; if not, execute step S608.

[0141] S604, adding the i-th header and the specified value to the standard request.

[0142] S605, determine if a cache poisoning attack is detected, if yes, execute step S606; if no, execute step S607.

[0143] S606, adding the poisoned request to the result, and continuing to execute S607.

[0144] S607, execute i=i+1.

[0145] S608, output: a request set that can cause a cache poisoning attack.

[0146] S609, end.

[0147] Among them, Figure 7 As shown, Figure 7 This is a flow chart of a filter field blacklist mutation algorithm provided according to a specific embodiment of the present invention. The filter field blacklist mutation algorithm includes the following steps:

[0148] S701, start.

[0149] S702, input: URL, standard request.

[0150] S703, determine if i<blacklist filter field list length, if yes, execute step S704; if no, execute step S708.

[0151] S704, adding the i-th filtered field to the standard request.

[0152] S705, determine if a cache poisoning attack is detected, if yes, execute step S706; if no, execute step S707.

[0153] S706, add the poisoned request to the result, and continue to execute S707.

[0154] S707, execute i=i+1.

[0155] S708, output: a request set that can cause a cache poisoning attack.

[0156] S709, end.

[0157] Among them, Figure 8 As shown, Figure 8 This is a flow chart of a request body mutation algorithm provided according to a specific embodiment of the present invention. The request body mutation algorithm includes the following steps:

[0158] S801, start.

[0159] S802, input: URL, standard request.

[0160] S803, adding a request body to the standard request.

[0161] S804, determine if a cache poisoning attack is detected, if yes, execute step S805; if no, execute step S806.

[0162] S805, add the poisoned request to the result, and continue to execute S806.

[0163] S806, output: a request set that can cause a cache poisoning attack.

[0164] S807, end.

[0165] Among them, Fig. 9 As shown, Fig. 9 This is a flow chart of a request length variation algorithm provided according to a specific embodiment of the present invention. The request length variation algorithm comprises the following steps:

[0166] S901, start.

[0167] S902, input: URL, standard request.

[0168] S903, add a custom header to the standard request until the request length is greater than 8192 bytes.

[0169] S904, determine if a cache poisoning attack is detected, if yes, execute step S905; if no, execute step S906.

[0170] S905, add the poisoned request to the result, and continue to execute S906.

[0171] S906, output: a request set that can cause a cache poisoning attack.

[0172] S907, end.

[0173] According to the above process, the embodiment of the present invention generates HTTP attack requests to be tested based on different variation tests for different parts of HTTP requests, and searches for various utilization points that may cause cache poisoning attacks. The variation tests are specifically as follows:

[0174]

[0175]

[0176]

[0177] Using the detected cache key and the content obtained from traffic analysis, a request containing all cache keys is generated (line25,26), and the HTTP request parameters are tested and mutated for the request line of the HTTP request (line27-34). Some Web applications will obtain the HTTP request specified parameter value for subsequent program execution, such as obtaining the src field in the parameter to dynamically generate link information in JS. Therefore, when the intermediate cache server does not use the parameter as the cache key, but the back-end Web application uses the parameter to dynamically generate return information, a parameter-based cache poisoning attack is formed. This method collects a list of common parameters and uses these parameters as a dictionary to mutate the parameters of the HTTP request to detect cache poisoning attacks caused by parameter mutations. After generating the request, the cache poisoning attack verification function is called for verification.

[0178] For HTTP request headers (line 35-56), three methods are used to generate test cases for different types of headers.

[0179] Scan common HTTP request headers and special headers of various CDN vendors (line 36-42). Different cache servers often handle these headers differently. A common trick is to use forwarding headers (such as X-Forwarded-Host, X-Forwarded-Scheme, X-Forward-Port). These headers are often used to pass information to multi-hop HTTP servers in the Web request transmission path. When a cache server uses these fields for routing but does not add these fields to the cache key, it is easy to cause cache poisoning attacks. In addition, some Web applications obtain the Cookie field in the HTTP request to dynamically generate echo data. This behavior may also lead to cache poisoning attacks. Similarly, there may be a large number of other headers in the real world that will dynamically affect the cache results. This method collects common request headers on the Internet and uses these headers to mutate HTTP requests in turn, thereby testing the possible impact of different request headers on cache devices. After generating the request, call the cache poisoning attack verification function for verification.

[0180] For some HTTP request headers with special meanings specified in RFC, their values ​​have special requirements and need to meet certain specific formats. According to the formats of these headers and the values ​​specified in RFC, specific values ​​that meet the syntax specifications are generated for testing (line43-49). The generated values ​​include normal and valid values, values ​​that conform to the syntax but are prohibited or meaningless in RFC. These special values ​​are used for testing to avoid being directly filtered out when the value corresponding to a header is a random string. After generating the request, call the verification cache poisoning attack function for verification.

[0181] Add some common blacklist filter fields to the request header for testing (line50-56). Web application firewalls often configure some common filtering mechanisms to prevent malicious attacks from certain scanners or crawlers. For example, when they detect that the User-Agent is Sqlmap, they will directly return a 403 illegal access response. However, some cache servers do not use User-Agent as a cache key, which leads to cache poisoning attacks. This patent will explore the impact of some known Web security scanners (such as Nuclei, Acunetix) and web crawlers (CrazyWebCrawler, PyCurl) on the cache by defining a blacklist-based HTTP request mutation mechanism. In addition, some websites will also block jump links from phishing websites. Therefore, some well-known phishing website domain names are also used to detect the impact of malicious Referrer information on the cache. At the same time, some common key strings that will be blacklisted by application firewalls are also loaded, such as burpcollaborator.net, <script>alert(1)< / script> , system("ls"), etc., to detect the cache server's processing of requests containing filter fields. After generating the request, call the cache poisoning attack verification function for verification.

[0182] Test the HTTP request body (line57-61). Add a request body to the GET request. Generally speaking, a GET request should not contain an HTTP request body. Some HTTP services will trigger some additional abnormal behaviors when processing a GET header with a request body, such as returning a redirect response, a 400 error response, etc. On this basis, a rewrite method is introduced to expand the attack payload of such attacks, such as X-HTTP-Method-Override, X-HTTP-Method, and X-Method-Override. When the cache server transparently forwards such requests and the source server triggers an abnormal return due to the request, it is easy to cause a cache poisoning attack. After generating the request, call the cache poisoning attack verification function for verification.

[0183] Test the length of the HTTP request (line 62-66). The HTTP standard does not define the size of the HTTP request header, so intermediate systems, web servers, and web frameworks have their own regulations on size limits. Most web servers and proxies (Apache HTTPD) limit the size of the request header to about 8192 bytes to mitigate request header buffer overflows or ReDoS attacks. However, some other intermediate systems have restrictions that exceed this threshold. For example, Amazon Cloudfront CDN allows a size of 20480 bytes. Generate an overly long request and launch an attack through the request header size limit. After generating the request, call the verification cache poisoning attack function for verification.

[0184] In step S203, the multiple mutated attack requests are verified to obtain verification results, and the verification results are determined based on preset authentication conditions. If the verification results meet the preset authentication conditions, the attack requests are determined to be poisoned requests that can be exploited.

[0185] Specifically, a large number of attack requests to be tested are generated in step S202. The embodiment of the present invention first sends a standard request to obtain a normal response, then sends an attack request containing a cache destruction variable to obtain its abnormal response, and then compares the difference between the normal response and the abnormal response to determine whether there is a potential cache poisoning attack. If it is determined that there is a potential cache poisoning attack, the attack request containing the cache destruction variable is sent again to confirm its cache status (such as the value of the X-Cache header). If the cache hits and the responses are the same, the attack request is determined to be a poisoned request that can be exploited.

[0186] As a possible implementation method, in some embodiments, the verification result is determined based on preset authentication conditions, including: obtaining a first response according to the standard request to be verified, obtaining a second response according to the mutated attack request, and determining whether the first response and the second response are consistent; if the first response is inconsistent with the second response, obtaining a third response again according to the standard request to be verified, and determining whether the second response and the third response are consistent and whether the third response hits the cache key; if the second response and the third response are consistent and the third response hits the cache key of the Web cache server, determining that the attack request is a poisoned request that can be exploited.

[0187] Specifically, if Fig.10 As shown, Fig.10 This is a flow chart of a cache poisoning determination algorithm provided according to a specific embodiment of the present invention. The cache poisoning determination algorithm comprises the following steps:

[0188] S1001, start.

[0189] S1002, input: URL, poisoned request.

[0190] S1003, generate request 1.

[0191] S1004, send request 1, obtain response 1.

[0192] S1005, sending a poisoned request carrying cache destruction parameters, and obtaining response 2.

[0193] S1006, determine if response 1 ≠ response 2, if yes, execute step S1007; if no, execute step S1010.

[0194] S1007, sending request 1 carrying the same cache destruction parameters, and obtaining response 3.

[0195] S1008, determine if response 2 == response 3 and response 3 hits the cache, if yes, execute step S1009; if no, execute step S1010.

[0196] S1009, output: True, and execute S1011.

[0197] S1010, output: False, and execute S1011.

[0198] S1011, end.

[0199] For example, the embodiment of the present invention implements the detection of cache poisoning vulnerabilities by defining a function for determining whether a request will trigger cache poisoning, wherein the function for determining whether a request will trigger cache poisoning is as follows:

[0200]

[0201] The input of this function is the target URL and the generated HTTP request to be tested. First, a common HTTP basic request is generated based on expert knowledge and traffic analysis (line 17). Then, the request is sent to the URL to be tested to obtain a normal response (line 18). Then, the generated HTTP attack request is sent to the URL to be tested. A cache destruction variable needs to be added to the request, that is, a random parameter that is not included in normal user access is added to the path part of the request. The purpose is twofold. First, if the target URL has a cache poisoning vulnerability, the polluted cache will not affect the access of normal users. Second, in our test of different HTTP attack requests, different tests will not interfere with each other (line 19). By checking the difference between the response and the first normal response, it is determined whether a potential cache poisoning attack has occurred (line 20). The judgment of the attack mainly analyzes three types of information: 1. Whether the status code of the HTTP response has changed; 2. Whether the length of the HTTP response body has changed; 3. Whether the HTTP response contains specific content in the request. If one of the above situations occurs, it is determined that the target service may be threatened by a cache poisoning attack. At this point, a verification request is initiated to verify whether the cache poisoning vulnerability can be successfully exploited (line 21, 22). If the response received by the verification request is consistent with the response received by the attack request and the cache identification header in the response shows hit, it means that a cache poisoning attack has been discovered, and the judgment result of the cache poisoning attack is returned (line 23, 24).

[0202] Therefore, by obtaining the cache key of the Web cache server according to the cache detection algorithm, and generating a standard request and a mutated attack request according to the cache key, after sending the standard request and the mutated attack request and obtaining the corresponding server response, it is determined whether it is a poisoned request that can be exploited based on the response difference.

[0203] Optionally, in some embodiments, after determining that a Web cache poisoning vulnerability detection attack request is an exploitable poisoned request, the Web cache poisoning vulnerability detection further includes: generating a cache poisoning attack request set based on all Web cache poisoning vulnerability detection exploitable poisoned requests; and outputting the Web cache poisoning vulnerability detection cache poisoning attack request set.

[0204] Specifically, the embodiment of the present invention can define a function that saves the result after detecting a cache poisoning attack request, so as to generate a cache poisoning attack request set after detecting all cache poisoning attack requests and output the cache poisoning attack request set to the user.

[0205] For example, the function that saves the result after detecting a poisoned request that can be exploited is as follows:

[0206]

[0207]

[0208] When a poisoned request that can be exploited is detected, the function saves the detection result (line 68-93), and finally returns whether the URL has a cache poisoning vulnerability and the specific exploitable attack payload (line 94).

[0209] In order to enable those skilled in the art to further understand the Web cache poisoning vulnerability detection method according to the embodiment of the present invention, it is described in detail below in conjunction with specific embodiments.

[0210] Specifically, Fig.11 As shown, Fig.11 A system architecture diagram of a Web cache poisoning vulnerability detection method provided according to a specific embodiment of the present invention.

[0211] The system of the Web cache poisoning vulnerability detection method according to the embodiment of the present invention includes: cache key detection, test request generation and cache poisoning determination.

[0212] Among them, cache key detection includes:

[0213] (1) Basic request field hit detection.

[0214] (2) Generate specific request header enumeration.

[0215] Among them, the test request generation includes:

[0216] (3) Generate a standard HTTP request.

[0217] (4) HTTP request line variation.

[0218] (5)HTTP request header mutation.

[0219] (6)HTTP request body mutation.

[0220] (7) HTTP request length variation.

[0221] (8) Add cache busting variable generation request.

[0222] Among them, cache poisoning determination includes:

[0223] (9)Analysis of HTTP response status code differences.

[0224] (10)Analysis of HTTP response length differences.

[0225] (11) HTTP response content difference analysis.

[0226] According to the Web cache poisoning vulnerability detection method proposed in the embodiment of the present invention, different parts of the HTTP request are detected in sequence, and after the cache key is detected, a mutation test is performed on the request generated according to the cache key, and a request is sent to the server according to the attack request generated by the mutation test, and it is determined whether it is an exploitable poisoned request based on the difference in the obtained response. Therefore, by generating cache poisoning attack test cases covering various forms for different parts of the request, various types of cache poisoning attack vulnerabilities existing in the URL are comprehensively and systematically detected, avoiding various potential cache poisoning attacks and new cache poisoning attacks, and helping security personnel to better detect and protect against cache poisoning attacks on their own websites.

[0227] Next, a Web cache poisoning vulnerability detection device according to an embodiment of the present invention will be described with reference to the accompanying drawings.

[0228] Fig.12 The figure is a block diagram of a Web cache poisoning vulnerability detection device provided according to an embodiment of the present invention.

[0229] like Fig.12 As shown, the Web cache poisoning vulnerability detection device 10 includes: an acquisition module 100 , a mutation module 200 and a determination module 300 .

[0230] Wherein, the acquisition module 100 is used to obtain the cache key of the Web cache server;

[0231] The mutation module 200 is used to generate a standard request to be verified according to the cache key of the Web cache server, and perform multiple mutation tests on the standard request to be verified to obtain multiple mutated attack requests;

[0232] The determination module 300 is used to verify the multiple mutated attack requests to obtain verification results, and determine the verification results based on preset authentication conditions. If the verification results meet the preset authentication conditions, the attack request is determined to be a poisoned request that can be exploited.

[0233] According to one embodiment of the present invention, the acquisition module 100 is specifically used to: acquire HTTP traffic and RFC documents, and generate a standard HTTP request based on the HTTP traffic and the RFC documents; acquire multiple standard fields based on the standard HTTP request, and modify each standard field one by one to obtain multiple modified fields; and detect and obtain the cache key of the Web cache server based on the multiple standard fields and the multiple modified fields.

[0234] According to one embodiment of the present invention, the mutation module 200 is specifically used to: based on a preset request line mutation strategy, perform a request line mutation on the standard request to be verified to obtain a first attack request; based on a preset request header mutation strategy, perform a request header mutation on the standard request to be verified to obtain a second attack request; based on a preset request body mutation strategy, perform a request body mutation on the standard request to be verified to obtain a third attack request; based on a preset request length mutation strategy, perform a request length mutation on the standard request to be verified to obtain a fourth attack request; obtain multiple mutated attack requests according to the first attack request, the second attack request, the third attack request and the fourth attack request.

[0235] According to one embodiment of the present invention, the determination module 300 is specifically used to: obtain a first response according to the standard request to be verified, obtain a second response according to the mutated attack request, and determine whether the first response and the second response are consistent; if the first response is inconsistent with the second response, obtain a third response again according to the standard request to be verified, and determine whether the second response and the third response are consistent and whether the third response hits the cache key; if the second response and the third response are consistent and the third response hits the cache key of the Web cache server, determine that the attack request is a poisoned request that can be exploited.

[0236] According to an embodiment of the present invention, after determining that the attack request is an exploitable poisoned request, the determination module 300 is further used to: generate a cache poisoning attack request set based on all exploitable poisoned requests; and output the cache poisoning attack request set.

[0237] According to the Web cache poisoning vulnerability detection device proposed in the embodiment of the present invention, by detecting different parts of the HTTP request in sequence, after detecting the cache key, a mutation test is performed on the request generated according to the cache key, a request is sent to the server according to the attack request generated by the mutation test, and it is determined whether it is an exploitable poisoned request based on the difference in the obtained response. Therefore, by generating cache poisoning attack test cases covering various forms for different parts of the request, various types of cache poisoning attack vulnerabilities existing in the URL are comprehensively and systematically detected, avoiding various potential cache poisoning attacks and new cache poisoning attacks, and helping security personnel to better detect and protect against cache poisoning attacks on their own websites.

[0238] Fig.13 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. The electronic device may include:

[0239] A memory 1301 , a processor 1302 , and a computer program stored in the memory 1301 and executable on the processor 1302 .

[0240] When the processor 1302 executes the program, the Web cache poisoning vulnerability detection method provided in the above embodiment is implemented.

[0241] Furthermore, the electronic device further comprises:

[0242] The communication interface 1303 is used for communication between the memory 1301 and the processor 1302 .

[0243] The memory 1301 is used to store computer programs that can be executed on the processor 1302 .

[0244] The memory 1301 may include a high-speed RAM (Random Access Memory) memory, and may also include a non-volatile memory, such as at least one disk memory.

[0245] If the memory 1301, the processor 1302 and the communication interface 1303 are implemented independently, the communication interface 1303, the memory 1301 and the processor 1302 can be connected to each other through a bus and communicate with each other. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.13 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0246] Optionally, in a specific implementation, if the memory 1301, the processor 1302 and the communication interface 1303 are integrated on a chip, the memory 1301, the processor 1302 and the communication interface 1303 can communicate with each other through an internal interface.

[0247] The processor 1302 may be a CPU (Central Processing Unit), or an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of the present invention.

[0248] An embodiment of the present invention further provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the above-mentioned Web cache poisoning vulnerability detection method is implemented.

[0249] An embodiment of the present invention further provides a computer program product, including a computer program, which implements the above Web cache poisoning vulnerability detection method when executed by a processor.

[0250] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In the description of the present invention, the meaning of "plurality" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0251] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0252] Although the embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and are not to be construed as limitations of the present invention. A person skilled in the art may change, modify, replace and vary the above embodiments within the scope of the present invention.

Claims

1. A Web cache poisoning vulnerability detection method, characterized in that: The following steps are involved: Get the cache key of the web cache server; Generate a standard request to be verified according to the cache key of the Web cache server, and perform multiple mutation tests on the standard request to be verified to obtain multiple mutated attack requests; The multiple mutated attack requests are verified to obtain verification results, and the verification results are determined based on preset authentication conditions. If the verification results meet the preset authentication conditions, the attack requests are determined to be exploitable poisoned requests.

2. The method according to claim 1, characterized in that The step of obtaining the cache key of the Web cache server includes: Obtaining HTTP traffic and an RFC document, and generating a standard HTTP request according to the HTTP traffic and the RFC document; Acquire multiple standard fields according to the standard HTTP request, and modify each standard field one by one to obtain multiple modified fields; The cache key of the Web cache server is detected and obtained according to the multiple standard fields and the multiple modified fields.

3. The method according to claim 1, characterized in that: The multiple variation tests are performed on the standard request to be verified, including: Based on a preset request line mutation strategy, mutate the request line of the standard request to be verified to obtain a first attack request; Based on a preset request header mutation strategy, mutate the request header of the standard request to be verified to obtain a second attack request; Based on a preset request body mutation strategy, mutate the request body of the standard request to be verified to obtain a third attack request; Based on a preset request length variation strategy, performing a request length variation on the standard request to be verified to obtain a fourth attack request; The multiple mutated attack requests are obtained according to the first attack request, the second attack request, the third attack request, and the fourth attack request.

4. The method according to claim 1, characterized in that: The determining of the verification result based on the preset authentication condition includes: Obtain a first response according to the standard request to be verified, obtain a second response according to the mutated attack request, and determine whether the first response and the second response are consistent; If the first response is inconsistent with the second response, re-obtaining the third response according to the standard request to be verified, and determining whether the second response is consistent with the third response and whether the third response hits the cache key; If the second response is consistent with the third response and the third response hits the cache key of the Web cache server, the attack request is determined to be the exploitable poisoned request.

5. The method according to claim 1, characterized in that After determining that the attack request is a poisoned request that can be exploited, the method further includes: Based on all the exploitable poisoned requests, generating a cache poisoning attack request set; The cache poisoning attack request set is output.

6. A Web cache poisoning vulnerability detection device, characterized in that: The following steps are involved: The acquisition module is used to obtain the cache key of the Web cache server; A mutation module, used for generating a standard request to be verified according to the cache key of the Web cache server, and performing multiple mutation tests on the standard request to be verified to obtain multiple mutated attack requests; The determination module is used to verify the multiple mutated attack requests to obtain verification results, and determine the verification results based on preset authentication conditions. If the verification results meet the preset authentication conditions, the attack request is determined to be a poisoned request that can be exploited.

7. The device according to claim 6, characterized in that The acquisition module is specifically used for: Obtaining HTTP traffic and an RFC document, and generating a standard HTTP request according to the HTTP traffic and the RFC document; Acquire multiple standard fields according to the standard HTTP request, and modify each standard field one by one to obtain multiple modified fields; The cache key of the Web cache server is detected and obtained according to the multiple standard fields and the multiple modified fields.

8. An electronic device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the Web cache poisoning vulnerability detection method according to any one of claims 1 to 5.

9. A computer storage medium having a computer program stored thereon, characterized in that: The program is executed by a processor to implement the Web cache poisoning vulnerability detection method according to any one of claims 1 to 5.

10. A computer program product, characterized in that It comprises a computer program, which, when executed by a processor, is used to implement the Web cache poisoning vulnerability detection method according to any one of claims 1 to 5.

Images