Popular browsers made to cough up browsing history | Cyber Security
Anonymous Coward, in commenting on a report from The Register about vulnerabilities that expose people’s browsing histories, pithily sums up potential repercussions like so:
Sweetheart, whats this ‘saucyferrets.com’ site I found in your browsing history?
If you value your privacy and your ferret predilections, be advised that in August, security researchers from Stanford University and UC San Diego presented, during the 2018 USENIX Workshop on Offensive Technologies (WOOT), four new, privacy-demolishing attack methods to get at people’s browsing histories.
The novel attacks fit into two classic categories – visited-link attacks and cache-based attacks – and exploit new, modern browser features such as the CSS Paint application programming interface (API) and the JavaScript bytecode cache: two examples of evolving web code that don’t take privacy into account when handling cross-origin URL data, the researchers say.
So-called history sniffing vulnerabilities are as old as dirt, and browser code has addressed them in the past. Here’s a paper written on the issue back in 2000, and here’s a Firefox bug reported that same year about how CSS page disclosure could let others see what pages you’ve visited.
Old or not, common web browsers – Google Chrome, Mozilla Firefox, Microsoft Edge and Internet Explorer, and Brave – are all, to greater or lesser degree, affected by the new methods of sniffing, the researchers say.
Even most of the security-focused browsers they evaluated – they looked at ChromeZero, Brave, FuzzyFox and DeterFox – coughed up browsing histories in the face of two of their attacks. The Tor Browser alone stood fast against all four attacks: not surprising, since it doesn’t actually store users’ browser histories.
These attacks weren’t just “effective;” at least one of them was sizzling. One of the visited-link attacks – CVE2018-6137, a bug in Chrome 67 that Google fixed in June – peeled off user browsing history at the rate of 3,000 URLs per second. The vulnerability allowed an attacker to figure out whether a link had been visited by using the CSS Paint API to check if a “paint” method – used to change the color of visited links – had been invoked.
Google fixed that one, but that leaves three of the vulnerabilities, as Deian Stefan, assistant professor in the UCSD computer science and engineering department, told The Register. Stefan said the remaining flaws are timing-side channel attacks, which makes them “considerably less severe” than the CSS Paint API attack.