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

Abstract

The present invention relates to a method, device, electronic device and medium for detecting Web cache poisoning vulnerabilities. The method comprises: obtaining a cache key of a Web cache server; generating a standard request to be verified based on 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; verifying the multiple mutated attack requests to obtain a verification result, and judging the verification result based on a preset authentication condition. If the verification result meets the preset authentication condition, the attack request is judged to be an exploitable poisoned request. Thus, 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 can be comprehensively and systematically detected, avoiding multiple 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.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a method, device, electronic device and medium for detecting a Web cache poisoning vulnerability. 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 then cached by the cache server, preventing the victim from properly retrieving the response. For example, an attacker can craft a malicious URL and exploit 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 related technologies, 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 urgently need to be solved. 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 in related technologies that detection of attack behaviors cannot detect potential vulnerabilities in the target system and is prone to missed detection errors. The method can comprehensively and systematically detect various types of cache poisoning attack vulnerabilities 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 objectives, 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 one 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 obtained by detecting the multiple standard fields and the multiple modified fields.

[0014] According to one 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 one embodiment of the present invention, determining the verification result based on the preset authentication condition includes:

[0021] 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;

[0022] If the first response is inconsistent with the second response, re-obtain a third response according to the standard request to be verified, and determine 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 one embodiment of the present invention, after determining that the attack request is a poisoned request that can be exploited, the method further includes:

[0025] Generating a cache poisoning attack request set based on all the exploitable poisoned requests;

[0026] Output the cache poisoning attack request set.

[0027] The Web cache poisoning vulnerability detection method proposed in an embodiment of the present invention sequentially detects different parts of an HTTP request. After detecting the cache key, a mutation test is performed on the request generated based on the cache key. The attack request generated by the mutation test is sent to the server, and the difference in the response obtained is used to determine whether it is an exploitable poisoned request. Thus, 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 better detect and protect against cache poisoning attacks on their own websites.

[0028] To achieve the above objectives, 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, configured to generate a standard request to be verified according to a 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;

[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 one embodiment of the present invention, the acquisition module is specifically configured 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 obtained by detecting the multiple standard fields and the multiple modified fields.

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

[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 one embodiment of the present invention, the determination module is specifically configured to:

[0043] 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;

[0044] If the first response is inconsistent with the second response, re-obtain a third response according to the standard request to be verified, and determine 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 one 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] Generating a cache poisoning attack request set based on all the exploitable poisoned requests;

[0048] Output the cache poisoning attack request set.

[0049] The Web cache poisoning vulnerability detection device proposed in an embodiment of the present invention sequentially detects different parts of an HTTP request, performs a mutation test on the request generated based on the cache key after detecting the cache key, sends a request to the server based on the attack request generated by the mutation test, and determines whether it is an exploitable poisoned request based on the difference in the response obtained. Thus, 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 better detect and protect against cache poisoning attacks on their own websites.

[0050] To achieve the above objectives, a third embodiment 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 embodiment 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 embodiment 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 set forth in part in the description which follows and, in part, will be obvious from the description which follows, or may 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 readily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

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

[0056] Figure 2 A flowchart of a method for detecting a Web cache poisoning vulnerability provided by one 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 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] Figure 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] Figure 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] Figure 11 A system architecture diagram of a Web cache poisoning vulnerability detection method according to a specific embodiment of the present invention;

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

[0067] Figure 13 A schematic structural diagram 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] The following describes embodiments of the present invention in detail. Examples of the embodiments 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 explain the present invention, but are not to be construed as limiting the present invention.

[0070] The following describes a Web cache poisoning vulnerability detection method, device, electronic device, and medium according to embodiments of the present invention with reference to the accompanying drawings.

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

