Security

Leaking browser history

Browser history is fairly sensitive information for most people. If there were a way for random web sites to grab a list of other sites you have visited recently, it would cause a fair amount of concern. Unfortunately, a longstanding problem in the HTML Document Object Model (DOM) makes for an information leak nearly as bad as that.

The problem stems from the handy feature that browsers implement to show you which links you have already visited. The way that they show links in a different color if you have visited them is by turning on the "visited" style for the link. Many sites, such as LWN, then change the default colors for both visited and non-visited links via the site's Cascading Style Sheet (CSS). This information gets recorded in the DOM for the page which can be queried from Javascript.

Because of the nature of the leak, scripts cannot get a full dump of the browser's history, but they can get the visited status for a set of sites they are interested in. A web site that wishes to gather this kind of information need only add a link to each site of interest—often in an unreadable font size or color—and send over a bit of Javascript to read the DOM status for each link.

While this problem has been known since at least 2002, there is no easy fix while still being compliant with the CSS standard. Because of that, most or all browsers are vulnerable. It has recently been in the news because it is being used in a benign, or at least semi-benign, way.

These days many news sites and blogs have small images that correspond to various social networking sites—digg, reddit and the like—that allow voting on particular stories or postings. Those images are buttons that register a vote or submission of the site that displays them. With the proliferation of these sites, a great deal of screen real estate was being taken up by these icons, many of which were not useful because the person viewing them never visited those particular sites.

To reduce the clutter, Aza Raskin created some Javascript code to determine which of the social networking sites a particular user had visited so that only the icons for those sites were displayed. Many people would find that to be a useful hack, one that was fairly minimally intrusive, which it is at some level. Others, with a more strict personal privacy desire, might find it more than a bit creepy.

Reducing clutter is one thing, but this technique can be used to gather much more sensitive information than which of the many social networking "news" sites you visit. It is tempting to remind readers of the NoScript Firefox extension, but it has become increasingly difficult to do nearly anything on the web without enabling Javascript. Many sites essentially hide their content behind a Javascript test, refusing to display it unless Javascript is enabled.

This makes it difficult to avoid giving away some of your browsing history to dodgy sites—or those with cross-site scripting vulnerabilities—other than by avoiding them entirely. It is an unfortunate side effect of a useful property that, as the discussion on the Mozilla bugzilla shows, will be difficult to completely eliminate. It should be noted that the links do not have to be obfuscated—by adding a dash of Javascript LWN could know whether you have visited digg or reddit. But, of course, we don't force Javascript on our readers.

Comments (25 posted)

New vulnerabilities

clamav: denial of service

Comments (none posted)

fetchmail: denial of service

Comments (none posted)

gallery: multiple vulnerabilities

Comments (none posted)

horde: cross-site scripting

Comments (none posted)

IBM JDK/JRE: multiple vulnerabilities

Comments (none posted)

kernel: information disclosure

Comments (none posted)

kernel: information disclosure

Comments (none posted)

kernel: denial of service

Comments (none posted)

nasm: off-by-one error

Comments (none posted)

phpMyAdmin: cross-site scripting

Comments (none posted)

ruby: multiple vulnerabilities

Comments (none posted)

sblim: arbitrary code execution

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>