SoylentNews

upstart writes:

Submitted via IRC for Bytram

Header aches in Firefox, Tor, Brave and Chrome as HTTP opens new security holes

The HTTP Alternative Services header can be abused to conduct network reconnaissance and attacks, to bypass malware protection services, and to foil tracking defenses and privacy assumptions, according to a paper scheduled to be presented at the WOOT '19 security conference on Tuesday.

Back in March 2016, the Internet Engineering Steering Group approved the HTTP Alternative Services header as a proposed web standard for situations when a web server needs to send a client to another service.

There are a variety of legitimate reasons to do this: a web server may be overloaded with requests, may be undergoing maintenance, or may determine that another server is closer (and thus quicker to respond). As Mark Nottingham, co-chair the IETF HTTP and QUIC Working Groups, explained at the time, such redirection can be handled by DNS load balancing under short-lived HTTP/1.1 connections.

But DNS load balancing doesn't work as well with HTTP/2, which is designed to maintain a persistent connection.

HTTP Alternatives Services was designed as an alternative method to point requests elsewhere. It allows a web server to return a header that specifies another server as the host of its resources, in effect deputizing the stand-in to act as the Origin, the first-party source of content.

"The ability to redirect clients to use another server in a transparent, persistent fashion brings some obvious security concerns," said Nottingham in his post.

A paper titled "Alternative (ab)uses for HTTP Alternative Services," by boffins Trishita Tiwari, who co-authored the paper while at Boston University and is currently a cyber-security PhD student at Cornell University, and Ari Trachtenberg, professor of electrical and computer engineering at Boston University, makes these obvious security concerns more evident.

[...]

Tiwari said that the security implications mentioned in Nottingham's 2016 blog post were incorporated into the Alt-Svc spec.

"The spec does attempt to address these issues, but the mitigations proposed there (i.e., clearing the Alt-Svc cache when the user clears their browser cache) are not strong enough," she said.

"Browser vendors understand this and are now proposing much stronger mitigations like cache isolation (which should, in my opinion, be included in the spec so that it is not at the mercy of individual browser vendors to implement it – user tracking has become a rising issue, and it is high time that these RFCs start requiring cache isolation upfront)."

"The rest of the attacks we show in the paper stem from how the Alt-Svc spec was improperly implemented, so, in a sense, the remaining attacks weren't fundamental design flaws, but rather flaws in the way browser vendors implemented the design," she said.

Original Submission