+44 (0)203 88 020 88

Menu

Search

Cyber Security News & Articles

 

Cyber Security
News & Articles

Trusted Cyber Security Experts
25+ Years Industry Experience
Ethical, Professional & Pragmatic

What is HTTP request smuggling?

Long considered a theoretical attack, HTTP request smuggling is now ‘soaring in popularity’ according to a new research paper published this month.  What is HTTP request smuggling and what risk does it pose to your network?

HTTP Request Smuggling (HRS) was first documented back in 2005.  It is made possible by the way different web servers implement the HTTP standard – as the standard itself leaves some matters open to interpretation.  HRS is also referred to as an HTTP Desync Attack.

Most web server deployments have two of more devices in a chain of systems all talking over HTTP. For example, a load balancer in front of a proxy server, in front of a web application server.

Since HTTP/1.1 it has been possible to send multiple requests in a single long lived TCP/TLS socket – and this approach is often adopted as it is much more performant and efficient than setting up and tearing down a new socket for each request.  The HTTP requests are sent back to back and the header for each request is parsed by the server in order to work out where one request ends and the next one starts.  However, if the front and back-end servers interpret the headers differently and so place the boundary between two successive HTTP requests in a different place, an opportunity for abuse arises.  In particular, contents of the data payload of an HTTP request (which is ignored by the first server) can be turned into a valid HTTP request that is actioned by the second server – in effect being smuggled past the first server and ignored by any defensive logic in place there.

This is possible because the HTTP specification includes two different ways to define the length of a request using two different HTTP headers:  Content-Length and Transfer-Encoding.  Furthermore, RFC2616 which governs the behaviour of these systems states that:

If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

So, an HTTP request with both headers is valid but if you can find a way to cause the first server to ignore the Transfer-Encoding header it will fall back to use the Content-Length but if the second server does not behave in the same way, then you are able to desynchronise the server chain and smuggle requests.  One possible way to do this is by introducing a subtle syntax error into the Transfer-Encoding header that causes a failure in the first server (and so the header is ignored) but is processed successfully by the next server in the chain.

For example:

POST / HTTP/1.1

Host: example.com

Content-Length: 33

Transfer-Encoding: xchunked

    0

GET /img/a.jpg HTTP/1.1 

X:X

 

If the first server in the chain has a strict parser, the ‘xchunked’ value in the Transfer-Encoding header will be ignored as invalid and the server will fall back to the Content-Length header and send the entire message – including the smuggled request in the last lines.

The next server in the chain, which uses a different software stack, parses the headers differently and ignores the ‘x’ and accepted the ‘chunked’ header and uses the Transfer-Encoding to process the request.  Since Transfer-Encoding terminates a chunk of data with a ‘0’ the smuggled request is left in the buffer and not sent on at this time.

A subsequent incoming request arrives at the second server and is appended to the unprocessed smuggled request – making a new request which is only seen by the second server such as:

GET /img/a.jpg HTTP/1.1

X:XGET /js/j.js HTTP/1.1

Host: example.com

In this example the GET command to download the file a.jpg was smuggled past the first server in the chain.

This is an example of a CL.TE style attack, that is both headers are present, the front-end server uses the Content-Length header and the back-end server uses the Transfer-Encoding header.

There are two other flavours of HRS attack:

TE.CL: When both headers are present, the front-end server uses the Transfer-Encoding header and the back-end server uses the Content-Length header.

TE.TE: When both headers are present, the front-end and back-end servers both support the Transfer-Encoding header, but one of the servers can be induced not to process it by obfuscating the header in some way.

In all variations, the key point is that two successive HTTP servers in the transaction chain can be manipulated to interpret the length headers in different ways allowing the data payload of one HTTP request to be processed as a second HTTP request by a server further down the chain.

HRS can be used to perform attacks such as session hijacking, cache poisoning and circumvention of other security controls as well as exploiting design flaws and vulnerabilities in the web application processing the requests.

How to defend against HTTP Request Smuggling

Since HRS relies on a difference in behaviour between the different servers in the chain, it is only possible when those servers are either running different software stacks or different versions of the same software that behave differently when parsing the HTTP request headers.

If you are setting up a new server or have the option to make changes then switching from HTTP/1.1 to HTTP/2 is the easiest defence as it does away with the chunked Transfer-Encoding mechanism in favour of alternatives which are not susceptible to HRS in the same way. This only needs to be done for the links between the servers in the chain, not the public facing side of the first server (although about 97% of web browsers now support HTTP/2)

Another option is to disable the reuse of the socket connections – instead make and break and new connection for each message by adjusting the web server configuration.

Finally, using a Web Application Firewall can defend against HRS both by normalising incoming requests (to remove ambiguity or sloppy syntax designed to confuse downstream webservers) and by inspecting the data payload to look for suspicious content that could be an attempt to smuggle another HTTP request.

You can assess the vulnerability of your web application to HRS and other security threats with a penetration test from SecureTeam.

 

 

 

Subscribe to our monthly newsletter today

If you’d like to stay up-to-date with the latest cyber security news and articles from our technical team, you can sign up to our monthly newsletter. 

We hate spam as much as you do, so we promise not to bombard you with emails. We’ll send you a single, curated email each month that contains all of our cyber security news and articles for that month.

Why Choose SecureTeam?

Customer Testimonials

“We were very impressed with the service, I will say, the vulnerability found was one our previous organisation had not picked up, which does make you wonder if anything else was missed.”

Aim Ltd Chief Technology Officer (CTO)

"Within a very tight timescale, SecureTeam managed to deliver a highly professional service efficiently. The team helped the process with regular updates and escalation where necessary. Would highly recommend"

IoT Solutions Group Limited Chief Technology Officer (CTO) & Founder

“First class service as ever. We learn something new each year! Thank you to all your team.”

Royal Haskoning DHV Service Delivery Manager

“We’ve worked with SecureTeam for a few years to conduct our testing. The team make it easy to deal with them; they are attentive and explain detailed reports in a jargon-free way that allows the less technical people to understand. I wouldn’t work with anyone else for our cyber security.”

Capital Asset Management Head of Operations

“SecureTeam provided Derbyshire's Education Data Hub with an approachable and professional service to ensure our schools were able to successfully certify for Cyber Essentials. The team provided a smooth end-to-end service and were always on hand to offer advice when necessary.”

Derbyshire County Council Team Manager Education Data Hub

“A very efficient, professional, and friendly delivery of our testing and the results. You delivered exactly what we asked for in the timeframe we needed it, while maintaining quality and integrity. A great job, done well.”

AMX Solutions IT Project Officer

“We were very pleased with the work and report provided. It was easy to translate the provided details into some actionable tasks on our end so that was great. We always appreciate the ongoing support.”

Innovez Ltd Support Officer

Get in touch today

If you’d like to see how SecureTeam can take your cybersecurity posture to the next level, we’d love to hear from you, learn about your requirements and then send you a free quotation for our services.

Our customers love our fast-turnaround, “no-nonsense” quotations – not to mention that we hate high-pressure sales tactics as much as you do.

We know that every organisation is unique, so our detailed scoping process ensures that we provide you with an accurate quotation for our services, which we trust you’ll find highly competitive.

Get in touch with us today and a member of our team will be in touch to provide you with a quotation. 

0

No products in the basket.

No products in the basket.