A whole lot of work rolling out HTTP security is being undermined by bad browser implementation that facilitates man-in-the-middle attacks.
CERT has warned that all of the major browser vendors have a basic implementation error that mean “cookies set via HTTP requests may allow a remote attacker to bypass HTTPS and reveal private session information”.
The problem was first revealed at Usenix, and the good news for users is that the browser makers have now caught up with the problem, so if you're using the latest versions of Safari, Chrome, IE (11 or later only), Mozilla, Opera or Vivaldi, you're in the clear.
Unprotected browsers accept cookies via HTTPS, but they didn't check the source of an HTTPS cookie. As the advisory states:
“A cookie can contain a “secure” flag, indicating that it should be only sent over an HTTPS connection. Yet there is no corresponding flag to indicate how a cookie was set: attackers who act as a man-in-the-midddle even temporarily on an HTTP session can inject cookies which will be attached to subsequent HTTPS connections”.
For the unprotected browser, that meant an attacker could set an HTTPS cookie masquerading as another site: “an attacker may set cookies for example.com and override the real cookie for www.example.com.”
The malicious cookie is under the attacker's control, but even a user who looks through their cookie list might not realise it's a fake - opening the way for the attacker to grab private information.
In the Usenix paper from August the researchers note that Bank of America and Google both structured their sites in ways that permitted a “cookie injection” attack.
The advisory says site owners should protect users by enabling HSTS (HTTP strict transport security, https://tools.ietf.org/html/rfc6797 RFC 6797) with the includeSubdomains option. “This partially mitigates the attacker's ability to set top-level cookies that may override subdomain cookies”.
Or you could just tell your browser to block all cookies. ®