

History theft with CSS Boolean algebra - afreak
http://lcamtuf.coredump.cx/css_calc/

======
heydenberk
There are a bunch of these exploits — I remember one a few weeks ago that
posed as a mind-reading survey — and I think they can only be well and truly
solved by a same-domain policy for :visited links. In short, don't apply
:visited styling to a link unless that link is the same domain as the host
page. This is the general security model on the rest of the web and it'd work
here.

~~~
pornel
or better, have separate visited database per origin (i.e. rather than
tracking state of `url` track state of `(url, origin)` tuples). This way e.g.
links visited from HN would be marked as visited on HN and _on HN only_.

It wouldn't disclose any information the site can't already get by tracking
clicks.

~~~
gavinpc
How does this differ from "a same-domain policy for :visited links"?

~~~
sejje
Because it wouldn't mark the links on the HN front page as visited if it were
a "same-domain policy."

The origin policy fixes that.

------
thegeomaster
Considering the work needed by the website to convince the user to give away
the data, and even with approaches like described with the article, we may be
overestimating what websites could learn of us by checking if we've visited
some random 2, or 4, or 15 sites.

Yes, it's an invasion of privacy and has to be sanitized, but it's not like
that websites can see all of your history, view it in chronological order, or
know if you've visited this link 6 months ago or today. And plus, you need to
make the user somehow disclose what he sees on the screen, which may often
look suspicious.

And what would an adversarial website do with these {visitedlinks, IP} tuples?
Hit me with personalized ads or sell that modicum of my history to some ad
company? Big shit, I hit the reset button on my router, and I get a new
dynamic IP address from the ISP. The site now knows nothing.

These work more as proof-of-concepts. The inconvenience they require to be
collected, paired with the limited utility of the results, makes for an
unattractive attack vector.

I agree that if someone wants to target specifically you and knows something
about you, they can put this class of exploits to a more threatening use, such
as (if you're at work) seeing if you've visited some company LAN URL. Or
perhaps they can see if you've accessed the admin pages on some website
they're targeting, so they can determine if you have admin rights there.

~~~
dfabulich
The canonical use of history stealing is to find exploits in a bunch of
websites (e.g. online banks), then use history stealing to find customers of
that site.

A number of attacks against, e.g. banks seem implausible ("but how would the
attacker know that I bank at Wells Fargo?") until you learn about history
stealing.

~~~
gizmo686
Why do you need history stealing for that. If you have an attack against Wells
Fargo, why not launch it on everyone you can. You will get at least as many
Wells Fargo users as you would if you pre-filtered (probably more because of
false negatives).

~~~
grrowl
But a phishing site such as "HTTPS-SECURE.required-bank-security-
check.gmkla4lwgi.com" [hypothetical] could easily check for the most popular
bank institutions in a user's history using this exploit and present them with
the appropriate, familiar login dialog they'd expect.

You'd easily increase the amount of victims (conversions?) several times over.

~~~
coldpie
You could also use it to identify high-value targets. Make a popular webpage,
and make a record of all users who have visited internal.nsa.gov and the like.

------
epmatsw
Oh neat, I thought this was broken at first since it said that I hadn't
visited news.ycombinator.com. Then I remembered that after seeing a similar
(though less clever) exploit a few weeks ago, I'd changed Firefox to not show
visited styles. I'd call that a success.

------
erikano
>[...] for those using non-WebKit browsers, here's a slightly modified version
that will do the trick for you [...]

All four are grey in Firefox for Android.

~~~
rockdoe
Same in desktop Firefox. Does the attack not work against Firefox or did he
mess up the CSS?

~~~
tripzilch
I'm assuming he just didn't thoroughly test the Firefox version of this
exploit.

In theory it can be made to work, the browser has to have some kind of
rounding mode for opacity.

It could be solved by making the up/down rounding random.

------
tripzilch
Wow. Lcamtuf is such a king of side-channel attacks.

Using opacity quantization/rounding errors to get around CSS :visited
restrictions ... crazy brilliant.

