Software Engineering Institute

HTTP cookies have long been known to lead to potential security issues when managing HTTP state. For example, in RFC 6265, Section 8.6:

Cookies do not provide integrity guarantees for sibling domains (and their subdomains). For example, consider foo.example.com and bar.example.com. The foo.example.com server can set a cookie with a Domain attribute of "example.com" (possibly overwriting an existing "example.com" cookie set by bar.example.com), and the user agent will include that cookie in HTTP requests to bar.example.com. In the worst case, bar.example.com will be unable to distinguish this cookie from a cookie it set itself. The foo.example.com server might be able to leverage this ability to mount an attack against bar.example.com.

as well as in RFC 6265, Section 8.5:

Cookies do not provide isolation by port. If a cookie is readable by a service running on one port, the cookie is also readable by a service running on another port of the same server. If a cookie is writable by a service on one port, the cookie is also writable by a service running on another port of the same server.
...
Cookies do not provide isolation by scheme. Although most commonly used with the http and https schemes, the cookies for a given host might also be available to other schemes, such as ftp and gopher.

According to the researchers:

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.

Since RFC 6265 does not specify any mechanism to provide isolation and integrity guarantees, web browser implementations do not always authenticate the domain setting a cookie. A malicious attacker can utilize this to set a cookie that is later used via an HTTPS connection instead of the cookie set by the actual site; for example, an attacker may set cookies for example.com that override the real cookie for www.example.com when the victim is loading HTTPS content. By exploiting other weaknesses in the server, the attacker-controlled cookie may be used to obtain private information. Note that typical Same Origin Policy (RFC 6454) does not apply to cookies and so does not mitigate this attack.

For more details on how an HTTPS session may be compromised by this attack, please see the research paper by Zheng, et. al., published at USENIX Security 2015.

Some web browser vendors have noted previous attempts at more secure cookie management have been foiled due to the lack of a widely implemented standard.

The IETF HTTP State Management Mechanism (httpstate) Working Group that drafted RFC 6265 was concluded in April 2011.

A remote attacker may be able to obtain private information from a victim's HTTPS session.

A complete solution may include future updates to RFC 6265 and/or RFC 6454 to enable safer handling of cookies via an updated same origin policy for cookies.

However, the following workarounds help mitigate this issue:

Deploy HSTS on top-level domain

According to the researchers, website operators should deploy HSTS (RFC 6797) on the top-level domain they control, and utilize the includeSubDomains option. This partially mitigates the attacker's ability to set top-level cookies that may override subdomain cookies.

In general, website operators following best practices for secure website deployment will partially mitigate this attack.

Upgrade your browser

Ensure you are using the latest version of your browser of choice so you have full HSTS support. In particular, if using Internet Explorer, please update to IE 11 or later. HSTS support was added to IE11 in June 2015.