[0072] Specifically, if Figure 1 As shown, Figure 1 This diagram illustrates the principles of cache hit and cache poisoning attacks. A cache hit occurs when a client requests a request with the same cache key as a previous request, and the corresponding web resource object is available in the cache. The cache device directly returns the cached resource. If the cache misses, the cache device retrieves the resource from the backend origin server and returns it to the client. Furthermore, the cache device typically caches the resource based on the web resource cache time set by the origin server. Obviously, the higher the cache hit rate, the greater the network performance acceleration achieved by the cache device. A cache key corresponds to each web resource object in the cache, serving as a unique identifier for the web resource object in the cache. According to RFCs and implementations by major web application vendors, a cache key typically consists of the request method, request host name, and request URI. However, different web application vendors may utilize other headers as cache keys to implement additional functionality. A cache poisoning attack exploits differences in request processing between a network cache and the origin server, tricking the server into generating an erroneous response that is then cached by the cache server, preventing the victim from properly retrieving the response. The diagram illustrates the basic model of a cache poisoning attack, which typically involves four steps:

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

[0074] (2) The cache server fails to 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 resource on the cache server, thus being attacked.

[0077] Based on the above principles, it's clear that a cache hit, or a cache key match, is crucial for a successful cache poisoning attack. Therefore, detecting cache poisoning first requires determining which fields in the HTTP request comprise the cache key. Subsequently, during cache poisoning testing, cache poisoning attacks can be detected by sending requests with the same cache key and determining whether the responses triggered by different requests are consistent. In summary, detecting cache poisoning attacks requires first identifying which fields in the HTTP request constitute a cache key, allowing for more efficient subsequent testing.

[0078] Therefore, an embodiment of the present invention proposes a Web cache poisoning vulnerability detection method. In this method, different parts of an HTTP request are detected in sequence. After the cache key is detected, a mutation test is performed on the request generated based on the cache key. The attack request generated by the mutation test is sent to the server, and the difference in the obtained response is used to determine whether it is an exploitable poisoned request. This solves the problem in the related art that detecting attack behavior cannot detect potential vulnerabilities in the target system and is prone to missed detection errors. 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 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, a cache key is a unique identifier used to determine whether the resource requested by the user hits the edge cache content. Therefore, an embodiment of the present invention proposes a universal cache detection algorithm, which detects whether different parts of the HTTP request are cache keys in turn, and judges the header list of the HTTP request in turn to ensure that various different headers are covered and 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; obtaining the cache key of the Web cache poisoning vulnerability detection Web cache server based on the multiple standard fields of the Web cache poisoning vulnerability detection and the multiple modified fields of the Web cache poisoning vulnerability detection.

