A method for detecting a client HTTP request smuggling vulnerability

Abstract

The embodiment of the present disclosure relates to the technical field of vulnerability detection, and provides a detection method for a client HTTP request smuggling vulnerability, comprising the following steps: sending an abnormal HTTP request to a target test system; judging whether the target test system meets the necessary condition for forming the client HTTP request smuggling vulnerability according to a request response fed back by the target test system; when the target test system meets the necessary condition for forming the client HTTP request smuggling vulnerability, carrying out a review and verification of the client HTTP request smuggling vulnerability based on an actual application scenario to obtain a detection result of the target test system. The embodiment of the present disclosure makes up for the deficiency of the existing HTTP request smuggling vulnerability detection method, can realize rapid preliminary detection on the existence of the client HTTP request smuggling vulnerability, has high detection efficiency, and can further improve the accuracy of detection.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of vulnerability detection, and particularly relates to a detection method for a client HTTP request smuggling vulnerability. BACKGROUND

[0002] WEB systems usually adopt a client / server (C / S) architecture and complete data request and response between the client and the server based on the HyperText Transfer Protocol (HTTP) protocol. The HTTP request smuggling vulnerability refers to a type of vulnerability that the application server incorrectly parses the application client request, parses the HTTP request body content as the request header, and thus produces an unexpected response.

[0003] The HTTP request smuggling vulnerability usually occurs between the application front-end server and the application back-end server. The application front-end server refers to any intermediate server with a request forwarding function, such as a reverse proxy server, a 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 parsing methods for HTTP requests, thus causing HTTP request smuggling and producing a more serious security risk. This type of HTTP request smuggling vulnerability occurs between the application front-end and back-end servers, and is therefore also referred to as a server HTTP request smuggling vulnerability.

[0004] At present, many detection methods have been proposed for the HTTP request smuggling vulnerability problem in the prior art, but these methods can only detect the server HTTP request smuggling vulnerability, that is, they can only detect the HTTP request smuggling vulnerability for WEB applications that have both front-end servers and back-end servers.

[0005] However, in practice, a large number of WEB applications do not have a request forwarding node of the front-end server, and the business request and response are directly completed between the application client (browser) and the application back-end. This type of application deployment mode also has the HTTP request smuggling vulnerability, which is usually referred to as a client HTTP request smuggling vulnerability. Since the specific reasons for the client HTTP request smuggling vulnerability and the server HTTP request smuggling vulnerability are different, the detection method for the server HTTP request smuggling vulnerability cannot be applied to the detection of the client HTTP request smuggling vulnerability, which makes it a problem to be solved in the field how to detect the client HTTP request smuggling vulnerability. SUMMARY

[0006] The present disclosure aims to at least solve one of the problems in the prior art, and provides a detection method for 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, and the method comprises:

[0008] sending an abnormal HTTP request to a target test system;

[0009] judging whether the target test system meets a necessary condition for forming a client HTTP request smuggling vulnerability according to a request response fed back by the target test system;

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

[0011] Optionally, the step of sending an abnormal HTTP request to a target test system comprises:

[0012] normally accessing the target test system to capture a corresponding HTTP request message as a normal HTTP request;

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

[0014] replaying all the abnormal HTTP requests to the target test system, and replaying a corresponding normal HTTP request each time an abnormal HTTP request is replayed, and each abnormal HTTP request is in the same connection as the corresponding normal HTTP request.

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

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

[0017] repeating the modifying step multiple times to obtain a plurality of corresponding abnormal HTTP requests.

[0018] Optionally, the step of modifying a request header and a request body of the normal HTTP request comprises:

[0019] modifying a content format of the request body and modifying a request method, a URL field and a Content-length field in the request header of the normal HTTP request.

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

[0021] adding "GET / 404 HTTP / 1.1" at the beginning of the request body and adding "TEST:TEST" at the end of the request body;

[0022] modifying the request method to POST;

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

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

[0025] Optionally, the judging whether the target test system meets the necessary condition of forming the client HTTP request smuggling vulnerability according to the request response fed back by the target test system comprises:

[0026] In the replay process, if all the normal HTTP requests cannot obtain normal responses of the target test system, the target test system meets the necessary condition of forming the client HTTP request smuggling vulnerability.

