Free Tool Scans Web Servers for Vulnerability to HTTP Header-Smuggling Attacks

A researcher has created a method for testing and identifying how HTTP/HTTPS headers can be abused to sneak malicious code into back-end servers.

Daniel Thatcher, researcher and penetration tester at Intruder, will present his new research on so-called HTTP header-smuggling at Black Hat Europe, in London next week. He also will release a free tool for testing Web servers for weaknesses that could allow an attacker to pull off this Web attack.

HTTP (and HTTPS) headers carry information such as the client's browser, cookies, and IP address, as well as the requested Web page. Thatcher has been studying header-smuggling, which he explains is related to, but not the same as, HTTP request-smuggling attacks.

HTTP request-smuggling attack methods have been studied and well-documented by researchers James Kettle of Portswigger and Amit Klein. With this tactic, an attacker could send Web requests that purposely desynchronize how front-end and back-end Web servers process them, leading to other attack opportunities, such as cross-site scripting.

"Header-smuggling and request-smuggling are separate," but header-smuggling can be used to smuggle a malicious request, Thatcher explains.

Header-smuggling is a technique in which a front-end server sneaks malicious or phony information to the back-end server within the HTTP header, for example.

Thatcher says header-smuggling can be used to exploit other weaknesses in Web applications as well. He plans to demonstrate how header smuggling was used to bypass IP-address restrictions in the AWS API Gateway, resulting in a cache-poisoning exploit. He wouldn't give away any details just yet on the AWS research but says it was a "specific issue" in the AWS gateway.

In his research, Thatcher found HTTP header-smuggling made cache-poisoning easier than it typically can be. This could allow an attacker to overwrite any cached pages with their own content, he says.

"I've developed a methodology which leverages the errors HTTP servers return when an invalid value is provided in the 'Content-Length' header, which typically should be an integer," Thatcher says. "You can then start looking at other headers using this mutation to see if any interesting behavior can be generated by sneaking headers through to the back-end server."

So who's the responsible party to fix or prevent this type of HTTP/HTTPS abuse? 

"That's a really interesting question," Thatcher says. "You've got this situation where two different Web servers from two different organizations combine to create the issue. It's not an issue that they've done anything wrong or messed up. ... It requires a level of cooperation from every Web server."

Not all implementations of the HTTP standards are equal: "The HTTP standards set out fairly strict rules on what a request should look like," he says, but not all Web server developers "stick" with those rules. "A lot of Web servers are very generous in how they pass a request," Thatcher adds.

The good news is his research appears to be ahead of the bad guys — so far, anyway. 

"As far as I know, we've never heard of any of this in the wild," he says. "Not yet."