Client HTTP request smuggling vulnerability detection method

Abstract

The embodiment of the invention relates to the technical field of vulnerability detection, and provides a client HTTP request smuggling vulnerability detection method comprising the following steps: sending an abnormal HTTP request to a target test system; according to a request response fed back by the target test system, judging whether the target test system meets a necessary condition for forming a client HTTP request smuggling vulnerability or not; and when the target test system meets the necessary conditions for forming the client HTTP request smuggling vulnerability, performing client HTTP request smuggling vulnerability recheck verification based on the actual application scene to obtain a detection result of the target test system. According to the embodiment of the invention, the defects of the existing HTTP request smuggling vulnerability detection method are overcome, the rapid preliminary detection of the existence of the HTTP request smuggling vulnerability of the client can be realized, the detection efficiency is relatively high, and the detection accuracy can be further improved.

Description

Technical Field

[0001] The present disclosure relates to the technical field of vulnerability detection, and in particular to a method for detecting a client HTTP request smuggling vulnerability. Background Art

[0002] WEB systems usually use a client / server (C / S) architecture and complete data requests and responses between clients and servers based on the HyperText Transfer Protocol (HTTP). HTTP request smuggling vulnerabilities refer to a type of vulnerability in which the application server incorrectly parses the application client request and parses the HTTP request body content into the request header, resulting in an unexpected response.

[0003] HTTP request smuggling vulnerabilities usually occur between the application front-end server and the application back-end server. The application front-end server refers to any intermediate server with request forwarding function, such as reverse proxy server, WEB application firewall, etc. The application back-end server refers to the server that completes the business request. Different types of servers may have different ways of parsing HTTP requests, which may lead to HTTP request smuggling and create more serious security risks. This type of HTTP request smuggling vulnerability occurs between the application front-end and back-end servers, so it is also called the server-side HTTP request smuggling vulnerability.

[0004] Currently, the existing technology has proposed many detection methods for the HTTP request smuggling vulnerability problem, but these methods can only detect the HTTP request smuggling vulnerability on the server side, that is, they can only detect the HTTP request smuggling vulnerability on the WEB application that deploys both the front-end server and the back-end server.

[0005] However, in reality, a large number of WEB applications do not have a front-end server as a request forwarding node, and business requests and responses are completed directly between the application client (browser) and the application backend. This type of application deployment model also has HTTP request smuggling vulnerabilities, which are usually called client HTTP request smuggling vulnerabilities. Due to the differences in the specific causes of client HTTP request smuggling vulnerabilities and server HTTP request smuggling vulnerabilities, the detection method for server HTTP request smuggling vulnerabilities is difficult to apply to the detection of client HTTP request smuggling vulnerabilities, which makes how to detect client HTTP request smuggling vulnerabilities an urgent problem to be solved in this field. Summary of the invention

[0006] The present disclosure aims to solve at least one of the problems existing in the prior art and provide a method for detecting a client HTTP request smuggling vulnerability.

[0007] In one aspect of the present disclosure, a method for detecting a client HTTP request smuggling vulnerability is provided, the detection method comprising:

[0008] Send abnormal HTTP requests to the target test system;

[0009] According to the request response fed back by the target test system, determine whether the target test system meets the necessary conditions for the formation of the client HTTP request smuggling vulnerability;

[0010] When the target test system meets the necessary conditions for forming a client HTTP request smuggling vulnerability, a client HTTP request smuggling vulnerability review and verification is performed based on an actual application scenario to obtain a detection result of the target test system.

[0011] Optionally, sending the abnormal HTTP request to the target test system includes:

[0012] Access the target test system normally, and capture the corresponding HTTP request message as a normal HTTP request;

[0013] Constructing a plurality of abnormal HTTP requests according to the normal HTTP request;

