24M websites vulnerable to complete takeover due to backend reliance on flawed HTTP/1.1

Millions of websites appear to use modern secure protocols, but under the hood, they’re actually downgrading requests to the old HTTP/1.1 somewhere in the proxy chain. Hackers can completely take over these websites due to inherent technology flaws, security researchers warn.

When users visit a website, they send an HTTP request to a server. The request typically hops through multiple components, such as reverse proxies, load balancers, and others, to reach the final destination.

PortSwigger, an application security software provider, discovered over 24 million websites still using the “ancient” HTTP/1.1 protocol somewhere along this path.

Hackers can completely take over these websites using request smuggling – by attaching malicious code to legitimate users’ requests.

“HTTP/1.1 has a fatal, highly-exploitable flaw – the boundaries between individual HTTP requests are very weak. Requests are simply concatenated on the underlying TCP/TLS socket with no delimiters, and there are multiple ways to specify their length. This means attackers can create extreme ambiguity about where one request ends and the next request starts,” new research reports.

What’s even more alarming is that most major cloud service providers still use HTTP/1.1 internally by default. Even website administrators on Google or Cloudflare must manually configure their systems to use HTTP/2 throughout the entire infrastructure.

Some software and services, such as Nginx, Akamai, CloudFront, and Fastly, have not yet added upstream support for the newer HTTP/2 protocol.

The widespread vulnerabilities affect most mature and security-conscious organizations, according to James Kettle, Director of Research at PortSwigger. Kettle unveiled the inherent HTTP/1.1 flaws at Black Hat USA and DEF CON, which already earned him over $350,000 in bug bounties

“If we want a secure web, HTTP/1.1 must die,” the researcher claims.

“A single HTTP request can make a website lose track of which responses should go to which users, resulting in massive disclosure of confidential information. This typically results in users being randomly logged into other live users' accounts.”

Attackers can also poison websites’ caches with malicious JavaScript, giving them persistent control over every page users visit. This enables hackers to redirect users, steal passwords, or credit card details, and more.

The researchers used request smuggling to compromise PayPal twice, which enabled them to steal users' plaintext passwords. The vulnerability disclosures to PayPal alone netted them $39,000 in bug bounties.

How do HTTP desync attacks work?

Kettle explains that reverse proxies typically route requests from different users over a single shared pool of connections to back-end servers.

If an attacker finds “the tiniest parser discrepancy in the server chain,” they can cause a desync and apply malicious additions to other users’ requests.

“This mingles attackers' requests with those from legitimate users.”

Poor request separation is the protocol’s “fatal flaw.” Because HTTP/1.1 is ancient, lenient, text-based, and has thousands of implementations, finding the discrepancies is not hard.

“These attacks exploit a discrepancy in how two different web servers (typically a front-end proxy server and a back-end server) process the same HTTP request. This discrepancy allows an attacker to ‘smuggle’ a malicious request into the back-end server, which can then be used to harm other users of the application,” the paper reads.

For example, an HTTP request can contain the “Content-Length” header, which defines the request’s total size in bytes. But it can also have another header, “Transfer-Encoding: chunked,” which tells the server that the request’s body will be sent in pieces (chunks). Different servers will interpret the same request differently.

An attacker exploits this confusion by sending malformed requests with both headers. One server might think that the request is finished, while the other is still waiting for more data, enabling an attacker to prepend malicious code to the legitimate user’s request.

Kettle doesn’t believe that the protocol’s flaws can be simply patched.

“Time has proven we can't patch HTTP/1.1 to safety – more vulnerabilities are on the way.”

HTTP/1.1 can still be used safely when no proxying is involved, which is not usually the case.

The researcher urges organizations to use HTTP/2 upstream, as this version of the protocol leaves little room for ambiguity about requests’ length and makes desync vulnerabilities much rarer.

If that’s not possible, administrators must aggressively configure their servers to validate and reject ambiguous requests and regularly scan for vulnerabilities. The researcher released an open-source HTTP Request Smuggler v3.0 tool that automatically detects and exploits various advanced desynchronization techniques.