Tricking the frontend and the backend: HTTP request smuggling

Aug 11, 2020 · 5 min read

When you can trick the front and the back of your application causing it to behave unexpectedly.

Image for post
Image for post

Vulnerability, that could allow malicious actors to leverage specific features of the HTTP/1.1 protocol in order to bypass security protections and obtain sensitive information from requests other than their own.

The HTTP request smuggling vulnerability was first discovered by Watchfire in their 2005 whitepaper entitled “HTTP Request Smuggling”. Then the work was later expanded by researcher Regis Leroy which was further discussed by James Kettle from Portswigger security during BlackHat USA 2019.

Some Important Terms

  • Keep-Alive Header: By default, HTTP connections closes after each request. That means when someone visits your site, the browser needs to create new connections to request each of the files that make makes up the web pages. The HTTP keep-alive header maintains a connection between a client and your server, reducing the time needed to load the files.
  • Pipelining: This feature allows a web server to process requests asynchronously rather than processing each request individually. It sends a request without waiting for a previous response to arrive.
  • Content-Length and Transfer-Encoding Header: These headers are used for message framing, informing a server where a message ends and another begins. The content-length header indicates the size of the entity-body of the request which is commonly seen in the HTTP Post request. Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.

What is Request Smuggling?

HTTP Request Smuggling is a type of attack where malicious actor abuses how two HTTP devices send requests between each other by modifying a request to include two requests within the body of a singular request. This informs the server where the request ends by modifying the Content-Length and Transfer-Encoding header.

How does it occur?

This is where malicious actor, causes part of the front-end request to be interpreted by the backend server as the start of the next request. Effectively, prepended to the next request, and so can interfere with the way the application processes that request. And this how the HTTP Request Smuggling attack occurs.

Most of the HTTP specification provides two different ways to specify where a request ends. They are Content-Length and Transfer-Encoding header. Because of there two methods, it is possible for a single message to use both methods at once, such that they conflict with each other. However, we need to keep in mind that some servers do not support the transport-encoding header. While some do not do support the transfer-encoding header can be induced not to process it if the header is obfuscated in some way.

Some Attack Techniques

Image for post
Image for post

There are several different attack methods using HTTP Request Smuggling. Among them, some of them are Cross-Site Scripting (XSS). In this kind of attack, the attacker does not target the specific user but targets any users of the application.

There are also different types of Request Smuggling, which are:

TE: TE- Both the frontend and the backend servers support the Transfer-Encoding header.

CL: TE- Here, the frontend supports content-length whereas, the backend supports transfer-encoding header

TE: CL — The frontend supports transfer-encoding header while the backend supports content-length

CL: CL- Double content length attack technique

TE: TE — Both the back and the frontend supports transfer-encoding header.

In this article, I will demonstrate two of the attack techniques- CL: CL &CL: TE

  1. CL: CL ( Double Content-Length)
GET / HTTP/1.1
Content-Length: 60
Content-Length: 0
GET /reqexample HTTP/1.1

In the above request, you can see that two content-length headers are sent to a target that has a proxy or a load balancer as a frontend. The proxy will prioritize the first one and view the smuggled request as part of the request body. However, the GET method shouldn’t have a request body but here two Content-Length headers have been provided. Now, this is processed by the backend processes the second Content-Length header ignoring the first content-length header.

Since the second Content-Length has the value zero, the backend will expect no request body, and the /reqexample request is treated as another pipelined request. As a result, the response of this smuggled request could be received by another user.

2. CL: TE ( Content-Length: Transfer-Encoding)

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 52
Transfer-Encoding: chunked
GET /404 HTTP/1.1
X-Foo: bar

When the above request gets processed by proxies, the content-length header will be prioritized rather than the transfer-encoding header. However, the backend prioritizes just the opposite which is the transfer-encoding header. And, the backend will process the request ending at character 0. As a result, the 404 GET request gets treated as a separate pipelined request.

Some ways to remediate HTTP Request Smuggling

Image for post
Image for post
  • Make sure that the same server software is used on both the front and back end servers so they agree on which header they will use will prevent the conflicts.
  • Disable reuse of backend connections. Ensure that each back-end request is sent over a separate network connection.
  • Use HTTP/2 for back-end connections, since the protocol prevents ambiguity about the boundaries between requests.
  • Prioritize Transfer-Encoding header over a content-length header by both backend and frontend.
  • Disallow requests that consist of both Content-length and Transfer encoding or double Content-Length headers.

Conclusion: In this article, I have explained some basic concepts and techniques of the HTTP Smuggling attack for educational purposes. You can further regarding the research conducted by James Kettle. Also, you can go through the session given by him during the BlackHat USA 2019.

Digital Diplomacy

Technology, digital, and innovation, at the intersection with government and foreign policy

Sign up for We Are Digital Diplomacy

By Digital Diplomacy

Focus on technology, government, foreign policy and anything in between. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.


Written by


Digital Diplomacy

Technology, digital, and innovation, at the intersection with government and foreign policy


Written by


Digital Diplomacy

Technology, digital, and innovation, at the intersection with government and foreign policy

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store