[0014] All the abnormal HTTP requests are replayed to the target test system. During the replay process, each time an abnormal HTTP request is replayed, a corresponding normal HTTP request is replayed, and each abnormal HTTP request is in the same connection as the corresponding normal HTTP request.

[0015] Optionally, constructing a plurality of abnormal HTTP requests according to the normal HTTP request includes:

[0016] Modification step: modifying the request header and request body of the normal HTTP request to obtain the abnormal HTTP request;

[0017] Repeat the modification step multiple times to obtain corresponding multiple abnormal HTTP requests.

[0018] Optionally, the modifying the request header and request body of the normal HTTP request includes:

[0019] The content format of the request body is modified, and the request method, URL field and Content-length field in the request header of the normal HTTP request are modified.

[0020] Optionally, the modifying the content format of the request body and modifying the request method, URL field and Content-length field in the request header of the normal HTTP request includes:

[0021] Add "GET / 404HTTP / 1.1" to the beginning of the request body, and add "TEST:TEST" to the end of the request body;

[0022] Change the request method to POST;

[0023] Adding special characters to the URL field to make the URL field invalid, or filling the URL field with arbitrary characters to make the length of the URL field exceed a preset length, or replacing the URL field with a static file address;

[0024] Modify the value of the Content-length field so that the modified value of the Content-length field is greater than the modified length of the request body.

[0025] Optionally, judging whether the target test system meets the necessary conditions for forming a client HTTP request smuggling vulnerability according to the request response fed back by the target test system includes:

[0026] During the replay process, if all the normal HTTP requests cannot obtain normal responses from the target test system, then the target test system meets the necessary conditions for forming a client HTTP request smuggling vulnerability.

[0027] Optionally, the client HTTP request smuggling vulnerability review and verification based on the actual application scenario to obtain the detection result of the target test system includes:

[0028] Replaying, using a browser, the normal HTTP request to which the target test system fails to respond normally during the replay process and the corresponding abnormal HTTP request;

[0029] Check, through the developer tool, whether the response of the normal HTTP request replayed this time is affected by the response of the corresponding abnormal HTTP request and whether the connection ID of the normal HTTP request replayed this time is the same as the connection ID of the corresponding abnormal HTTP request;

[0030] If the response to the normal HTTP request is affected by the response to the corresponding abnormal HTTP request and the connection ID of the normal HTTP request is the same as the connection ID of the corresponding abnormal HTTP request, the detection result is that the target test system has a client HTTP request smuggling vulnerability.

[0031] Another aspect of the present disclosure provides a detection device for a client HTTP request smuggling vulnerability, the detection device comprising:

[0032] The sending module is used to send abnormal HTTP requests to the target test system;

[0033] A judgment module, used to judge whether the target test system meets the necessary conditions for forming a client HTTP request smuggling vulnerability according to the request response fed back by the target test system;

[0034] The verification module is used to perform a review and verification of the client HTTP request smuggling vulnerability based on an actual application scenario when the target test system meets the necessary conditions for forming a client HTTP request smuggling vulnerability, and obtain a detection result of the target test system.

[0035] Another aspect of the present disclosure provides an electronic device, including:

[0036] at least one processor; and,

[0037] a memory communicatively connected to at least one processor; wherein,

[0038] The memory stores instructions that can be executed by at least one processor, and the instructions are executed by at least one processor so that the at least one processor can execute the detection method of the client HTTP request smuggling vulnerability recorded above.

[0039] Another aspect of the present disclosure provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method for detecting the client HTTP request smuggling vulnerability described above.

[0040] Compared with the prior art, the present disclosure makes up for the shortcomings of the existing HTTP request smuggling vulnerability detection method, and can achieve rapid preliminary detection of the existence of the client HTTP request smuggling vulnerability based on the necessary conditions for the formation of the client HTTP request smuggling vulnerability. It has high detection efficiency and can further improve the accuracy of detection by reviewing and verifying the client HTTP request smuggling vulnerability based on actual application scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplifications do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0042] Figure 1 A flowchart of a method for detecting a client HTTP request smuggling vulnerability provided by an embodiment of the present disclosure;

