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.