[0027] Optionally, the client HTTP request smuggling vulnerability review verification based on the actual application scenario comprises:

[0028] replaying the normal HTTP request and the corresponding abnormal HTTP request which cannot obtain normal responses of the target test system in the replay process by using a browser;

[0029] viewing, by using a developer tool, whether the response of the normal HTTP request is affected by the response of the corresponding abnormal HTTP request and whether the connection ID of the normal HTTP request is the same as the connection ID of the corresponding abnormal HTTP request in this replay;

[0030] 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 the 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 configured to send an abnormal HTTP request to a target test system.

[0033] The determining module is configured to determine whether the target test system meets a necessary condition for forming a client HTTP request smuggling vulnerability based on a request response fed back by the target test system.

[0034] The verifying module is configured to perform a client HTTP request smuggling vulnerability review and verification based on an actual application scenario when the target test system meets the necessary condition for forming the 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, comprising:

[0036] at least one processor; and

[0037] a memory in communication connection with the at least one processor; wherein

[0038] The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the detection method of the client HTTP request smuggling vulnerability as described above.

[0039] Another aspect of the present disclosure provides a computer readable storage medium storing a computer program, and the computer program is executed by a processor to implement the detection method of the client HTTP request smuggling vulnerability as described above.

[0040] The present disclosure makes up for the deficiencies of the existing HTTP request smuggling vulnerability detection method, and is based on the necessary condition for forming the client HTTP request smuggling vulnerability, so that a quick preliminary detection of the existence of the client HTTP request smuggling vulnerability can be realized, and the detection efficiency is high. Furthermore, the detection accuracy can be further improved through the client HTTP request smuggling vulnerability review and verification based on the actual application scenario. BRIEF DESCRIPTION OF DRAWINGS

[0041] One or more embodiments are illustrated by way of example in the drawings, which are not intended to be limiting of the embodiments, and like reference numerals designate corresponding parts throughout the drawings, and in which:

[0042] Figure 1 A flowchart of a detection method of a client HTTP request smuggling vulnerability according to an embodiment of the present disclosure;

[0043] Figure 2A schematic diagram of a detection method of a client HTTP request smuggling vulnerability according to another embodiment of the present disclosure is provided;

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

[0045] Figure 4 A schematic diagram of a response result of a target test system according to another embodiment of the present disclosure is provided;

[0046] Figure 5 A structural schematic diagram of a detection device of a client HTTP request smuggling vulnerability according to another embodiment of the present disclosure is provided;

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

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

[0049] One embodiment of the present disclosure relates to a detection method of a client HTTP request smuggling vulnerability, which takes the basic occurrence principle of the client HTTP request smuggling vulnerability as the starting point, preliminarily investigates the existence of the vulnerability of a target test system by constructing an abnormal HTTP request, and then rechecks and verifies the vulnerability based on the preliminary investigation result and actual application scenarios, so as to realize the detection of the client HTTP request smuggling vulnerability.

[0050] As shown in Figure 1 The detection method of the client HTTP request smuggling vulnerability provided by the embodiment includes the following steps:

[0051] Step S110, an abnormal HTTP request is sent to a target test system.

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

[0053] For example, in combination with Figure 2, step S110 can 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 the HTTP request message, and the present embodiment does not limit this.

[0055] Step 1.2, according to the normal HTTP request, a plurality of abnormal HTTP requests are constructed. Specifically, step 1.2 can construct abnormal HTTP requests according to normal HTTP requests by modifying the request header and the request body based on the HTTP request message captured in step 1.1. In this case, step 1.2 can further include step 1.2.1 and step 1.2.2.

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

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

[0058] GET / 404 HTTP / 1.1

[0059] TEST:TEST

[0060] Modifying the request method in the request header of the normal HTTP request, specifically: modifying the request method to POST. That is, the GET method in the request header of the normal HTTP request is modified to the POST method.

[0061] modifying the URL field in the request header of the normal HTTP request, specifically, adding special characters to the URL field to make the URL field invalid, for example, adding / %2e%2e to the URL field of the normal HTTP request to make the modified URL field invalid. Alternatively, filling the URL field with any characters to make the length of the URL field exceed a preset length, for example, adding a super-long string aaaaaaaaaaaaaaaaaaaa... to the URL field http: / / example.com / of the normal HTTP request to make the length of the modified URL field http: / / example.com / aaaaaaaaaaaaaaaaaaa... exceed the preset length. Alternatively, replacing the URL field with a static file address, for example, replacing the URL field http: / / example.com / of the normal HTTP request with a static file address / robots.txt.

