The title to this post is sure alarming, isn’t it?  It’s taken from this summary:

Upstream HTTP/1.1 is inherently insecure and consistently exposes millions of websites to hostile takeover. Six years after we exposed the threat of HTTP desync attacks, there’s still no end in sight. On August 6, James Kettle from PortSwigger Research will reveal new classes of desync attack that enabled him to compromise multiple CDNs and kick off the desync endgame.

What the heck are we talking about here?

Request Smuggling

I first ran into this looming threat because I’m an avid reader of Ted Unangst’s blog, flak.  Ted (aka tedu) is an OpenBSD developer who posts all kinds of interesting things about programming, security, and golang, with his characteristic wit and word-efficient humor.

Ted’s post, “Polarizing Parsers,” observed:

The web as we know it will soon crash and burn in a fiery death. 12 days. There’s even a countdown.

In focus is request smuggling, a clever attack on HTTP/1.1 which happens to still power roughly a third of the web (the rest being HTTP/2 and HTTP/3).  In HTTP/1.1, when a client makes a connection, it sends a header and a body.  The header specifies, among other things, either the length of the body or where the boundaries of the body end.  After all, the server is just getting a stream of bytes.  It needs a map to understand how to parse those bytes.

Most of us are familiar with Content-Length: field.  For example, here is a typical HTTP/1.1 request:

POST /search HTTP/1.1 
Host: www.example.com 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 16

LowEndBox rocks!

The Content-Length: field tells the server that there are 16 bytes in the body.

However, there’s also the Transfer-Encoding field, which tells the server to use chunked encoding. The message body contains one or more “chunks” of data. Each chunk consists of the chunk size in bytes (in hexadecimal), then a newline, and finally the chunk contents. The message is terminated with a chunk of size zero.  This method is typically used where you have a load balancer or other front-end server that is forwarding data to back end servers.

Unfortunately, some servers get confused when you use both methods in the same request.  What can happen is that servers don’t agree where a request ends and where the next one begins.

As Portswigger explains:

POST / HTTP/1.1 
Host: vulnerable-website.com 
Content-Length: 13 
Transfer-Encoding: chunked 

0 

SMUGGLED

The front-end server processes the Content-Length header and determines that the request body is 13 bytes long, up to the end of SMUGGLED. This request is forwarded on to the back-end server.

The back-end server processes the Transfer-Encoding header, and so treats the message body as using chunked encoding. It processes the first chunk, which is stated to be zero length, and so is treated as terminating the request. The following bytes, SMUGGLED, are left unprocessed, and the back-end server will treat these as being the start of the next request in the sequence.

…which can lead to all kinds of mayhem.  For example:

POST /home HTTP/1.1 
Host: vulnerable-website.com 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 62 
Transfer-Encoding: chunked

 0 
GET /admin HTTP/1.1 
Host: vulnerable-website.com 
Foo: xGET /home 
HTTP/1.1 Host: vulnerable-website.com

The front-end server sees two requests here, both for /home, and so the requests are forwarded to the back-end server. However, the back-end server sees one request for /home and one request for /admin. It assumes (as always) that the requests have passed through the front-end controls, and so grants access to the restricted URL.

To be clear, the problem is not with the HTTP/1.1 protocol.  Or as Ted more colorfully puts it:

So what is Akamai (it’s always Akamai) doing that their proxy is putting invalid requests on the wire? Why are we blaming the protocol here, when it’s clear (to me) that the error is the proxy that sends invalid requests? If you put crap on the wire, that’s bad. If your supposed web firewall is the one putting crap on the wire, that’s really bad. Yes, someone somewhere has to deal with the crap input, but why is anything in your stack generating crap? That’s just deranged.

This will be an interesting one to watch.

raindog308

Raindog308 is a longtime LowEndTalk community administrator, technical writer, and self-described techno polymath. With deep roots in the *nix world, he has a passion for systems both modern and vintage, ranging from Unix, Perl, Python, and Golang to shell scripting and mainframe-era operating systems like MVS. He’s equally comfortable with relational database systems, having spent years working with Oracle, PostgreSQL, and MySQL.

As an avid user of LowEndBox providers, Raindog runs an empire of LEBs, from tiny boxes for VPNs, to mid-sized instances for application hosting, and heavyweight servers for data storage and complex databases. He brings both technical rigor and real-world experience to every piece he writes.

Beyond the command line, Raindog is a lover of German Shepherds, high-quality knives, target shooting, theology, tabletop RPGs, and hiking in deep, quiet forests.

His goal with every article is to help users, from beginners to seasoned sysadmins, get more value, performance, and enjoyment out of their infrastructure.

You can find him daily in the forums at LowEndTalk under the handle @raindog308.