Introduction This article mainly introduces the principles of HTTP request smuggling vulnerabilities, common types of vulnerabilities, and testing methods. At the end of the article, automated testing methods and tools are provided for those in need.0x01 Vulnerability Overview HTTP Request Smuggling is an attack technique that exploits the differences in HTTP protocol parsing between front-end and back-end servers. This vulnerability allows attackers to construct malicious requests that interfere with the HTTP message flow, leading to inconsistencies in how the front-end and back-end servers parse request boundaries. This vulnerability can result in serious consequences such as authentication bypass, sensitive data theft, and XSS chain attacks.0x02 Vulnerability Principles1. Protocol Layer BasicsThe HTTP/1.1 specification defines two methods for determining request length:Content-Length (CL): Explicitly specifies the byte size of the message bodyTransfer-Encoding (TE): Chunked transfer encodingWhen a server receives both headers, RFC recommends prioritizing the TE header, but actual implementations may vary.2. Conditions for Attack Surface FormationThe core cause of the vulnerability lies in the inconsistency of protocol parsing among different components in the request processing chain:[Attacker] –> [Front-end Server] –> [Back-end Server] (Parsing Strategy A) (Parsing Strategy B)Typical difference scenarios:Front-end uses CL header, back-end uses TE headerDifferences in handling malformed requests (e.g., CL=0 but carrying a body)Inconsistent priority judgment for duplicate header fields0x03 Common Vulnerability Types1. CL.TE SmugglingFront-end uses Content-Length, back-end uses Transfer-Encoding:
Resend the request packet
Incl-te,cl is the first threshold, it must ensure thatcl can work normally, but if0 is introduced in the body, it will be recognized as the end of transmission at the second threshold te, at this point G continues to wait in the buffer, and when the next request arrives, it is attached to the next request, contaminating it, thus G is smuggled into the next request, completing the attack.2. TE.CL Smuggling (requires disabling update-content-length)Front-end processes TE header, back-end uses CL header:
Send the exact same request packet again
The front-end server processes the te header, the message body uses chunked encoding, “5c….” will be treated as a block, 0 is the termination flag for chunked transfer (followed by \r\n\r\n), and this request is forwarded to the back-end server.The back-end server checks cl, so it will only read 4 bytes the first time, and the content of “GPOST” is placed in the buffer, and when the request comes again, it will be treated as the start of a request.3. TE.TE Smuggling (Header Confusion Type)To discover TE.TE vulnerabilities, it is necessary to find certain variants of the Transfer-Encoding header so that only one of the front-end or back-end servers processes it while the other ignores it.By exploiting the server’s differences in handling the TE header, achieve header pollution:
Resend the request:
Both front-end and back-end recognize the te header, and perform case confusion on the te header in the request packet, the front-end server can recognize and chunk transfer normally, while the back-end server cannot parse the te header and instead uses the cl header for processing.Other methods of te header confusion:1 Transfer-Encoding: xchunked2 Transfer-Encoding : chunked3 Transfer-Encoding: chunked4 Transfer-Encoding: x5 Transfer-Encoding:[tab]chunked6 [space]Transfer-Encoding: chunked7 X: X[\n]Transfer-Encoding: chunked8 Transfer-Encoding: chunked 0x04 Exploiting VulnerabilitiesScenario: Accessing /admin is intercepted, but /home can be accessed normallyIt can be seen that this is a cl-te scenario.
Directly accessing the /admin path is restricted
Continuing to try to access the /admin path, it prompts that only local users can access:
Constructing a request packet, successfully accessing the /admin path:
0x05 Vulnerability Identification Methods1. Manual Detection TechniquesTime Delay Detection: Send ambiguous requests and observe the response time differencesE.g: Discovering cl-te request smuggling vulnerabilities through time delay detectionSince the front-end server usescl header, it only forwards this request, omitting X, while the back-end server useste header, processes the first block, and then waits for the next block to arrive. This will lead to an observable time delay.
Differential Response Detection: Compare the response characteristics of normal/malformed requests2. Automated Toolsbp plugin:http request smuggler
Select convert to chunked for post request packet:Select an attack method, here taking cl-te as an example:
Response differences indicate the presence of a cl-te request smuggling vulnerability (custom body can also be defined):
Automated tool smuggler:Directly detects request smuggling vulnerabilities automatically, the -x parameter can terminate detection when a possible attack method is detected, improving efficiency.
Tool Link:Link: https://pan.quark.cn/s/772cf5719386 Extraction Code: wzf90x06 Remediation Solutions1. Use HTTP/2 end-to-end and disable HTTP downgrade as much as possible. HTTP/2 uses robust mechanisms to determine the length of requests and can essentially prevent request smuggling when used end-to-end. If HTTP downgrade cannot be avoided, ensure that rewritten requests are validated according to HTTP/1.1 specifications. For example, reject requests that contain newlines in headers, colons in header names, and spaces in request methods.2. Normalize ambiguous requests on the front-end server and have the back-end server reject any still ambiguous requests, closing the TCP connection in the process.3. Never assume that requests do not have a body. This is the fundamental cause of CL.0 and client asynchronous vulnerabilities.4. If a server-level exception is triggered while processing a request, default to dropping the connection.5. If routing traffic through a forwarding proxy, ensure that upstream HTTP/2 is enabled whenever possible.