Browser History Sniffing Is Back

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

Comments

Easy work-around

[richkh]

Fixed cache size of 0.

Re:Easy work-around

[CastrTroy]

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

[icebraining]

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.

Re:Easy work-around

[zoloto]

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

[fuzzyfuzzyfungus]

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

[fuzzyfuzzyfungus]

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

Re:Easy work-around

[icebraining]

You might not care, but the guy paying for the server's bandwidth certainly does ;)

Re:Easy work-around

[KXeron]

There is a large difference between "user" and "customer", the problem is you may think that you are a "customer" (or at least potential customer) of every site you visit, but this is incorrect.

"Customer" implies that there is a business relationship in play, however if it is a forum or other free resource, you will never be a customer as there is nothing to purchase. Not every website on the internet is a business.

It is often seen as abuse when a user downloads or needlessly accesses a resource (files) multiple times and website administrators often have no qualms blocking abuse, it means less load on their site's server and more resources free (bandwidth, connection slots on the webserver daemon) for other users and on top of that: potentially lowering their bill.

Coming from experience, I've seen people use download managers and misconfigure them purposefully so they open 20-100+ connections to a file feeling that the website somehow owes them that file, doing so on a webpage with a browser is no different.

Javascript required?

[betterunixthanunix]

This appears to require Javascript. Thank you, noscript.

Re:Javascript required?

[danbuter]

NoScript should just be added in as part of default Firefox. It's very easy to manage, and saves me lots of headaches.

convincing implementation

[cachimaster]

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

Convincing to who? to you?

ACM was quite convinced back in 2000 when they published the paper.

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

Re:but you have to run their software to do it...

[lattyware]

Reality: Only a small number of users use NoScript et al. This is a problem for those that don't, and even if you do, what about when the site you want someone from requires JS?

without javascript

[Anonymous Coward]

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?

How

[farnsworth]

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.

Easy enough

[Baloroth]

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.

Re:jacked or tracked: it's your choice

[CapOblivious2010]

I've only gotten one internet virus in my life - via the "executable GIF" exploit, from visiting NVIDIA.COM !!!

If you think "reputable" means "safe", YOU'RE a few cards short of a full deck!

Better have good gag reflexes

[axlr8or]

Cuz if they wanna sniff my browser history they are in for a surprise.

Hard to block this

[rlk]

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

Re:You would think so...

[icebraining]

The script doesn't actually analyze the cache, just the time it takes to load the resource, so if your proxy's cache is fast enough it might still be detected.