[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 HTTP traffic and RFC documents, 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, if 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 includes 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 line i in request 1.

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

[0093] S308, judging if response 1 ≠ response 2 and the cache identification header of response 2 == miss, if yes, executing step S309; ​​if not, executing 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, obtain response 3.

[0099] S314: Add 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 not, execute step S317.

[0101] S316: Add 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 (line 2-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, 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 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 values. Send the modified request 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 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). By checking the header list consisting of all common headers collected and specific headers of different CDNs and different servers one by one, the headers in the list are added to the standard headers one by one, and the request with the new header added is sent to obtain 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 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 the cache key of the Web cache server for Web cache poisoning vulnerability detection, and multiple mutation tests are performed on the standard request to be verified for Web cache poisoning vulnerability detection 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, mutating the request line of 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, mutating the request header of 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, mutating the request body of 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, mutating the request length of 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 based on 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 them, the request header mutation can be divided into two different mutation testing methods, including: request header mutation, special request header mutation and filter field blacklist mutation. These mutation tests will be explained in detail below in combination with specific embodiments.

[0117] Among them, such as 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: Add the i-th parameter to the standard request.

[0122] S405, determine if a cache poisoning attack is detected, if yes, execute step S406; if not, 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, Judge 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, Judge 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, Judge if i < the length of the RFC-specified header list. If so, execute step S604; if not, execute step S608.

[0141] S604: Add 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 not, execute step S607.

[0143] S606: Add the poisoned request to the result, and continue 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 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, judging if i < blacklist filter field list length, if yes, executing step S704; if no, executing step S708.

[0151] S704: Add 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 not, 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: Add a request body to the standard request.

[0161] S804, determine if a cache poisoning attack is detected, if yes, execute step S805; if not, 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, such as Figure 9 As shown, Figure 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 includes 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 not, 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 mutation tests for different parts of the HTTP request, and searches for various exploit points that may cause cache poisoning attacks. The mutation tests are specifically as follows:

[0174]

[0175]

[0176]

[0177] Using the detected cache keys and the content obtained from traffic analysis, a request containing all cache keys is generated (lines 25, 26). The HTTP request parameters are tested and mutated for the request lines (lines 27-34) of the HTTP request. Some web applications obtain the value of the HTTP request-specified parameters 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 a 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 as well as those specific to each CDN vendor (lines 36-42). Different cache servers often handle these headers differently. A common technique is to utilize forwarding headers (such as X-Forwarded-Host, X-Forwarded-Scheme, and X-Forwarded-Port). These headers are often used to convey information to multiple HTTP servers along the web request transmission path. When a cache server uses these fields for routing but fails to include them in the cache key, cache poisoning attacks can easily occur. Furthermore, some web applications extract the Cookie field from HTTP requests to dynamically generate echo data. This behavior can also lead to cache poisoning attacks. Similarly, in the real world, there may be numerous other headers that can dynamically influence cache results. This method collects common request headers from the internet and uses them sequentially to mutate HTTP requests, thereby testing the potential impact of different request headers on cache devices. After generating a request, the cache poisoning attack verification function is called for verification.

[0180] Some HTTP request headers with special meanings specified in the RFC have special requirements for their values ​​and must meet certain specific formats. Based on these headers and the format of the values ​​specified in the RFC, specific values ​​that meet the grammatical specifications are generated for testing (lines 43-49). The generated values ​​include normal and valid values, as well as values ​​that are grammatically correct but prohibited or meaningless in the RFC. These special values ​​are used for testing to prevent random string values ​​from being directly filtered out. After generating the request, the cache poisoning attack verification function is called 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 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 handling of requests containing filter fields. After generating the request, call the cache poisoning attack verification function for verification.

[0182] Test the HTTP request body (line 57-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 the GET header with a request body, such as returning a redirect response, a 400 error response, etc. On this basis, rewriting methods are 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 (lines 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 request header size to approximately 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 by exploiting the request header size limit. After generating the request, call the cache poisoning attack verification 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 request is determined to be a poisoned request that can be exploited.

[0185] Specifically, in step S202, a large number of attack requests to be tested are generated. In the embodiment of the present invention, a standard request is first sent to obtain a normal response, and then an attack request containing a cache destruction variable is sent to obtain its abnormal response. Then, the difference between the normal response and the abnormal response is compared 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 response is 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 based on the standard request to be verified, obtaining a second response based on 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 based on 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 Figure 10 As shown, Figure 10 This is a flow chart of a cache poisoning determination algorithm according to a specific embodiment of the present invention. The cache poisoning determination algorithm includes 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: Send a poisoned request carrying cache destruction parameters and obtain response 2.

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

[0194] S1007: Send request 1 with the same cache destruction parameters and obtain response 3.

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

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

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

[0198] S1011, end.

[0199] For example, an embodiment of the present invention implements cache poisoning vulnerability detection by defining a function for determining whether a request triggers cache poisoning. The function for determining whether a request triggers cache poisoning is specifically as follows:

[0200]

[0201] The function takes as input the target URL and the generated HTTP request to be tested. First, based on expert knowledge and traffic analysis, a common basic HTTP request is generated (line 17). This request is then sent to the URL to be tested, obtaining a normal response (line 18). The generated attack HTTP request is then sent to the URL to be tested. This request adds a cache-busting variable—a random parameter that is not present in normal user access—to the path portion of the request. This serves two purposes: first, if the target URL is vulnerable to cache poisoning, the contaminated cache will not affect normal user access; second, when testing different HTTP attack requests, different tests will not interfere with each other (line 19). By examining the difference between this response and the first normal response, we determine whether a potential cache poisoning attack has occurred (line 20). Attack detection primarily analyzes three types of information: 1. Whether the HTTP response status code has changed; 2. Whether the HTTP response body length has changed; and 3. Whether the HTTP response contains the specific content from the request. If any of these conditions occur, the target service is considered vulnerable to a cache poisoning attack. At this point, a verification request is initiated to verify whether the cache poisoning vulnerability can be successfully exploited (lines 21, 22). If the response received from the verification request is consistent with the response received from 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 cache poisoning attack judgment result is returned (lines 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 based on 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 results after detecting a poisoned request that can be exploited is as follows:

[0206]

[0207]

[0208] Among them, when a poisoned request that can be exploited is detected, the function will save the detection results (line68-93), and finally return whether the URL has a cache poisoning vulnerability and the specific exploitable attack payload (line94).

[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 with reference to specific embodiments.

[0210] Specifically, if Figure 11 As shown, Figure 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 enumeration of specific request headers.

[0215] Among them, 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 to generate request.

[0222] 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] The Web cache poisoning vulnerability detection method proposed in an embodiment of the present invention sequentially detects different parts of an HTTP request. After detecting the cache key, a mutation test is performed on the request generated based on the cache key. The attack request generated by the mutation test is sent to the server, and the difference in the response obtained is used to determine whether it is an exploitable poisoned request. Thus, 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 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] Figure 12 4 is a block diagram of a Web cache poisoning vulnerability detection device provided according to an embodiment of the present invention.

[0229] like Figure 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: obtain HTTP traffic and RFC documents, and generate a standard HTTP request based on the HTTP traffic and RFC documents; obtain multiple standard fields based on the standard HTTP request, and modify each standard field one by one to obtain multiple modified fields; and obtain a 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; and obtain multiple mutated attack requests based on 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 one embodiment of the present invention, after determining that the attack request is an exploitable poisoned request, the determination module 300 is further configured to: generate a cache poisoning attack request set based on all exploitable poisoned requests; and output the cache poisoning attack request set.

[0237] The Web cache poisoning vulnerability detection device proposed in an embodiment of the present invention sequentially detects different parts of an HTTP request, performs a mutation test on the request generated based on the cache key after detecting the cache key, sends a request to the server based on the attack request generated by the mutation test, and determines whether it is an exploitable poisoned request based on the difference in the response obtained. Thus, 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 better detect and protect against cache poisoning attacks on their own websites.

[0238] Figure 13 This is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. The electronic device may include:

[0239] Memory 1301 , processor 1302 , and computer programs 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 includes:

[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 run 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 via 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. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 13 Only one thick line is used in the diagram, but this does not mean that there is only one bus or 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 storing a computer program, which, when executed by a processor, implements the above-mentioned Web cache poisoning vulnerability detection method.

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

[0250] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of the technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "plurality" means at least two, such as two, three, etc., unless otherwise specifically defined.

[0251] In the description of this specification, the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" mean 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 do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification and features of different embodiments or examples without contradiction.

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

Claims

1. A method for detecting a Web cache poisoning vulnerability, 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; Verifying the multiple mutated attack requests to obtain verification results, and determining the verification results based on preset authentication conditions, and if the verification results meet the preset authentication conditions, determining that the attack request is an exploitable poisoned request; The determining of the verification result based on the preset authentication conditions includes: 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, re-obtain a third response according to the standard request to be verified, and determine 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.

2. The method according to claim 1, characterized in that 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 obtained by detecting the multiple standard fields and the multiple modified fields.

3. The method according to claim 1, characterized in that The multiple variation tests on the standard request to be verified include: 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, wherein After determining that the attack request is a poisoned request that can be exploited, the method further includes: Generating a cache poisoning attack request set based on all the exploitable poisoned requests; Output the cache poisoning attack request set.

5. 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, configured to generate a standard request to be verified according to a 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; a determination module, configured to verify the multiple mutated attack requests to obtain verification results, and determine the verification results based on preset authentication conditions, and if the verification results meet the preset authentication conditions, determine that the attack request is an exploitable poisoned request; The determining of the verification result based on the preset authentication conditions includes: 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, re-obtain a third response according to the standard request to be verified, and determine 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.

6. The device according to claim 5, characterized in that The acquisition module is specifically used to: 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 obtained by detecting the multiple standard fields and the multiple modified fields.

7. 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 4.

8. 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 4.

9. A computer program product, characterized in that The method 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 4.

Images