Attention, webmasters: Insecure website cookies set via HTTP requests may allow a remote attacker to obtain private information from a victim's HTTPS session, warns DHS-CERT.
The problem is this: A cookie can contain a “secure” flag, indicating that it should be sent over only an HTTPS connection. Yet, there is no corresponding flag to indicate how a cookie was set. That means that attackers who act as a man-in-the-middle even temporarily on an HTTP session can inject cookies that will be attached to subsequent HTTPS connections—and use them to obtain data.
Cookies are vastly common—websites use them to remember returning visitors and to track their activities. But, HTTP cookies have long been known to lead to potential security issues—as outlined by the authors of the cookie code, RFC 6265.
One section of the code explains that cookies do not provide integrity guarantees for sibling domains (and their subdomains), and that sometimes, websites will be unable to distinguish a sibling site’s cookie from a cookie it set itself. So, an attacker might be able to leverage this ability to mount an attack against the sister site using the original site’s server.
Similarly, cookies as coded 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.
They also don’t 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,” the authors of the cookie code explained. “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.”
That means that 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 bogus cookies for a site that override the real cookie 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.
Some web browser vendors have noted that previous attempts at more secure cookie management have been foiled due to the lack of a widely implemented standard.
DHS-CERT explained that 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, but for now, there are workarounds to help mitigate the issue. Webmasters 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. If using Internet Explorer, they should update to IE 11 or later. HSTS support was added to IE11 in June 2015.