[0043] Figure 2A schematic diagram of a method for detecting a client HTTP request smuggling vulnerability provided by another embodiment of the present disclosure;

[0044] Figure 3 A schematic diagram of a request message for an abnormal request provided by another embodiment of the present disclosure;

[0045] Figure 4 A schematic diagram of response results of a target test system provided by another embodiment of the present disclosure;

[0046] Figure 5 A schematic diagram of the structure of a detection device for a client HTTP request smuggling vulnerability provided by another embodiment of the present disclosure;

[0047] Figure 6 A schematic structural diagram of an electronic device provided in another embodiment of the present disclosure. DETAILED DESCRIPTION

[0048] In order to make the purpose, technical scheme and advantages of the embodiments of the present disclosure clearer, the embodiments of the present disclosure will be described in detail below in conjunction with the accompanying drawings. However, it can be understood by those skilled in the art that in each embodiment of the present disclosure, many technical details are proposed in order to enable readers to better understand the present disclosure. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed for protection in the present disclosure can also be implemented. The division of the following embodiments is for the convenience of description and should not constitute any limitation on the specific implementation of the present disclosure. The various embodiments can be combined and referenced with each other without contradiction.

[0049] An embodiment of the present disclosure relates to a method for detecting a client HTTP request smuggling vulnerability. The method takes the basic occurrence principle of the client HTTP smuggling vulnerability as the starting point, constructs an abnormal HTTP request to perform a preliminary investigation on the vulnerability of the target test system, and then reviews and verifies the vulnerability based on the actual application scenario according to the preliminary investigation result, thereby realizing the detection of the client HTTP request smuggling vulnerability.

[0050] like Figure 1 As shown, the method for detecting the client HTTP request smuggling vulnerability provided by this embodiment includes the following steps:

[0051] Step S110: sending an abnormal HTTP request to the target test system.

[0052] Specifically, the target test system here can be the server of any WEB application that needs to perform client HTTP request smuggling vulnerability detection.

[0053] Exemplary, combined Figure 2, step S110 may include the following sub-steps:

[0054] Step 1.1, access the target test system normally, and capture the corresponding HTTP request message as a normal HTTP request. Specifically, step 1.1 can use BurpSutie, an integrated platform for attacking web applications, to capture the HTTP request message. Of course, those skilled in the art can also use other tools to capture HTTP request messages, and this embodiment does not limit this.

[0055] Step 1.2, construct multiple abnormal HTTP requests according to normal HTTP requests. Specifically, step 1.2 can construct abnormal HTTP requests according to normal HTTP requests by modifying request headers and request bodies based on the HTTP request messages captured in step 1.1. In this case, step 1.2 can further include steps 1.2.1 and 1.2.2.

[0056] Step 1.2.1, modification step: modify the request header and request body of a normal HTTP request to obtain an abnormal HTTP request, wherein modifying the request header and request body of a normal HTTP request includes: modifying the content format of the request body, and modifying the request method, URL field, and Content-length field in the request header of the normal HTTP request.

[0057] Specifically, modify the content format of the request body, including: adding "GET / 404HTTP / 1.1" at the beginning of the request body, and adding "TEST:TEST" at the end of the request body. That is, modify the request body content in a normal HTTP request to the following format:

[0058] GET / 404HTTP / 1.1

[0059] TEST:TEST

[0060] Modify the request method in the request header of a normal HTTP request, specifically: change the request method to POST. That is, change the GET method in the request header of a normal HTTP request to the POST method.

