Browser cookies were always a compromise. Surfing at its start decades ago was stateless: there was no connection between retrieving one page and the next. A cookie allowed a server (among other possibilities) to send a token that the browser could accept and then pass back with each subsequent request, allowing the server to create a session during which it could remember a browser. The compromise was that the continuity added by cookies also has the potential to cause privacy leaks.
A new attack on your privacy leverages browsers’ ability to allow third-party cookies, ones that aren’t delivered by the site you’re visiting, but used by scripts or content delivered from other sites. Third-party cookies most commonly get used by advertising technology that serves up scripts and other media hosted elsewhere, and employs cookies to track you.
However, it’s also used for less-invasive purposes. For instance, the University of California, Berkeley library system
requires third-party cookies to track the use of licensed resources through a proxy. Because of the ad-related use, however, browser makers added controls several years ago to disable third-party cookies at a user’s option. This sometimes breaks features on sites or renders them unavailable. Ad networks learned to work around the limitation, too.
This new attack argues for instantly disabling third-party cookies on all your browsers, enabling only as needed, and letting commercial websites cope with the consequences of people no longer accepting them. It won’t block ads, necessarily, and it won’t break delivering words and videos in most cases, but it’s long overdue. It’s the only current way to mitigate against an attack that’s eminently possible right now.
The researchers who discovered this flaw labeled it HEIST, a back formation from the title of the paper
they published and
presented at the Black Hat conference recently: “HTTP Encrypted Information can be Stolen through TCP-windows.” That may sound obscure, but it’s easy to explain. HEIST takes advantage of browser functionality across all modern browsers and every platform.
The TL;DR is that the exploit doesn’t let attacker impersonate you, but does let them extract private information that’s displayed at websites at which you haven’t logged out or which doesn’t expire cookies used to maintain sessions over short periods of time, including web email. This could include credit card numbers and medical conditions, but in the current formulation shouldn’t allow retrieving information about which something can’t be guessed, such as the length of a credit card number or the usual format of an email address.
The authors manage this attack without violating same-origin policy, a bedrock of the Web since the early days of graphical browsers. This concept prohibits scripts on a given web page from accessing content on a different server, or even the same server but through a different method. That means that a non-securely loaded http page can’t have a script that requests data from an https connection on the same server, as well as a script being unable to retrieve information from unrelated websites.
The point of this policy is to prevent a script from accessing other information that the user might be connected to without the user’s knowledge and permission. It also prevents a cross-site request forgery (CSRF), where a malicious web page runs a script that tries to carry out bank transfers and other behavior on unrelated sites at which you have accounts. Websites also have varying means to protect against this, but they rely in part on the same-origin policy in browsers for some of the enforcement.
HEIST makes use of newer, more efficient browser features and a newer form of the underlying Web protocol to make server requests it can’t read, but which it can analyze and measure to see the rough shape of what’s returned. It doesn’t matter whether the interaction is encrypted, either. By varying requests and using known information, the attack can retrieve a black box that it can shake and figure out what’s inside. Let’s say someone (unwisely) emailed you their credit card information to make a purchase on their behalf; HEIST could perform searches against your web mail host that ultimately revealed the number, expiration date, and validation code.
Crumble the cookies
The authors paint a fairly dismal picture of several attributes of the underlying communications protocols that allow this data to leak. Browser makers, websites, server software developers, and probably operating system creators will need to tweak a number of low-level attributes to reduce the potential for HEIST and other attacks to work. The authors note one problem has been known since 1996, so don’t hold your breath.
However, disabling third-party cookies is a big win, because while it doesn’t prevent a script from trying to retrieve pages from popular sites that you might have an unexpired session at, it does prevent including session tokens and other details in the cookies.
Each browser has a different default behavior, and settings are often inherited as you upgrade from version to version. It’s possible you turned on third-party cookie blocking years ago or disabled it, and you’re still in that state.
In Chrome, visit
chrome://settings/content and check Block Third-Party Cookies and Site Data. Chrome lets you work around restrictions at specific sites that require non-first-party cookies by clicking Manage Exceptions. In Firefox, visit
about:preferences#privacy, and select the History menu’s Use Custom Settings for History. Then under Accept Cookies from Sites in the Accept Third-Party Cookies pop-up menu, don’t pick From Visited (the same as Safari’s limits); instead, choose Never.
This exploit is both severe and weak at the same time: it can be easily weaponized into a tool that less-sophisticated attackers can use, and it’s most effective against the most popularly used websites (like Gmail and a few others) where malicious parties can predict the sort of information they might find and test to extract the details.
I expect the biggest websites to deploy their own solutions, looking for patterns of this behavior, which should be distinguishable, and protecting users silently. Given how easy it is to disable third-party cookies and close the biggest window of exploitation, I recommend making that change immediately.