[0062] modifying 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, i.e., repeat the step 1.2.1 multiple times, to obtain a plurality of abnormal HTTP requests corresponding thereto.

[0064] Step 1.3, replay all abnormal HTTP requests to the target test system, and during the replay process, replay one corresponding normal HTTP request for each abnormal HTTP request, i.e., send the abnormal HTTP request and its corresponding normal HTTP request to the target test system at the same time, and each abnormal HTTP request is in the same connection with 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 to make the target test server produce an abnormality as much as possible.

[0066] It should be noted that in step 1.2.1, only the request method, URL field and Content-length field in the request header are modified, because the browser has strict restrictions on HTTP cross-domain requests, and modifying other fields in the request body will cause the cross-domain request to fail, so that the target test system cannot satisfy the cross-domain access, which is one of the necessary conditions for forming the client HTTP request smuggling vulnerability.

[0067] In step S120, it is judged whether the target test system satisfies the necessary condition 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 judge whether the target test system may have a client HTTP request smuggling vulnerability. The necessary conditions for forming the 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 judge 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 in a specific situation, thereby satisfying the necessary condition for forming the 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 satisfy the necessary condition for forming the client HTTP request smuggling vulnerability. Therefore, the purpose of step S110 of sending an abnormal HTTP request to the target test system is to make the target test server produce an exception as much as possible, so as to ignore the Content-Length field.

[0069] For example, in step S120, if all normal HTTP requests cannot obtain normal responses from the target test system during the replay process, it is determined that the target test system satisfies the necessary condition for forming the client HTTP request smuggling vulnerability.

[0070] Specifically, in combination with Figure 2 In step S120, the request response content fed back by the target test system is collected and analyzed, the request response content is parsed and detected, the existence of the client HTTP request smuggling vulnerability is preliminarily judged, and it is judged whether the target test system may have the vulnerability. Among them, if all normal HTTP requests can be normally responded by the target test system during the replay process, it is determined that the target test system is not likely to have a client HTTP request smuggling vulnerability, otherwise it is preliminarily determined that the target test system is likely to 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 reverified based on the actual application scenario, and the detection result of the target test system is obtained.

[0072] Specifically, the purpose of step S130 is to simulate the real behavior of the user. Since the actual application scenario is usually a browser, step S130 can be combined with Figure 2 , step S130 can reverify the vulnerability in the actual application scenario when the target test system meets the necessary conditions for forming the client HTTP request smuggling vulnerability, i.e., there may be a vulnerability. That is, the browser is used to reverify the client HTTP request smuggling vulnerability to ensure the effectiveness and feasibility of vulnerability detection.

[0073] For example, in step S130, the client HTTP request smuggling vulnerability is reverified based on the actual application scenario, and the detection result of the target test system is obtained, including step 3.1 and step 3.2.

[0074] Step 3.1, use the browser to replay the normal HTTP request that the target test system failed to respond normally in the replay process and the corresponding abnormal HTTP request. Specifically, step 3.1 can use the browser to replay the normal HTTP request that failed to obtain the normal response of the target test system in step S120 and the corresponding abnormal HTTP request.

[0075] Step 3.2, through the developer tool, check whether the response of the normal HTTP request in this replay is affected by the response of the corresponding abnormal HTTP request and whether the connection ID of the normal HTTP request in this replay 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 identification of the connection. If the connection ID of the 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] The client HTTP request smuggling vulnerability detection provided by the embodiment of the present disclosure makes up for the deficiencies of the existing HTTP request smuggling vulnerability detection method, and can realize 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, has high detection efficiency, and can further improve the accuracy of detection through the rechecking and verification of the client HTTP request smuggling vulnerability based on the actual application scene.

[0078] In order to enable those skilled in the art to better understand the above-mentioned embodiments, the following will be described with a specific example.

[0079] A detection method of a client HTTP request smuggling vulnerability, comprising the following steps:

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

[0081] Step 2: send the captured HTTP request package to the Repeater module of BurpSutie twice to obtain two request packages that need to be replayed.