[0061] Modify the URL field in the request header of a normal HTTP request, specifically: add special characters to the URL field to invalidate the URL field, for example, add / %2e%2e to the URL field of a normal HTTP request to invalidate the modified URL field. Alternatively, use any characters to fill the URL field to make the length of the URL field exceed the preset length, for example, add an overlong string aaaaaaaaaaaaaaaaaaaaaaa... after the URL field http: / / example.com / of a normal HTTP request to make the length of the modified URL field http: / / example.com / aaaaaaaaaaaaaaaaaaaaa... too long to exceed the preset length. Alternatively, replace the URL field with a static file address, for example, replace the URL field http: / / example.com / of a normal HTTP request with the static file address / robots.txt.

[0062] Modify the value of the Content-length field so that the value of the modified Content-length field is greater than the length of the modified request body. For example, when the length of the modified request body is 80, the value of the Content-length field in the normal HTTP request can be modified to 100, so that the value of the modified Content-length field is greater than the length of the modified request body.

[0063] Step 1.2.2, repeat the modification step multiple times, that is, repeat step 1.2.1 multiple times, to obtain corresponding multiple abnormal HTTP requests.

[0064] Step 1.3, replay all abnormal HTTP requests to the target test system. During the replay process, each abnormal HTTP request is replayed together with a corresponding normal HTTP request, that is, the abnormal HTTP request and its corresponding normal HTTP request are sent to the target test system at the same time, and each abnormal HTTP request is in the same connection as the corresponding normal HTTP request.

[0065] Specifically, during the replay process, step 1.3 needs to ensure that each abnormal HTTP request and its corresponding normal HTTP request are completed in the same connection, so as to cause the target test server to generate anomalies as much as possible.

[0066] It should be noted that in step 1.2.1, when modifying the request header, only the request method, URL field, and Content-length field in the request header are modified. This is because browsers have strict restrictions on HTTP cross-domain requests. Modifying other fields in the request body will cause the cross-domain request to fail, making the target test system unable to meet cross-domain access, which is one of the necessary conditions for the formation of the client HTTP request smuggling vulnerability.

[0067] Step S120, judging whether the target test system meets the necessary conditions for forming the client HTTP request smuggling vulnerability according to the request response fed back by the target test system.

[0068] Specifically, the purpose of step S120 is to quickly determine whether the target test system may have a client HTTP request smuggling vulnerability. The necessary conditions for the formation of a client HTTP request smuggling vulnerability usually include two: one is that the request to the target test system must support cross-domain access, and the other is that the target test system may ignore the Content-Length field in the request when responding to the request. Therefore, the core process of step S120 is to determine whether the abnormal HTTP request will affect the corresponding normal HTTP request. If the abnormal HTTP request affects the corresponding normal HTTP request, it means that the target test system will ignore the Content-Length field of the HTTP request under certain circumstances, thereby satisfying the necessary conditions for the formation of a client HTTP request smuggling vulnerability. If the abnormal HTTP request does not affect the corresponding normal HTTP request, it means that the target test system does not meet the necessary conditions for the formation of a client HTTP request smuggling vulnerability. Therefore, the purpose of step S110 sending an abnormal HTTP request to the target test system is to cause the target test server to generate an exception as much as possible, thereby ignoring the Content-Length field.

[0069] Exemplarily, step S120 includes: during the replay process, if all normal HTTP requests cannot obtain normal responses from the target test system, then the target test system meets the necessary conditions for forming a client HTTP request smuggling vulnerability.

[0070] Specifically, combined with Figure 2 , step S120 collects and analyzes the request response content fed back by the target test system, parses and detects the request response content, preliminarily determines the existence of the client HTTP request smuggling vulnerability, and determines whether the target test system may have a vulnerability. Among them, during the replay process, if all normal HTTP requests can be responded to normally by the target test system, it is determined that the target test system is unlikely to have a client HTTP request smuggling vulnerability, otherwise it is preliminarily determined that the target test system may have a client HTTP request smuggling vulnerability.

[0071] Step S130, when the target test system meets the necessary conditions for forming the client HTTP request smuggling vulnerability, the client HTTP request smuggling vulnerability is reviewed and verified based on the actual application scenario to obtain the detection result of the target test system.

