Security researchers have shed more light on the way that browsers’ lack of integrity checking for cookies puts web users at risk of attacks that can extract information from encrypted connections.
One of the issues is that browsers will allow cookies set on subdomains to be sent to other subdomains and to the main domain of a site. If an attacker can breach a subdomain’s server and create their own cookies, subdomains set by that server will also be sent to other subdomains and vice versa.
Many large websites allow users to create subdomains and add content to them — think of the way WordPress.com creates subdomains for user sites. In theory, a user with control of one subdomain can set cookies that will be used by other subdomains. This vulnerability is one of the main reasons that GitHub moved its user home pages from subdomains of the site’s main github.com domain onto the github.io domain. Similar problems exist for content distribution networks that use subdomains for serving hosted content.
The situation is further complicated by the fact that, although cookies are able to carry a “secure flag” so that they will only be sent over an HTTPS connection, there’s no way to determine the conditions under which the cookie was originally set. If a man-in-the-middle attacker can exploit the lack of cookie integrity checking we’ve discussed, they can set a cookie using an HTTP connection for a subdomain that will be used by the browser even on an HTTPS connection, allowing attackers with non-encrypted access to inject cookies into encrypted connections.
The vulnerability created by the lack of cookie integrity checking was used by the researchers to demonstrate a wide-range of successful attacks that included hijacking GMail chat widgets, stealing Google search history, stealing credit card data, hijacking online deposits, and manipulating shopping carts on popular eCommerce sites.
If you’re interested in the specific details of these attacks, take a look at the original research paper.
There have been various attempts to limit the effectiveness of cookie injections and related attacks, but they have largely failed because browser developers and others with skin in the game can’t agree on a standard mechanism to make cookies more secure.
As noted by the CERT in their vulnerability note:
“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.”
For the moment, the best way to minimize the impact of this sort of attack is to implement HSTS, which we’ll be discussing in more detail in a forthcoming article.