[0082] Step 3: add the two request packages that need to be replayed into the same group, and modify the names of the two request packages as 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 shown in the following formula (1). Figure 3

[0084] Step 5: replay the abnormal request and the normal request to the target test system by using the Repeater module, in the replay process, turn on the option of sending sequence requests in the same connection, so that the abnormal request and the normal request are sent in the same connection, and turn off the automatic update Content-length option of BurpSutie.

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

[0086] Step 7: open the browser developer tool, and use JS (JavaScript script) in the console to simulate the verification process of the client HTTP request smuggling vulnerability. The script content includes: the fetch function is used to simulate the abnormal request, the then function is used to simulate the normal request, and the mode: no-cors is used to display the connection ID. The script content can be specifically represented 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, view the response feedback of the target test system in the network option of the developer tool. If the response of the normal request is 404 and the connection ID of the normal request is the same as that 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. As shown in Figure 4 , if the connection ID of the normal request is the same as that of the abnormal request, but the normal request can obtain the normal response of 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 is indicated 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, as shown in Figure 5 , comprising a sending module 510, a judging module 520 and a verifying module 530.

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

[0097] The judging module 520 is configured to judge whether the target test system meets the necessary condition for forming a client HTTP request smuggling vulnerability according to the request response feedback of the target test system.

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

[0099] The specific implementation method of the client HTTP request smuggling vulnerability detection apparatus provided by the embodiment of the present disclosure can be referred to the client HTTP request smuggling vulnerability detection method provided by the embodiment of the present disclosure, which will not be described here again.

[0100] The client HTTP request smuggling vulnerability detection apparatus provided by the embodiment of the present disclosure makes up for the deficiency of the existing HTTP request smuggling vulnerability detection method, and is based on the necessary condition for the formation of the client HTTP request smuggling vulnerability. The apparatus can realize the 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 through the rechecking and verification of the client HTTP request smuggling vulnerability based on the actual application scenario.

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

[0102] at least one processor 601; and

[0103] a memory 602 connected in communication with the at least one processor 601; wherein

[0104] The memory 602 stores instructions executable by the at least one processor 601, and the instructions are executed by the at least one processor 601 to enable the at least one processor 601 to perform the client HTTP request smuggling vulnerability detection method described in the above embodiments.

[0105] The memory and the processor are connected in a bus manner, the bus can 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 peripheral devices, voltage stabilizers, and power management circuits together, which are well known in the art, and therefore, they will not be 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, which provide a unit for communicating with various other devices on the transmission medium. The data processed by the processor is transmitted on the wireless medium through the 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 interface, voltage regulation, power management, and other control functions. And the memory can be used to store the data used by the processor in the execution operation.