[0072] Specifically, the purpose of step S130 is to simulate the real behavior of the user. Figure 2 In step S130, when the target test system meets the necessary conditions for forming a client HTTP request smuggling vulnerability, that is, a vulnerability may exist, the vulnerability can be reviewed and verified in an actual application scenario, that is, the client HTTP request smuggling vulnerability can be reviewed and verified using a browser to ensure the effectiveness and feasibility of vulnerability detection.

[0073] Exemplarily, in step S130, the client HTTP request smuggling vulnerability is reviewed and verified based on the actual application scenario to obtain the detection result of the target test system, including step 3.1 and step 3.2.

[0074] Step 3.1, using a browser to replay the normal HTTP requests and their corresponding abnormal HTTP requests that the target test system fails to respond to normally during the replay process. Specifically, step 3.1 can use a browser to replay the normal HTTP requests and their corresponding abnormal HTTP requests that fail to obtain a normal response from the target test system in step S120.

[0075] Step 3.2, through the developer tool, check whether the response of the normal HTTP request replayed this time is affected by the response of the corresponding abnormal HTTP request and whether the connection ID of the normal HTTP request replayed this time is the same as the connection ID of the corresponding abnormal HTTP request. If the response of the normal HTTP request is affected by the response of the corresponding abnormal HTTP request and the connection ID of the normal HTTP request is the same as the connection ID of the corresponding abnormal HTTP request, the detection result is that the target test system has a client HTTP request smuggling vulnerability.

[0076] Specifically, the connection ID here refers to the connection identifier. If the connection ID of a normal HTTP request is the same as the connection ID of the corresponding abnormal HTTP request, it means that the normal HTTP request and the corresponding abnormal HTTP request are in the same connection. At this time, if the response of the abnormal HTTP request affects the response of the normal HTTP request, it can be determined that the target test system has a client HTTP request smuggling vulnerability.

[0077] Compared with the prior art, the detection of the client HTTP request smuggling vulnerability provided by the embodiment of the present disclosure makes up for the shortcomings of the existing HTTP request smuggling vulnerability detection method. Based on the necessary conditions for the formation of the client HTTP request smuggling vulnerability, it can achieve rapid preliminary detection of the existence of the client HTTP request smuggling vulnerability, has high detection efficiency, and can further improve the accuracy of detection by reviewing and verifying the client HTTP request smuggling vulnerability based on actual application scenarios.

[0078] In order to enable those skilled in the art to better understand the above implementation, a specific example is used as an example for description below.

[0079] A method for detecting a client HTTP request smuggling vulnerability comprises the following steps:

[0080] Step 1: Access the target test system normally and use BurpSutie to capture the HTTP request package.

[0081] Step 2: Send the captured HTTP request packet twice to the Repeater module of BurpSutie to obtain two request packets that need to be replayed.

[0082] Step 3: Add the two request packets that need to be replayed into the same group, and change the names of the two request packets to abnormal request and normal request respectively.

[0083] Step 4: Modify the request body in the abnormal request and the request method, URL field, and Content-length field in the request header. Finally, the request message corresponding to the abnormal request is as follows: Figure 3 shown.

[0084] Step 5: Use the replay module to replay the abnormal request and normal request to the target test system. During the replay process, enable the option to send sequence requests in the same connection so that the abnormal request and normal request are in the same connection, and turn off the automatic update Content-length option of BurpSutie.

[0085] Step 6: If the response to the normal request is a 404 page, execute step 7; otherwise, re-execute steps 4 to 6, and construct an abnormal request in other ways during the execution of step 4.

[0086] Step 7, open the browser developer tools, and use JS (JavaScript) scripts in the console to simulate the verification process of the client HTTP request smuggling vulnerability. The script content includes: fetch function is used to simulate abnormal requests, then function is used to simulate normal requests, and mode:no-cors is used to display the connection ID. The script content can be specifically expressed as:

