HTTP Request Smuggling / HTTP Desync Attack
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
This vulnerability occurs when a desyncronization between front-end proxies and the back-end server allows an attacker to send an HTTP request that will be interpreted as a single request by the front-end proxies (load balance/reverse-proxy) and as 2 request by the back-end server. This allows a user to modify the next request that arrives to the back-end server after his.
If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
Content-Length
The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.
Transfer-Encoding: chunked
The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user. Chunked means that large data is sent in a series of chunks
The Front-End (a load-balance / Reverse Proxy) process the content-length or the transfer-encoding header and the Back-end server process the other one provoking a desyncronization between the 2 systems. This could be very critical as an attacker will be able to send one request to the reverse proxy that will be interpreted by the back-end server as 2 different requests. The danger of this technique resides in the fact the back-end server will interpret the 2nd request injected as if it came from the next client and the real request of that client will be part of the injected request.
Remember that in HTTP a new line character is composed by 2 bytes:
Content-Length: This header uses a decimal number to indicate the number of bytes of the body of the request. The body is expected to end in the last character, a new line is not needed in the end of the request.
Transfer-Encoding: This header uses in the body an hexadecimal number to indicate the number of bytes of the next chunk. The chunk must end with a new line but this new line isn't counted by the length indicator. This transfer method must end with a chunk of size 0 followed by 2 new lines: 0
Connection: Based on my experience it's recommended to use Connection: keep-alive on the first request of the request Smuggling.
When trying to exploit this with Burp Suite disable Update Content-Length and Normalize HTTP/1 line endings in the repeater because some gadgets abuse newlines, carriage returns and malformed content-lengths.
HTTP request smuggling attacks are crafted by sending ambiguous requests that exploit discrepancies in how front-end and back-end servers interpret the Content-Length (CL) and Transfer-Encoding (TE) headers. These attacks can manifest in different forms, primarily as CL.TE, TE.CL, and TE.TE. Each type represents a unique combination of how the front-end and back-end servers prioritize these headers. The vulnerabilities arise from the servers processing the same request in different ways, leading to unexpected and potentially malicious outcomes.
To the previous table you should add the TE.0 technique, like CL.0 technique but using Transfer Encoding.
Front-End (CL): Processes the request based on the Content-Length header.
Back-End (TE): Processes the request based on the Transfer-Encoding header.
Attack Scenario:
The attacker sends a request where the Content-Length header's value does not match the actual content length.
The front-end server forwards the entire request to the back-end, based on the Content-Length value.
The back-end server processes the request as chunked due to the Transfer-Encoding: chunked header, interpreting the remaining data as a separate, subsequent request.
Example:
Front-End (TE): Processes the request based on the Transfer-Encoding header.
Back-End (CL): Processes the request based on the Content-Length header.
Attack Scenario:
The attacker sends a chunked request where the chunk size (7b) and actual content length (Content-Length: 4) do not align.
The front-end server, honoring Transfer-Encoding, forwards the entire request to the back-end.
The back-end server, respecting Content-Length, processes only the initial part of the request (7b bytes), leaving the rest as part of an unintended subsequent request.
Example:
Servers: Both support Transfer-Encoding, but one can be tricked into ignoring it via obfuscation.
Attack Scenario:
The attacker sends a request with obfuscated Transfer-Encoding headers.
Depending on which server (front-end or back-end) fails to recognize the obfuscation, a CL.TE or TE.CL vulnerability may be exploited.
The unprocessed part of the request, as seen by one of the servers, becomes part of a subsequent request, leading to smuggling.
Example:
Both servers process the request based solely on the Content-Length header.
This scenario typically does not lead to smuggling, as there's alignment in how both servers interpret the request length.
Example:
Refers to scenarios where the Content-Length header is present and has a value other than zero, indicating that the request body has content. The back-end ignores the Content-Length header (which is treated as 0), but the front-end parses it.
It's crucial in understanding and crafting smuggling attacks, as it influences how servers determine the end of a request.
Example:
Like the previous one but using TE
Technique reported here
Example:
This technique is also useful in scenarios where it's possible to break a web server while reading the initial HTTP data but without closing the connection. This way, the body of the HTTP request will be considered the next HTTP request.
For example, as explained in this writeup, In Werkzeug it was possible to send some Unicode characters and it will make the server break. However, if the HTTP connection was created with the header Connection: keep-alive, the body of the request won’t be read and the connection will still be open, so the body of the request will be treated as the next HTTP request.
Abusing hop-by-hop headers you could indicate the proxy to delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse.
For more information about hop-by-hop headers visit:
Identifying HTTP request smuggling vulnerabilities can often be achieved using timing techniques, which rely on observing how long it takes for the server to respond to manipulated requests. These techniques are particularly useful for detecting CL.TE and TE.CL vulnerabilities. Besides these methods, there are other strategies and tools that can be used to find such vulnerabilities:
Method:
Send a request that, if the application is vulnerable, will cause the back-end server to wait for additional data.
Example:
Observation:
The front-end server processes the request based on Content-Length and cuts off the message prematurely.
The back-end server, expecting a chunked message, waits for the next chunk that never arrives, causing a delay.
Indicators:
Timeouts or long delays in response.
Receiving a 400 Bad Request error from the back-end server, sometimes with detailed server information.
Method:
Send a request that, if the application is vulnerable, will cause the back-end server to wait for additional data.
Example:
Observation:
The front-end server processes the request based on Transfer-Encoding and forwards the entire message.
The back-end server, expecting a message based on Content-Length, waits for additional data that never arrives, causing a delay.
Differential Response Analysis:
Send slightly varied versions of a request and observe if the server responses differ in an unexpected way, indicating a parsing discrepancy.
Using Automated Tools:
Tools like Burp Suite's 'HTTP Request Smuggler' extension can automatically test for these vulnerabilities by sending various forms of ambiguous requests and analyzing the responses.
Content-Length Variance Tests:
Send requests with varying Content-Length values that are not aligned with the actual content length and observe how the server handles such mismatches.
Transfer-Encoding Variance Tests:
Send requests with obfuscated or malformed Transfer-Encoding headers and monitor how differently the front-end and back-end servers respond to such manipulations.
After confirming the effectiveness of timing techniques, it's crucial to verify if client requests can be manipulated. A straightforward method is to attempt poisoning your requests, for instance, making a request to / yield a 404 response. The CL.TE and TE.CL examples previously discussed in Basic Examples demonstrate how to poison a client's request to elicit a 404 response, despite the client aiming to access a different resource.
Key Considerations
When testing for request smuggling vulnerabilities by interfering with other requests, bear in mind:
Distinct Network Connections: The "attack" and "normal" requests should be dispatched over separate network connections. Utilizing the same connection for both doesn't validate the vulnerability's presence.
Consistent URL and Parameters: Aim to use identical URLs and parameter names for both requests. Modern applications often route requests to specific back-end servers based on URL and parameters. Matching these increases the likelihood that both requests are processed by the same server, a prerequisite for a successful attack.
Timing and Racing Conditions: The "normal" request, meant to detect interference from the "attack" request, competes against other concurrent application requests. Therefore, send the "normal" request immediately following the "attack" request. Busy applications may necessitate multiple trials for conclusive vulnerability confirmation.
Load Balancing Challenges: Front-end servers acting as load balancers may distribute requests across various back-end systems. If the "attack" and "normal" requests end up on different systems, the attack won't succeed. This load balancing aspect may require several attempts to confirm a vulnerability.
Unintended User Impact: If your attack inadvertently impacts another user's request (not the "normal" request you sent for detection), this indicates your attack influenced another application user. Continuous testing could disrupt other users, mandating a cautious approach.
Sometimes, front-end proxies enforce security measures, scrutinizing incoming requests. However, these measures can be circumvented by exploiting HTTP Request Smuggling, allowing unauthorized access to restricted endpoints. For instance, accessing /admin might be prohibited externally, with the front-end proxy actively blocking such attempts. Nonetheless, this proxy may neglect to inspect embedded requests within a smuggled HTTP request, leaving a loophole for bypassing these restrictions.
Consider the following examples illustrating how HTTP Request Smuggling can be used to bypass front-end security controls, specifically targeting the /admin path which is typically guarded by the front-end proxy:
CL.TE Example
In the CL.TE attack, the Content-Length header is leveraged for the initial request, while the subsequent embedded request utilizes the Transfer-Encoding: chunked header. The front-end proxy processes the initial POST request but fails to inspect the embedded GET /admin request, allowing unauthorized access to the /admin path.
TE.CL Example
Conversely, in the TE.CL attack, the initial POST request uses Transfer-Encoding: chunked, and the subsequent embedded request is processed based on the Content-Length header. Similar to the CL.TE attack, the front-end proxy overlooks the smuggled GET /admin request, inadvertently granting access to the restricted /admin path.
Applications often employ a front-end server to modify incoming requests before passing them to the back-end server. A typical modification involves adding headers, such as X-Forwarded-For: <IP of the client>, to relay the client's IP to the back-end. Understanding these modifications can be crucial, as it might reveal ways to bypass protections or uncover concealed information or endpoints.
To investigate how a proxy alters a request, locate a POST parameter that the back-end echoes in the response. Then, craft a request, using this parameter last, similar to the following:
In this structure, subsequent request components are appended after search=, which is the parameter reflected in the response. This reflection will expose the headers of the subsequent request.
It's important to align the Content-Length header of the nested request with the actual content length. Starting with a small value and incrementing gradually is advisable, as too low a value will truncate the reflected data, while too high a value can cause the request to error out.
This technique is also applicable in the context of a TE.CL vulnerability, but the request should terminate with search=\r\n0. Regardless of the newline characters, the values will append to the search parameter.
This method primarily serves to understand the request modifications made by the front-end proxy, essentially performing a self-directed investigation.
It's feasible to capture the requests of the next user by appending a specific request as the value of a parameter during a POST operation. Here's how this can be accomplished:
By appending the following request as the value of a parameter, you can store the subsequent client's request:
In this scenario, the comment parameter is intended to store the contents within a post's comment section on a publicly accessible page. Consequently, the subsequent request's contents will appear as a comment.
However, this technique has limitations. Generally, it captures data only up to the parameter delimiter used in the smuggled request. For URL-encoded form submissions, this delimiter is the & character. This means the captured content from the victim user's request will stop at the first &, which may even be part of the query string.
Additionally, it's worth noting that this approach is also viable with a TE.CL vulnerability. In such cases, the request should conclude with search=\r\n0. Regardless of newline characters, the values will be appended to the search parameter.
HTTP Request Smuggling can be leveraged to exploit web pages vulnerable to Reflected XSS, offering significant advantages:
Interaction with the target users is not required.
Allows the exploitation of XSS in parts of the request that are normally unattainable, like HTTP request headers.
In scenarios where a website is susceptible to Reflected XSS through the User-Agent header, the following payload demonstrates how to exploit this vulnerability:
This payload is structured to exploit the vulnerability by:
Initiating a POST request, seemingly typical, with a Transfer-Encoding: chunked header to indicate the start of smuggling.
Following with a 0, marking the end of the chunked message body.
Then, a smuggled GET request is introduced, where the User-Agent header is injected with a script, <script>alert(1)</script>, triggering the XSS when the server processes this subsequent request.
By manipulating the User-Agent through smuggling, the payload bypasses normal request constraints, thus exploiting the Reflected XSS vulnerability in a non-standard but effective manner.
In case the user content is reflected in a response with a Content-type such as text/plain, preventing the execution of the XSS. If the server support HTTP/0.9 it might be possible to bypass this!
The version HTTP/0.9 was previously to the 1.0 and only uses GET verbs and doesn’t respond with headers, just the body.
In this writeup, this was abused with a request smuggling and a vulnerable endpoint that will reply with the input of the user to smuggle a request with HTTP/0.9. The parameter that will be reflected in the response contained a fake HTTP/1.1 response (with headers and body) so the response will contain valid executable JS code with a Content-Type of text/html.
Applications often redirect from one URL to another by using the hostname from the Host header in the redirect URL. This is common with web servers like Apache and IIS. For instance, requesting a folder without a trailing slash results in a redirect to include the slash:
Results in:
Though seemingly harmless, this behavior can be manipulated using HTTP request smuggling to redirect users to an external site. For example:
This smuggled request could cause the next processed user request to be redirected to an attacker-controlled website:
Results in:
In this scenario, a user's request for a JavaScript file is hijacked. The attacker can potentially compromise the user by serving malicious JavaScript in response.
Web cache poisoning can be executed if any component of the front-end infrastructure caches content, typically to enhance performance. By manipulating the server's response, it's possible to poison the cache.
Previously, we observed how server responses could be altered to return a 404 error (refer to Basic Examples). Similarly, it’s feasible to trick the server into delivering /index.html content in response to a request for /static/include.js. Consequently, the /static/include.js content gets replaced in the cache with that of /index.html, rendering /static/include.js inaccessible to users, potentially leading to a Denial of Service (DoS).
This technique becomes particularly potent if an Open Redirect vulnerability is discovered or if there's an on-site redirect to an open redirect. Such vulnerabilities can be exploited to replace the cached content of /static/include.js with a script under the attacker's control, essentially enabling a widespread Cross-Site Scripting (XSS) attack against all clients requesting the updated /static/include.js.
Below is an illustration of exploiting cache poisoning combined with an on-site redirect to open redirect. The objective is to alter the cache content of /static/include.js to serve JavaScript code controlled by the attacker:
Note the embedded request targeting /post/next?postId=3. This request will be redirected to /post?postId=4, utilizing the Host header value to determine the domain. By altering the Host header, the attacker can redirect the request to their domain (on-site redirect to open redirect).
After successful socket poisoning, a GET request for /static/include.js should be initiated. This request will be contaminated by the prior on-site redirect to open redirect request and fetch the content of the script controlled by the attacker.
Subsequently, any request for /static/include.js will serve the cached content of the attacker's script, effectively launching a broad XSS attack.
What is the difference between web cache poisoning and web cache deception?
In web cache poisoning, the attacker causes the application to store some malicious content in the cache, and this content is served from the cache to other application users.
In web cache deception, the attacker causes the application to store some sensitive content belonging to another user in the cache, and the attacker then retrieves this content from the cache.
The attacker crafts a smuggled request that fetches sensitive user-specific content. Consider the following example:
If this smuggled request poisons a cache entry intended for static content (e.g., /someimage.png), the victim's sensitive data from /private/messages might be cached under the static content's cache entry. Consequently, the attacker could potentially retrieve these cached sensitive data.
In this post is suggested that if the server has the method TRACE enabled it could be possible to abuse it with a HTTP Request Smuggling. This is because this method will reflect any header sent to the server as part of the body of the response. For example:
Will send a response such as:
An example on how to abuse this behaviour would be to smuggle first a HEAD request. This request will be responded with only the headers of a GET request (Content-Type among them). And smuggle immediately after the HEAD a TRACE request, which will be reflecting the sent data.
As the HEAD response will be containing a Content-Length header, the response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data in the response.
This response will be sent to the next request over the connection, so this could be used in a cached JS file for example to inject arbitrary JS code.
Continue following this post is suggested another way to abuse the TRACE method. As commented, smuggling a HEAD request and a TRACE request it's possible to control some reflected data in the response to the HEAD request. The length of the body of the HEAD request is basically indicated in the Content-Length header and is formed by the response to the TRACE request.
Therefore, the new idea would be that, knowing this Content-Length and the data given in the TRACE response, it's possible to make the TRACE response contains a valid HTTP response after the last byte of the Content-Length, allowing an attacker to completely control the request to the next response (which could be used to perform a cache poisoning).
Example:
Will generate these responses (note how the HEAD response has a Content-Length making the TRACE response part of the HEAD body and once the HEAD Content-Length ends a valid HTTP response is smuggled):
Have you found some HTTP Request Smuggling vulnerability and you don't know how to exploit it. Try these other method of exploitation:
Browser HTTP Request Smuggling (Client Side)
Request Smuggling in HTTP/2 Downgrades
From https://hipotermia.pw/bb/http-desync-idor
From: https://hipotermia.pw/bb/http-desync-account-takeover
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: This tool is a grammar-based HTTP Fuzzer useful to find weird request smuggling discrepancies.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
