Disable third-party cookies as a hedge against a new browser-based attack

[Batu69]

It's not about ad blocking, but rather an unintended consequence that you can mitigate.

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.

Ocean’s 00000011

The researchers who discovered this flaw labeled it HEIST, an 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.

 

JavaScript becomes more and more sophisticated each passing year because of the desire to run powerful, interactive Web apps in desktop and mobile browsers. In some cases now, it’s almost impossible to tell the difference between a Web app and the corresponding native version on the same platform. But more power brings more risk.

 

The paper’s writers, Mathy Vanhoef and Tom Van Goethem, make use with HEIST of newer browser features that improve how scripts can communicate interactively with servers, and that let developers time the performance of interactions. By sending a series of carefully crafted requests via a script that loads on a page the user visits, HEIST can extract an enormous amount of information about the page’s content. (Attackers using HEIST can get people to a malicious page via phishing techniques, or they can inject malicious JavaScript onto unsuspecting blogs and company sites through advertising networks that allow self-service ad purchases.)

 

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.

 

None of this requires malware to be installed: just visiting a malicious page can allow JavaScript to run that can carry out these tasks in the background for any site for which you have account information cached in the form of cookies for logging back in from the same browser.

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.

 

To block a new exploit, set Block Cookies to Allow from Current Website Only. Allow from Websites I Visit is the default.

 

 

In Safari for OS X (Safari > Preferences > Privacy) and iOS (Settings > Safari > Block Cookies), Apple has mingled a couple of different states. Allow from Websites I Visit, the default in both my browsers, prevents third-party cookies, but passes cookies from sites you’ve ever visited before that have deposited cookies. To deal with this exploit, set to Allow from Current Website Only, which disables all third-party cookies from being sent; otherwise, you’re in the same boat as if no protection were enabled, since the exploit only uses cookies from sites you frequent.

 

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.

 

Article source