[0087] fetch('http: / / 127.0.0.1:8081',{

[0088] method:'POST',

[0089] body:"GET / 404HTTP / 1.1\r\nX:Y",

[0090] mode:'no-cors',

[0091] }).then(()=>{

[0092] location='http: / / 127.0.0.1:8081'

[0093] })

[0094] Step 8: Check the response from the target test system in the network option of the developer tool. If the response to the normal request is 404 and the connection ID is the same as the connection ID of the abnormal request, it is determined that the target test system has a client HTTP request smuggling vulnerability. Otherwise, it is determined that the target test system does not have a client HTTP request smuggling vulnerability. Figure 4 As shown in the figure, if the connection ID of the normal request is the same as the connection ID of the abnormal request, but the normal request can obtain a normal response from the target test system and is not affected by the malicious data "GET / 404HTTP / 1.1\r\nX:Y" carried by the abnormal request, it indicates that the target test system does not have a client HTTP request smuggling vulnerability.

[0095] Another embodiment of the present disclosure relates to a detection device for a client HTTP request smuggling vulnerability, such as Figure 5 As shown, it includes a sending module 510, a judging module 520, and a verifying module 530.

[0096] The sending module 510 is used to send an abnormal HTTP request to a target test system.

[0097] The judgment module 520 is used to judge whether the target test system meets the necessary conditions for the formation of the client HTTP request smuggling vulnerability according to the request response fed back by the target test system.

[0098] The verification module 530 is used to perform a review and verification of the client HTTP request smuggling vulnerability based on an actual application scenario when the target test system meets the necessary conditions for forming the client HTTP request smuggling vulnerability, and obtain a detection result of the target test system.

[0099] The specific implementation method of the detection device for the client HTTP request smuggling vulnerability provided by the embodiment of the present disclosure can be found in the detection method for the client HTTP request smuggling vulnerability provided by the embodiment of the present disclosure, which will not be repeated here.

[0100] Compared with the prior art, the detection device for the client HTTP request smuggling vulnerability provided by the embodiment of the present disclosure makes up for the shortcomings of the existing HTTP request smuggling vulnerability detection method. Based on the necessary conditions for the formation of the client HTTP request smuggling vulnerability, it can achieve rapid preliminary detection of the existence of the client HTTP request smuggling vulnerability, has high detection efficiency, and can further improve the accuracy of detection by reviewing and verifying the client HTTP request smuggling vulnerability based on actual application scenarios.

[0101] Another embodiment of the present disclosure relates to an electronic device, such as Figure 6 As shown, including:

[0102] at least one processor 601; and,

[0103] A memory 602 is communicatively connected to at least one processor 601; wherein,

[0104] The memory 602 stores instructions that can be executed by at least one processor 601. The instructions are executed by at least one processor 601 so that the at least one processor 601 can execute the method for detecting the client HTTP request smuggling vulnerability described in the above embodiment.

[0105] Among them, the memory and the processor are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors and memories together. The bus can also connect various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. The data processed by the processor is transmitted on a wireless medium via an antenna, and further, the antenna also receives data and transmits the data to the processor.

[0106] The processor is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory can be used to store data used by the processor when performing operations.

[0107] Another embodiment of the present disclosure relates to a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method for detecting the client HTTP request smuggling vulnerability described in the above embodiment.

[0108] That is, those skilled in the art can understand that all or part of the steps in the method described in the above embodiments can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including several instructions for making a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) perform all or part of the steps of the method described in each embodiment of the present disclosure. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program codes.

[0109] Those skilled in the art will appreciate that the above-mentioned embodiments are specific embodiments for implementing the present disclosure, and in actual applications, various changes may be made thereto in form and detail without departing from the spirit and scope of the present disclosure.

Claims

