Welcome to HTTP Request Smuggling, a topic you’ve probably heard about if you’re new to bug hunting or web security. Now, you may be thinking, "Wow, this sounds complicated." And you’re right, it is. However, once you grasp the basic concept, you’ll find this is one of the most powerful attacks you can learn about.
In this post, I’ll take you from beginner to slightly more advanced levels, providing you with valuable information and insights along the way.
What is HTTP Request Smuggling?
HTTP Request Smuggling is a security flaw that occurs when two servers have different interpretations of an HTTP request.
In a typical web application setup, you have a frontend server and a backend server. The frontend server is typically a proxy server, CDN, or load balancer, while the backend server is where your actual web application is installed and runs.
When you make a request to a web server, your request is processed by both servers. However, if they don’t agree on where one request ends and another starts, you’ll find that things get weird pretty fast.
Why is HTTP Request Smuggling important?
Well, for one, it allows you to:
- Bypass security
- Access unauthorized data
- Hijack other users' requests
- Cache poisoning
- Account takeover
And to top it all off, it’s not even noticed!
Basic HTTP Structure Refresher
Before we dive further into this topic, I thought I’d give you a quick refresher on how HTTP requests work.
As you can see, this is a basic HTTP request example. However, this is all you’ll typically see for most web applications.
- Headers
- Body
- Content-Length
But what is Content-Length? Simply put, it’s how long the body is.
But what if I told you that Content-Length isn’t necessarily true?
Well, one way to measure the length is to look at this example below.
- Transfer-Encoding
- chunked
So, this is where the fun begins.
The Core Problem
The problem lies in the ambiguity.
Two headers are used to define the boundaries of the requests:
- Content-Length
- Transfer-Encoding: chunked
The frontend server trusts one header, and the backend server trusts the other header. This can be manipulated and used to desync the connection.
And this is what we call request smuggling.
Types of Request Smuggling
There are three types of request smuggling attacks that you should be aware of.
1. CL.TE - This is the combination of the content length and the transfer encoding headers.
The frontend server trusts the content length header, and the backend server trusts the transfer encoding header.
Example:
POST / HTTP/1.1
Host: example.com
Content-Length: 13
Transfer-Encoding: chunked
0
G
The frontend server is reading the content length header.
The backend server is reading the chunked transfer encoding header.
The difference in the headers allows us to smuggle the data.
2. TE.CL - This is the combination of the transfer encoding header and the content length header.
The frontend server trusts the transfer encoding header, and the backend server trusts the content length header.
Example:
POST / HTTP/1.1
Host: example.com
Content-Length: 4
Transfer-Encoding: chunked
5
Hello
0
The frontend server is reading the chunked transfer encoding header.
The backend server is reading the content length header.
The difference in the headers allows us to smuggle the data.
3. TE.TE - This is the double transfer encoding header.
The frontend server trusts the transfer encoding header, and the backend server trusts the transfer encoding header.
Example:
Transfer-Encoding: chunked
Transfer-Encoding: xchunked
The frontend server is ignoring the transfer encoding header.
The backend server is reading the transfer encoding header.
The difference in the headers allows us to smuggle the data.
Visualizing the Attack
The attack works like this:
You send the request.
The frontend server thinks the request is complete.
The backend server thinks the request is not complete.
The ‘extra’ portion of the request is the portion that we are smuggling.
Setting Up Your Testing Environment
In order to conduct the request smuggling attack, you will need the following tools:
- Burp Suite - This is the tool that we will be using.
- Repeater - This is the tool that we will be using.
Step 1: Identify Entry Points
Look for:
- POST requests
- API endpoints
- Any requests with a body
Step 2: Send a Normal Request
Catch the request in Burp Repeater.
Example:
POST /api HTTP/1.1
Host: target.com
Content-Length: 11
hello=world
Step 3: Introduce Transfer-Encoding
Change the request to:
POST /api HTTP/1.1
Host: target.com
Content-Length: 11
Transfer-Encoding: chunked
0
X
Observe the behavior.
Step 4: Observe Behavior
Signs of vulnerability:
- Time delays
- Different responses
- Backend errors
- Connection issues
Detecting Desync
The “timeout test” is one way to detect desync.
You send a request that makes the backend wait for data.
- If the frontend times out and the backend doesn’t, you have desync.
Confirming Exploitation
So, we have identified the vulnerability. Now we have to exploit it.
One way to exploit this is:
- Smuggling in a second request:
POST / HTTP/1.1
Host: target.com
Content-Length: 6
Transfer-Encoding: chunked
0
X
GET /admin HTTP/1.1
Host: target.com
If this works, the backend has executed the GET /admin request.
Real Impact of Exploitation
So, what can we actually achieve with this vulnerability?
Bypass Authentication
Smuggling in requests that skip authentication.Access Internal Endpoints
Smuggling in requests to internal endpoints.Cache Poisoning
Smuggling in requests that fill the cache with bad data.
This can affect all users.Session Hijacking
Smuggling in requests that affect other users’ requests.Web Cache Deception
Smuggling in requests that send bad data to users.
Advanced Techniques
So, we have identified the vulnerability and have exploited it. Now we are ready to look at advanced techniques.
1. Prefix Injection
You prepend malicious data to another user’s request.
This is powerful for backend connections.
2. Response Queue Poisoning
You manipulate the queuing of responses.
This can allow you to intercept other users’ responses.
3. HTTP/2 Smuggling
Modern applications use HTTP/2.
It’s a binary protocol, but request smuggling still works due to the downgrade to HTTP/1.1.
4. Browser-Powered Smuggling
Using the victim browsers to carry out the request smuggling attacks.
This increases the impact of the vulnerability.
Common Mistakes Beginners Make
- Don’t understand the basics of HTTP
- Don’t understand the differences between responses
- Give up too soon
- Don’t test multiple variations
Request smuggling can be a patient game.
Tips for Bug Hunters
- Always test for CL.TE and TE.CL
- Test variations of the request payload
- Inconsistent behavior is a good sign
- Timing attacks can be helpful
- API and Microservice testing
Tools That Help
- Burp Suite Repeater
- Turbo Intruder
- HTTP Request Smuggler extension
But remember, tools are helpful, but the real power comes from the brain.
Practice Targets
To become better at request smuggling, you should:
- Use labs from the PortSwigger Web Security Academy
- Create your own vulnerable labs
- Try out CTF challenges
How to Report It
To write a good report, you should include the following:
- A clear description of the desync
- A working example of the request
- A demonstration of the impact
Example
Send request A.
Send request B.
Unexpected response.
Keep it simple and clear.
Final Thoughts
HTTP Request Smuggling is a complex vulnerability to understand.
It’s not the easiest vulnerability to grasp at first.
Nothing seems to work.
Requests fail.
Responses look fine.
But then, suddenly, it all makes sense.
You start to notice patterns.
And that’s when the real fun begins.
Start small.
Basic headers.
Basic request payload.
Basic server behavior.
Then, as you become more comfortable, you can move on to the more complex stuff.