Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Privacy Security IT

Browser History Sniffing Is Back 161

Posted by timothy
from the this-time-it's-interstitial dept.
An anonymous reader writes "Remember CSS history sniffing? The leak is plugged in all major browsers today, but there is some bad news: in a post to the Full Disclosure mailing list, security researchers have showcased a brand new tool to quickly extract your history by probing the cache, instead. The theory isn't new, but a convincing implementation is."
This discussion has been archived. No new comments can be posted.

Browser History Sniffing Is Back

Comments Filter:
  • Easy work-around (Score:5, Informative)

    by richkh (534205) <rkh-slash.nekomi@cx> on Sunday December 04, 2011 @06:38PM (#38261030)
    Fixed cache size of 0.
    • by CastrTroy (595695) on Sunday December 04, 2011 @07:44PM (#38261496) Homepage
      I do this all the time. My history is disabled by default. Cache is 0. I have never really had a need for history in the past 10 years. If I want to find something again, it's faster to just Google it. Or if I find something that I really don't want to lose, I just bookmark it. No reason to keep a history.
      • Re:Easy work-around (Score:5, Informative)

        by icebraining (1313345) on Sunday December 04, 2011 @07:53PM (#38261566) Homepage

        Cache and history are completely different features. 0 cache means you'll have to download the same CSS/JS/image files over and over again for each page on the same website, which is a waste of resources for both you and the server.

        • by zoloto (586738) on Sunday December 04, 2011 @08:21PM (#38261756)
          well, if sites would stop using so much garbage for simple content we wouldn't have this problem now would we?
          • Re:Easy work-around (Score:4, Informative)

            by icebraining (1313345) on Sunday December 04, 2011 @08:35PM (#38261838) Homepage

            There are plenty of cases where actual content - images, videos, etc - benefit from caching. It's not all garbage.

            • by houghi (78078)

              Proof of concept (and a bit more then that)
              http://www.google.com/images/nav_logo95.png [google.com]

        • Re:Easy work-around (Score:5, Interesting)

          by fuzzyfuzzyfungus (1223518) on Sunday December 04, 2011 @08:41PM (#38261886) Journal
          Completely different features; but not completely different datasets...

          If I'm trying to infer where you've been, a nicely formatted(often with handy metadata, timestamps, etc.) history list sure is handy, if I can get access to it; but it's also an obviously juicy target, and something that browser designers are going to try to keep me away from.

          Your cache is a lot messier; but it does provide grounds for inference about where you've been(and thus can retrieve from cache in essentially zero time) and where you haven't recently been(and thus have to burn a few tens to hundreds of milliseconds retrieving from a remote host)... Worse, unlike history(which is really just a convenience feature for the user, and can be totally frozen out of any remotely observable aspect of loading a page, those purple links aren't life or death...) the browser cache is an architectural feature that one cannot remove without sacrificing performance, and one cannot even easily obfuscate without sacrificing performance. It's a much lousier dataset than the history, since history is designed to document where you've been but cache only does that partially and incidentally; but it is one that is harder to get rid of without user-visible sacrifices and increases in network load...
          • Re:Easy work-around (Score:4, Interesting)

            by icebraining (1313345) on Sunday December 04, 2011 @09:12PM (#38262074) Homepage

            You wouldn't need to eliminate the cache, just Javascript's ability to measure the load times reliably. For example, you could prevent scripts from reading the state of a particular resource during the e.g. 500 milliseconds after setting its URL, regardless of the source used (cache or network).

            • Re:Easy work-around (Score:5, Informative)

              by fuzzyfuzzyfungus (1223518) on Sunday December 04, 2011 @09:24PM (#38262120) Journal
              You'd also have to ensure that page elements don't load in any deterministic or controllable order, and that the number of requests the browser has going concurrently isn't predictable: If I can control the order in which your browser loads my page's elements, I can make useful inferences about the load time of a 3rd party resource, without any client javascript, by sandwiching its loading between the loading of two resources(at dynamically generated URLs, to ensure that you couldn't possibly have cached them) on servers I control. Not perfect, because various other factors could affect the time it takes your requests to hit my servers; but likely better than nothing.

              It would also be a bit tricky because inferential attacks wouldn't necessarily have to ask politely for the state of the resource they are interested in, they could instead attempt something else(say a script operation that will fail in a particular way unless the 3rd party resource is available). Barring a solution much cleverer than I can think of, you'd be at considerable risk of having to break progressive loading of pages entirely(or at least into human-visible-and-annoying stuttery chunks) in order to keep prevent a combination of a page interrogating its own state on the client, and correlating with timestamps on requests to servers controlled by the attacker...
              • Here's an idea to kill the cache attack, have cache loading speed simulate the network connection speed: Have the browser gather stats on its network use. Say the average load speed (call it AVGSPD) is 100KBps and the average lag (call it AVGLAG) is 0.5s. If it's about to load a big 500KB image from cache, it first introduces a delay of AVGLAG*random(0.5,1.5), and then an additional delay of FILESIZE/(AVGSPD*random(0.9,1.1)), so fetching the file would take somewhere around 5 seconds. This simulates the slo

            • by CastrTroy (595695)
              Or even better, always load something from the website when the content is third party. So if you're visiting random site, and they get you to load facebook content, then it would never look in your cache. There really would be some adjustments needed, to help with CDNs (content distribution networks), but that could be solved. Allow the browser to load anything from a subdomain from cache, but content that is from an unrelated domain always loads from the web. If you are using a CDN, just use a subdomai
        • by pscottdv (676889) on Sunday December 04, 2011 @10:28PM (#38262404)

          But according to how this exploit works they are not "completely different". They, in fact, have a small overlap. Apparently the exploit works by using JavaScript to load a file from a website and see how fast it loads. It infers you have been to a website if the file loads quickly.

          They seem to have a trick to stop the process just before the browser puts the loaded file into the cache which prevents it from poisoning the very cache it is "testing".

          Thus, setting cache to 0, which the OP recommends, and which I have been doing for years, is exactly the fix needed. I admit that I do not know he also disables history, as that would not help with this exploit.

        • by lpq (583377)

          Except that if you read the article, it targets your cache, not your history.

          It just tries to load various sites to see if they load quickly or not. If yes, then in local cache, else not. Thus used as how recently you have visited site (it it still in cache).

          History -- i keep that going back about 240-360 days... much faster and more useful than google.

          I mean if I wanna go to a site, why would I go to google rather than typing in a few letters of the site, -- and it knows which ones I visit most... all s

        • by al0ha (1262684)
          So what? My personal box is nowhere near tapped out, I've been doing this since I got my first broadband connection and originally on a single core. And who gives a rats a** about the remote server resource useage?
      • Re: (Score:3, Funny)

        by Anonymous Coward

        If I want to find something again, it's faster to just Google it. Or if I find something that I really don't want to lose, I just bookmark it. No reason to keep a history.

        If your ultimate purpose was more privacy, I find it VERY amusing that you ended up willingly sharing everything with Google, of all parties. :D

        • There's a browser plugin you can use to anonymize Google queries, although if you signed up for a Gmail account in a more innocent time like I did and haven't migrated to your own hosting yet, the best thing you can do to reduce your Google footprint is to open your Gmail/Google Reader/Youtube/whatever pages in a separate browser from everything else. Firefox could use "tab sandboxing" - where individual tabs can be like their own private browsing session, basically. I think Chrome has something like that.

    • Yep, but first install a Squid proxy on an internet-facing machine and then set all internal browsers to proxy through it, then set all browsers to use a cache size of 0.

      • Re: (Score:3, Informative)

        by Anonymous Coward

        If I correctly understand how this attack works, they could easily read your proxy cache the same way.

      • by Pieroxy (222434)

        How will that prevent this exploit? It could is your proxy is not faster that your internet connection... but what purpose would your proxy serves then?

  • Unreliable (Score:3, Informative)

    by cpicon92 (1157705) <kristianpicon@gmail.com> on Sunday December 04, 2011 @06:41PM (#38261048)

    This tool seems unreliable (at least in Chrome). I've been on YouTube five times in the past 48 hours and it still showed up grey on the sniffer.

    • Re: (Score:2, Funny)

      by Anonymous Coward

      This tool seems unreliable (at least in Chrome). I've been on YouTube five times in the past 48 hours and it still showed up grey on the sniffer.

      Most likely an OS/Vendor issue.

      If you're using a Mac, pretty much every sniffer tool will show up ghey.

    • by Hentes (2461350)

      Yeah, it's too inaccurate to be convincing. A random algorithm weighted on popularity could have a similar success rate. Maybe if the number of tested sites were increased it would be more clear whether it works or not.

  • Not surpisiing (Score:1, Insightful)

    by Anonymous Coward

    Browser developers are not doing proper development anymore. They are too busy playing stupid games like hiding http://, removing status bars, inflating the version numbers and breaking your extensions to do things like security or proper memory management.

    • Hard to block this (Score:5, Interesting)

      by rlk (1089) on Sunday December 04, 2011 @08:36PM (#38261844)

      This kind of timing attack isn't easy to block.

      Some kinds of timing attacks are. I think I heard once that a timing attack could be made against passwords in TOPS-20, because the passwords were stored in plaintext and compared one character at a time. The trick was to do the system call to check the password (or whatever it was) with the guess split across a page boundary (maybe the second page was forced out of memory or something). Since the system call would return as soon as one character didn't match, it was easy to see if the next character being guessed was correct or not. The fix was simple enough. Obviously there was a bit more to it than that, but I only heard this apocryphally as it was, and at that probably about 25 years ago.

      This kind of thing is harder to fix, since it depends upon the difference between cache and non-cache access time, and the non-cached access time is not deterministic. It would be possible for the browser to introduce an artificial delay into the appropriate JavaScript calls, but that would make performance go down the tubes.

      In any event, I tried it and the results didn't look very accurate (the first time, all of the sites it tried claimed that I had hit them; the secon time it caimed only one site was in cache, and after that it thought that nothing was).

  • Javascript required? (Score:5, Informative)

    by betterunixthanunix (980855) on Sunday December 04, 2011 @06:47PM (#38261094)
    This appears to require Javascript. Thank you, noscript.
    • by danbuter (2019760) on Sunday December 04, 2011 @07:17PM (#38261298)
      NoScript should just be added in as part of default Firefox. It's very easy to manage, and saves me lots of headaches.
      • by inzy (1095415)

        ...and it confuses the hell out of a lot of people who don't understand what javascript is. "I just want to see the webpage"

        Rather than trying to get people using what is frankly an arcane and imprecise tool, we would be better off removing the incentive which makes data theft valuable. This then becomes and economic and social problem rather than technical. there are few situations where the latter can be solved well with the former

        • by hedwards (940851)

          I ended up replacing it with request policy as half the time I ended up having to enable all the javascript to get the page to load anyways. I mostly just wish it provided a method of blacklisting things like Facebook that never add any value to the site.

      • by bussdriver (620565) on Sunday December 04, 2011 @08:35PM (#38261840)

        YES! I 2nd that! But it should be better integrated and off by default -- they can try to hint users into using it by other means. I have NoScript on by default just because I was sick of white listing everything; but any site I feel bad about I blacklist. Its not as secure but it is doing something. Add a subscription list like AdBlock has and it wouldn't be so bad for people who want to help compile black and white lists. Normal users would get a blacklist with it always on by default and others who know better will know enough to flip the policy. The paranoid would turn off the subscription lists and do it all themselves.

        I would like a power-user area to block certain DOM features completely. I do not trust canvas by default or most the newer DOM features by default; it should ask me to ok those when a site tries to use them. (the lists mentioned above could specify what is white or black listed not just whole domains etc.) Actually, I'm wary of CSS3 fonts because font render engines haven't been a focus of security and 3D drivers... you are lucky to have stable fast 3D; security? currently a pipe dream.

        A DOM js access list by domain would be a lot like a sandbox system for websites.

      • by TubeSteak (669689) on Sunday December 04, 2011 @08:58PM (#38261986) Journal

        It's very easy to manage

        I've installed NoScript for non-technical people and it almost immediately caused them headaches.
        There are plenty of internal academic/work websites that rely on fetching scripts from third parties...
        Which is exactly what NoScript is designed to prevent.

        And then there are endless websites that want you to allow scripts from a CDN or Google APIs or social bookmarking.
        NoScript's generic default allows aren't inclusive enough to keep websites from breaking for most people.

        • by hedwards (940851)

          I've noticed that. When I'm using noscript I tend to spend most of my time enabling things on sites as I often times can't even see the site. I've found that request policy is a lot easier to use in many ways, but unfortunately lacks any sort of black list so you're limited in what you can do as far as blocking portions of a site's javascript collection.

        • by Arker (91948) on Sunday December 04, 2011 @11:34PM (#38262678) Homepage

          And this wont stop as long as most people are stupid enough to accept browsers that will just run whatever random script some random website hands them. Unfortunately, it's a bit of a chicken and egg problem in that way. If the major browsers would behave sanely, these insanely bad web practices wouldnt work, and the insanely bad 'web designers' that come up with them would have to learn to write real web pages or find another line of work. As is, too many people dont know and dont want to know, and we all pay the price in one way or another.

          I'll keep my noscript and be happy that broken pages actually display as broken for me, so I know to avoid them, rather than having my browser just randomly download and execute whatever crap codes the broken web page needs to make it look like something else.

      • It's definitely not easy enough for the average user. My dad's better than average with computers and he struggles with it sometimes.

    • by swillden (191260)

      This appears to require Javascript. Thank you, noscript.

      It doesn't, really. This proof of concept is implemented using Javascript, because it's easier, but the basic concept doesn't require Javascript to work.

      • How do you observe download timings without Javascript?

        • by swillden (191260)
          Sandwich them between requests to a real server, which you control. Network latency jitter would make the attack less reliable, but I'll bet it would still work reasonably well. Better if you have a low-latency path to the target. ISPs could probably implement it with very high reliability.
          • How does that work considering that most browsers download resources in parallel (even if they actually load them to the page in order), particularly from different domains?

            • by swillden (191260)

              There's a limit to the number of resources they'll download in parallell; it would probably be necessary to saturate that first. In fact, filling up all of the available download slots might really help -- request a bunch of resources from a server that will respond to the connection request but not complete it. Then the attacker could start timing from the instant the server completes the pre-timing request, then stop when the server receives the post-timing request. Some similar methods could be used t

              • Doesn't that assume the page controls the total pool? My Firefox instance has eight established connections; with Ajax or background loading tabs, it's hardly unexpected that some other website will take over the only available socket, making a cached load appear as slow as a remote request.

                • by swillden (191260)

                  Mmm, yes, I was assuming there's a pool per tab. With Chrome, since each tab is a separate process, I'm pretty sure that's the case.

                  I don't think that's an insuperable problem, though. The attacker can just watch the requests that are supposed to saturate the pool coming into the server, and if they stop arriving he can assume the pool is full. At that point he knows how large the available pool is, factoring in other connections already established, and can "release" enough connections to allow the pa

  • by cachimaster (127194) on Sunday December 04, 2011 @06:47PM (#38261098)

    The theory isn't new, but a convincing implementation is.

    Convincing to who? to you?

    ACM [acm.org] was quite convinced back in 2000 when they published the paper.

    They obviously implemented it because it contains a lot of measurements.

    • by osu-neko (2604)

      The theory isn't new, but a convincing implementation is.

      Convincing to who? to you?

      ACM [acm.org] was quite convinced back in 2000 when they published the paper.

      They obviously implemented it because it contains a lot of measurements.

      Convincing to browser developers, obviously, who moved to fix the other problems fairly quickly but have, to date, done nothing about this one.

      And obviously, yes, they implemented a method for doing this back in 2000 for that paper. It's what's being referred to when the author notes, "Such attacks were historically regarded as fairly impractical, slow, and noisy - and perhaps more importantly, one-shot." What we have now, though, is a method that is fast, practical, and nondestructive.

      • by Hentes (2461350)

        Convincing to browser developers, obviously, who moved to fix the other problems fairly quickly but have, to date, done nothing about this one.

        Are you kidding me? The CSS visited link vulnerability took ages to get fixed.

        What we have now, though, is a method that is fast, practical, and nondestructive.

        It's too inaccurate to be practical. Try it.

  • without javascript (Score:4, Interesting)

    by Anonymous Coward on Sunday December 04, 2011 @06:57PM (#38261166)

    They say it can work without javascript, but I do not believe that. None of the samples work without javascript. In the paper, it says:

    We omit the straightforward but tedious details of how to write HTML that causes popular browsers to make serialized accesses to files.

    Can anyone provide this tedious, but allegedly straightforward, and extremely critical detail?

    • by Anonymous Coward

      HTML is typically rendered in the order that it is read, therefore its possible to know that A is requested before B etc
      With that in mind you can sandwich your request to twitter between two dummy requests to a server that you control.
      Server compares the timing on the dummy requests and can guess the timing for the real one.

      • by Bogtha (906264)

        There's a little more to it than that. Browsers open multiple connections in parallel. Historically, this was limited by the HTTP specification to two simultaneous connections, but recent versions of browsers have increased this limit. You'd have to detect how many simultaneous connections were in use (or hack it by detecting the browser) and make requests to enough tarpits to bog down all but one of the connections. It would probably be fairly reliable, but the work to build that just to demonstrate t

    • by Anonymous Coward

      Wow, I was wondering the same thing, then I found this -

      http://whattheinternetknowsaboutyou.com/docs/details.html [whattheint...outyou.com]

      Skip down to the CSS section:

      <style>
      a#link1:visited { background-image: url(/log?link1_was_visited); }
      a#link2:visited { background-image: url(/log?link2_was_visited); }
      </style>
      <a href="http://google.com" id="link1">
      <a href="http://yahoo.com" id="link2">

      The background-image is only loaded on the visited state...

  • How (Score:5, Informative)

    by farnsworth (558449) on Sunday December 04, 2011 @07:19PM (#38261314)
    This seems to work by loading well-known resources into an iframe and using a heuristic of the "time to load" to tell if it's cached or not. Hence, whether or not you have visited that site. I just scanned the source code, but this is what it looks like. It any case, it's not like this code reveals your history -- just whether or not your browser has visited one in a set of popular sites.

    Yay stateless web.
    • It seems like you could add a random delay of up to a couple hundred milliseconds before the browser reports that an iframe has successfully loaded, making it harder to tell by the timing.

      • by Korin43 (881732)

        Except that would make JavaScript slower, which is the exact opposite of what the browser makers are going for.

        • by bigtrike (904535)

          Yes, it definitely would. You could certainly limit the scope to only apply to cross domain queries for out of viewport/small/hidden iframes, but that still might cause slowness issues for legitimate uses.

    • by mapkinase (958129)

      1/ actually read the article
      2/ post cliff notes about it
      3/ points

      Works like a charm.

      Now on topic: I clicked and it shows nothing because of my OCD: Ctrl-Shift-Del, Enter.

  • by pla (258480) on Sunday December 04, 2011 @07:23PM (#38261342) Journal
    Subject says it all. I don't worry about cookies, cache, or malicious scripts (other than wastes-of-bandwidth) because every time I open FireFox, it looks shiny and new to the outside world.

    When I visit a "sensitive" site, like my bank, I open a new browser session and close it when I finish. Aside from that, I just don't worry about it, and have never had a problem. Hell, even that great data-mining wizard Google - My home page and probably the single most frequent site I hit - Always defaults me to Georgia (presumably the location of my ISP's HQ), missing by over a thousand miles.
  • Easy enough (Score:5, Interesting)

    by Baloroth (2370816) on Sunday December 04, 2011 @07:28PM (#38261374)

    Tried the test for Opera, and it mostly worked (missed Newegg). Tried it in a private tab, didn't work at all. So, any site you don't want tracking you you load in a private tab. Which you should anyways.

    Out of curiosity, I also tried the FF test (in Opera, still) and the IE test. The IE worked, better even than the dedicated test, while the FF test failed utterly. Curious.

    And of course, as always, this test only works for the specific sites you test for, not generally. But that isn't surprising. Wasn't terribly fast, either, I'd certainly notice if you tested for hundreds or thousands of sites.

  • Alt-t, d, enter (Score:3, Interesting)

    by Anonymous Coward on Sunday December 04, 2011 @07:42PM (#38261476)

    It's a dutch boy's thumb, but that quick key-combo clears history in Opera. I just habitually hit it between domains to kill tracking without screwing up sites that need cookies or js to function. Likely there's a Firefox equivalent.

    What neither has by default is a way to do this automatically. Browser makers finally got around to letting us limit cookies to the visited site, but they could go much further.

    Like just rig browser cache to be per domain -- there's no need for all domains to share the same cache.

    Maybe it's the festish for 'fastest' browser? It just seems the makers aren't doing what can be done easily enough on modest modern machines to improve privacy.

  • by Hentes (2461350) on Sunday December 04, 2011 @08:00PM (#38261626)

    While this specific implementation is very inaccurate, others using a similar method may work. An obvious workaround to these kind of attacks is to turn off caching, but that would increase loading times. I was wondering if there was a hack in some browser that would allow you to ban a site from using resources from another domain, whether it's by HTML or scripts. Does anyone know such a solution?

    • Re:A possible fix (Score:4, Informative)

      by _0xd0ad (1974778) on Monday December 05, 2011 @12:03AM (#38262784) Journal

      AdBlock Plus lets you do that very easily.

      e.g.
      Block fsdn.com on third-party sites except slashdot.org
      ||fsdn.com^$third-party,domain=~slashdot.org
      Block fbcdn.com on third-party sites except facebook.com, facebook.net, and fbcdn.net (write similar rules to block the other 3 facebook domains)
      ||fbcdn.com^$third-party,domain=~facebook.com|~facebook.net|~fbcdn.net

      • by Hentes (2461350)

        Yeah blocking individual sites is possible, but imperfect from a security perspective.

        • by _0xd0ad (1974778)

          By which you mean it's limited to a finite number of sites?
          The number of sites they can check for is also finite.
          The number of sites in my history/cache is also finite.

          Note currently it's "yes" or "no", and "no" is indistinguishable from "blocked". They could make it slightly more reliable if they actively checked to see if I was blocking (e.g. Grooveshark pops up a warning box if it can't load the facebook integration).

          • by Hentes (2461350)

            While it's possible to create a rule for every site you visit, it is impractical. The number of sites they can check is irrelevant, because you don't know which sites they will be testing for. The number of sites in your cache can be limited, but what sites are in it changes constantly.

            • by _0xd0ad (1974778)

              You'd probably think it impractical to go through the history and click "Forget About This Site" for sites which you don't want it remembering you visited. Which, in my case, is most of the sites I don't frequent.

    • Other possible fixes:

      • Add random delay when loading things: probably too much of an impact on loading times to be used
      • Don't let scripts measure the passage of time while loading: awkward, but at least it has a low impact on other things; you'd also have to randomize the order in which things load to prevent an outside server from acting as a clock
  • by axlr8or (889713) on Sunday December 04, 2011 @08:35PM (#38261842)
    Cuz if they wanna sniff my browser history they are in for a surprise.
  • I ran this "test" three times in succession. First go it showed sites which yes I might have been to though one, Dogster I was fairly certain I had not. I then clicked it again and this time it came up with almost every site in green. Running a third time gave the same results as the first attempt.

    • by gl4ss (559668)

      well, running safari it did get that I had visited slashdot.

      going to facebook, it for some reason thought I had gone to twitter though.

      (I know there's no "safari" version there, but the ie version did that)

  • by Anonymous Coward

    I'm using Linux and I'm trying the same thing that I do with Adobe Flash... I /dev/null it...

    cd to .mozilla/firefox/xxxxxxx.default (replace x's with your specific alphanumeric string)
    rm -rf Cache (deletes Cache dir and all subfolders)
    ln -s /dev/null Cache (creates symlink of Cache to /dev/null)

    Since nothing escapes the event horizon that is /dev/null, your Cache is written but cannot be inspected by others seeking to pry into your well-deserved privacy.

    So far, so good. I have noticed no slowness by doing t

  • Convenience comes at a price.
    You can buy your bread and butter at the local grocery with all your neighbors watching.
    Or you can disguise and go to the other end of town, which takes time and increases traffic.
  • It seems to me there's an easy way to make browsers immune to this: Introduce random delays when cached resources are fetched from other sites via JavaScript.

    In a well-designed web-page, the static (i.e. cached) resources are referenced in the html (often in the headers) and not subject to timing attacks as they can be fetched in random order.

    When something is requested dynamically via JavaScript it is typically not the cache anyways, so there is rarely a performance penalty.

    When there is a performance pena

"Free markets select for winning solutions." -- Eric S. Raymond

Working...