Slashdot Mirror
76% of Web Users Affected By Browser History Stealing
An anonymous reader writes "Web browser history detection with the CSS:visited trick has been known for the last ten years, but recently published research suggests that the problem is bigger than previously thought. A study of 243,068 users found that 76% of them were vulnerable to history detection by malicious websites. Newer browsers such as Safari and Chrome were even more affected, with 82% and 94% of users vulnerable. An average of 63 visited locations were detected per user, and for the top 10% of users the tests found over 150 visited sites. The website has a summary of the findings; the full paper (PDF) is available as well."
TFA describes a honey-pot based study. It doesn't describe a real-world study of people whose browser histories were actually stolen by actual malicious websites.
The English word fart is one of the oldest words in the English vocabulary.
According to http://hacks.mozilla.org/2010/03/privacy-related-changes-coming-to-css-vistited/ a future version of Firefox will address the :visited privacy issue.
One could also set layout.css.visited_links_enabled=false via about:config to disable :visited completely (at least until the issue is fixed in a future Firefox release).
No need for cookies, you just use javascript and CSS.
I actually implemented a history sniffer for an online advertising company a few years ago; we were using it as an additional selling point for potential advertisers, as in "We can tell you what percentage of your visitors have visited your rivals' landing pages".
Worth remembering you can only test against a list of exact urls that you're interested in, you can't just go browsing through a visitor's history. In other words, if I wanted to know how many pages you'd read on Slashdot, I'd need to test against every single possible URL.
Realistically that's pretty useless - I'd try to sell Ars Technica a solution that told them how many of their visitors have been to http://slashdot.org/. The obvious issue here is that neither I nor Ars Technica would need to get permission for this from either Slashdot or you; at the very least my product would need to give you an option to opt out.
this was on LWN a long time ago: http://lwn.net/Articles/350390/
http://blogs.msdn.com/ieinternals/archive/2009/06/17/CSSHistoryProbing.aspx is an article on the subject.
Essentially the vulnerability is a feature of the spec. Even without JavaScript or cookies, the CSS specification allows a web developer to specify that a particular icon/cursor/background-image should be shown for visited links. The exposure is that the client only downloads resources when they are needed to preserve bandwidth, and the server knows what has been requested from it, so I could put in then put somewhere in my css #google:visted { background: url("userwenttogoogle.png"); }
The problem is the only way to protect against the vulnerability is to remove features which are part of the spec (potentially breaking legitimate and standard compliant web pages), to download all resources (wasting lots of bandwidth), or putting the user in control (probably more annoying than useful as most users won't understand the dialog)
I don't think you're correct in your list of options for protecting against the vulnerability. As a general principal, client side code from an untrusted source (ie. the web) should only have access to client side content which originated from the same source. In the case we're talking about, the content has been modified by the client based on private client state (ie. visited links), at this stage, the content should no longer be accessible to the code. If the rendering pipeline were more compartmentalized (ie. think XSLT translation steps), then code in one department wouldn't have access to content that has been modified based on private client state.
In this manner, the client environment could modify the content at will (ie. changing style for links to web sites you've been to, blocking ads, stripping flash, turning off client side code functionality entirely, etc.) without fear of what's being harvested or inferred. I don't know what a client's browser does to a dom to make it consumable by the deaf or blind, but if that's something that can be detected by untrusted code then I believe it's another example of violating a user's privacy.
Here is a demonstration of the hack using only CSS: http://ha.ckers.org/weird/CSS-history.cgi You can also use: background: url"(logger.php?site=pornsite.com"); No need for the background to be a real image. This even works if you're using Noscript with Firefox.
I tried...I tried really hard and almost soiled myself with the effort, but I just can't care about my browser history being "stolen".
that's like calling my garbage being stolen every week when the big truck comes and takes it away.
Hell, the more time people spend stealing browser histories is time they're not spending doing something I do care about, so keep at it!
Not only that, it's not actually being "stolen". It's more like it's vulnerable to a game of "Fish". Sites can basically "query" your history looking for particular URLs, and the history will simply say "yes" or "no" to indicate whether a specifically requested URL is in the history.
So, yes, feel free to not give two shits, just like I do.
a#l15920:visited {background:url(/l?i=15920)}
with compaining HTML:
<a href="http://chickipedia.com" id="l15920">.</a>
That is, it loads a specific URL when a particular web page has been visited. So the detection is made by the browser, but the data is collected by the server as a purposedly side effect.