[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 client HTTP request smuggling vulnerabilities according to the above-mentioned embodiments.

[0108] That is, a person skilled in the art can understand that all or part of the steps in the method according to the above-mentioned embodiments can be completed by instructing the relevant hardware through a program stored in a storage medium, including a plurality of instructions for causing a device (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the method according to the embodiments of the present disclosure. The aforementioned storage medium includes a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0109] A person skilled in the art can understand that the above-mentioned embodiments are specific embodiments for implementing the present disclosure, and in actual applications, various changes can be made in form and details without departing from the spirit and scope of the present disclosure.

Claims

1. A method for detecting client-side HTTP request smuggling vulnerabilities, characterized in that, The detection method comprises: sending an abnormal HTTP request to a target test system; judging whether the target test system meets a necessary condition for forming a client HTTP request smuggling vulnerability according to a request response fed back by the target test system; when the target test system meets the necessary condition for forming the client HTTP request smuggling vulnerability, performing a client HTTP request smuggling vulnerability review and verification based on an actual application scenario to obtain a detection result of the target test system; the sending of the abnormal HTTP request to the target test system comprises: normally accessing the target test system and capturing a corresponding HTTP request message as a normal HTTP request; constructing a plurality of abnormal HTTP requests according to the normal HTTP request; replaying all the abnormal HTTP requests to the target test system, wherein in the replaying process, one corresponding normal HTTP request is replayed every time one abnormal HTTP request is replayed, and each abnormal HTTP request is in the same connection as the corresponding normal HTTP request; the construction of the plurality of abnormal HTTP requests according to the normal HTTP request comprises: a modification step of modifying a request header and a request body of the normal HTTP request to obtain the abnormal HTTP request; repeating the modification step multiple times to obtain a plurality of corresponding abnormal HTTP requests; the modification of the request header and the request body of the normal HTTP request comprises: modifying a content format of the request body and modifying a request method and a Content-length field in the request header of the normal HTTP request; the modification of the content format of the request body and the request method and the Content-length field in the request header of the normal HTTP request comprises: adding "GET / 404 HTTP / 1.1" at the beginning of the request body and adding "TEST:TEST" at the end of the request body; modifying the request method to POST; modifying a 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; the judgment of whether the target test system meets the necessary condition for forming the client HTTP request smuggling vulnerability according to the request response fed back by the target test system comprises: in the replaying process, if all the normal HTTP requests cannot obtain a normal response of the target test system, the target test system meets the necessary condition for forming the client HTTP request smuggling vulnerability.

2. The detection method according to claim 1, characterized in that, the modification of the request header and the request body of the normal HTTP request further comprises: modifying a URL field in the request header of the normal HTTP request.

3. The detection method according to claim 2, characterized in that, the modification of the URL field in the request header of the normal HTTP request comprises: adding special characters to the URL field to invalidate the URL field, or filling the URL field with any characters to make the length of the URL field exceed a preset length, or replacing the URL field with a static file address.

4. The method of claim 1, wherein The detection result of the target test system is obtained by verifying the client HTTP request smuggling vulnerability based on the actual application scenario. The normal HTTP request and the corresponding abnormal HTTP request that the target test system fails to respond normally in the replay process are replayed using a browser. It is determined whether the response of the normal HTTP request is affected by the response of the corresponding abnormal HTTP request and whether the connection ID of the normal HTTP request is the same as the connection ID of the corresponding abnormal HTTP request through the developer tool. 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. If the response of 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.

5. A detection device for client-side HTTP request smuggling vulnerabilities, characterized in that, The detection device comprises: The sending module is configured to send an abnormal HTTP request to the target test system. The judgment module is configured to determine whether the target test system meets the necessary condition for forming a client HTTP request smuggling vulnerability according to the request response fed back by the target test system. The verification module is configured to, when the target test system meets the necessary condition for forming a client HTTP request smuggling vulnerability, verify the client HTTP request smuggling vulnerability based on the actual application scenario to obtain the detection result of the target test system. The sending module is configured to send an abnormal HTTP request to the target test system. The normal HTTP request is obtained by normally accessing the target test system and capturing the corresponding HTTP request message. The abnormal HTTP request is constructed according to the normal HTTP request. All abnormal HTTP requests are replayed to the target test system, and each abnormal HTTP request is replayed with a corresponding normal HTTP request in the same connection. The abnormal HTTP request is constructed according to the normal HTTP request. The modification step is repeated multiple times to obtain a plurality of corresponding abnormal HTTP requests. The request header and the request body of the normal HTTP request are modified to obtain the abnormal HTTP request. The modification step is repeated multiple times to obtain a plurality of corresponding abnormal HTTP requests. The request header and the request body of the normal HTTP request are modified to obtain the abnormal HTTP request. modifying a content format of the request body, and modifying a request method and a Content-length field in the request header of the normal HTTP request; the modifying a content format of the request body, and modifying a request method and a Content-length field in the request header of the normal HTTP request, comprises: adding "GET / 404 HTTP / 1.1" at the beginning of the request body, and adding "TEST:TEST" at the end of the request body; modifying the request method to POST; modifying a value of the Content-length field, so that a modified value of the Content-length field is greater than a length of the modified request body; the judging whether the target test system satisfies the necessary condition of forming the client HTTP request smuggling vulnerability according to the request response fed back by the target test system, comprises: in the replay process, if all the normal HTTP requests cannot obtain the normal response of the target test system, the target test system satisfies the necessary condition of forming the client HTTP request smuggling vulnerability.

6. An electronic device, comprising: comprise: at least one processor; and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the detection method of the client HTTP request smuggling vulnerability according to any one of claims 1 to 4.

7. A computer readable storage medium storing a computer program, characterized in that, the computer program is executed by the processor to implement the detection method of the client HTTP request smuggling vulnerability according to any one of claims 1 to 4.

Images