Please read my blog's comment policy here.
BackgroundOne of the interesting attacks which makes the rounds every few years concerns the ability of web pages to use CSS to detect whether or not certain URLs have been visited. Given a sufficiently large set of URLs to probe, a website may be able to develop an interesting profile of where your browser has been.
You can try a simplistic demo of this here: CSS History Probing. The demo should (see comments) used to work in pretty much any browser.
ImplicationsThe security and privacy implications of this design vulnerability are obvious, and clever folks are finding more and more ways to take advantage of it.
It's been suggested that phishers could use this technique to determine where you bank and select the most appropriate phishing site when you visit their "uber" phishing page. (Of course, if my inbox is any guide, most phishers are content to blast everyone with every phishing attempt).
At HITB2008, Jeremiah Grossman said his research showed that advertisers and marketers are the only folks using this trick broadly; when you visit CarCoA, for instance, they're probably very interested in knowing whether you're also shopping at CarCoB. Similarly, a banner advertiser provider could show more relevant ads by probing for visits to a few top sites (e.g. sports, entertainment, news, etc) to determine a "good-enough" demographic profile of the viewer's age, location, and interests.
Beyond Evil.com and Madison Avenue, there are even some useful scripts that use this information leak in non-malicious ways.
LimitationsThis vulnerability is subject to a number of limitations, the most important of which is that the attacker must correctly generate the exact URL that the user has visited. So, for instance, an attacker can easily detect that you've visited Bing.com to perform a search, but it's much harder for him to detect what you searched for, because he would have to probe every possible search query (or at least, all queries he's interested in detecting). Additionally, the information leakage is limited by the duration that the browser is configured to retain history, and other factors I'll cover in the next section.
Fixes and MitigationsAs with any vulnerability that has been around a while and has received lots of exposure, a great many "fixes" have been proposed. Unfortunately, as is usually the case, most are non-starters for one reason or another.
Visited Links are completely disabled while you’re InPrivate. If you visit your “trusted” sites while InPrivate, those sites are not added to your history, so effectively a partition has been created:
The architects of CSS clearly had the best of intentions, as highlighting visited links can help users more easily navigate a site. Unfortunately, this useful feature had some unexpected consequences when exposed to clever web developers in the real world.
Trying to correct design vulnerabilities after the development and deployment of products based on the design is incredibly difficult, because compatibility and user-experience regressions inevitably ensue. As a result, design vulnerabilities often remain unaddressed or partially mitigated for years, as has happened in this case.
As the web platform grows more powerful, it's critical that architects and browser developers detect and remediate design problems before standards are ratified.
Interesting security flaw. Of course there's another solution. If the browser didn't try to be as smart, and just prefetched all urls referred to in the css then the attacker wouldn't know if they had actually visited the site or not.
Even with pure CSS, however, it would probably still be possible to execute the attack unless the user is willing wait forever for pages to load, because the CSS could be made to take nearly forever to run.
Pretty cool test page for this probing: http://www.whattheinternetknowsaboutyou.com/top20k
A future version of Firefox is taking a swipe at this problem by disabling all styling of :visited other than color.
IE9 Release Candidate has adopted CSS styling restrictions, interoperable with the protections introduced by other latest-version browsers. blogs.msdn.com/.../ie9-release-candidate-minor-changes-list.aspx