1. A method for detecting a client HTTP request smuggling vulnerability, characterized in that: The detection method comprises: Send abnormal HTTP requests to the target test system; According to the request response fed back by the target test system, determine whether the target test system meets the necessary conditions for the formation of the client HTTP request smuggling vulnerability; When the target test system meets the necessary conditions for forming a client HTTP request smuggling vulnerability, a client HTTP request smuggling vulnerability review and verification is performed based on an actual application scenario to obtain a detection result of the target test system.

2. The detection method according to claim 1, characterized in that: The sending of the abnormal HTTP request to the target test system includes: Access the target test system normally, and capture the corresponding HTTP request message as a normal HTTP request; Constructing a plurality of abnormal HTTP requests according to the normal HTTP request; All the abnormal HTTP requests are replayed to the target test system. During the replay process, each time an abnormal HTTP request is replayed, a corresponding normal HTTP request is replayed, and each abnormal HTTP request is in the same connection as the corresponding normal HTTP request.

3. The detection method according to claim 2, characterized in that: The step of constructing a plurality of abnormal HTTP requests according to the normal HTTP request comprises: Modification step: modifying the request header and request body of the normal HTTP request to obtain the abnormal HTTP request; Repeat the modification step multiple times to obtain corresponding multiple abnormal HTTP requests.

4. The detection method according to claim 3, characterized in that: The modifying the request header and request body of the normal HTTP request includes: The content format of the request body is modified, and the request method, URL field and Content-length field in the request header of the normal HTTP request are modified.

5. The detection method according to claim 4, characterized in that: The modifying the content format of the request body and modifying the request method, URL field and Content-length field in the request header of the normal HTTP request includes: Add "GET / 404HTTP / 1.1" to the beginning of the request body, and add "TEST:TEST" to the end of the request body; Change the request method to POST; Adding special characters to the URL field to make the URL field invalid, or filling the URL field with arbitrary characters to make the length of the URL field exceed a preset length, or replacing the URL field with a static file address; Modify the value of the Content-length field so that the modified value of the Content-length field is greater than the modified length of the request body.

6. The detection method according to claim 2, characterized in that: The step of judging whether the target test system meets the necessary conditions for forming a client HTTP request smuggling vulnerability according to the request response fed back by the target test system includes: During the replay process, if all the normal HTTP requests cannot obtain normal responses from the target test system, then the target test system meets the necessary conditions for forming a client HTTP request smuggling vulnerability.

7. The detection method according to claim 2, characterized in that: The client HTTP request smuggling vulnerability review and verification based on the actual application scenario to obtain the detection result of the target test system includes: Replaying, using a browser, the normal HTTP request to which the target test system fails to respond normally during the replay process and the corresponding abnormal HTTP request; Check, through the developer tool, whether the response of the normal HTTP request replayed this time is affected by the response of the corresponding abnormal HTTP request and whether the connection ID of the normal HTTP request replayed this time is the same as the connection ID of the corresponding abnormal HTTP request; If the response to the normal HTTP request is affected by the response to the corresponding abnormal HTTP request and the connection ID of the normal HTTP request is the same as the connection ID of the corresponding abnormal HTTP request, the detection result is that the target test system has a client HTTP request smuggling vulnerability.

8. A detection device for client HTTP request smuggling vulnerability, characterized in that: The detection device comprises: The sending module is used to send abnormal HTTP requests to the target test system; A judgment module, used to judge whether the target test system meets the necessary conditions for forming a client HTTP request smuggling vulnerability according to the request response fed back by the target test system; The verification module is used to perform a review and verification of the client HTTP request smuggling vulnerability based on an actual application scenario when the target test system meets the necessary conditions for forming a client HTTP request smuggling vulnerability, and obtain a detection result of the target test system.

9. An electronic device, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method for detecting the client HTTP request smuggling vulnerability according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method for detecting the client HTTP request smuggling vulnerability described in any one of claims 1 to 7 is implemented.

Images