Re: Subresource Integrity and fingerprinting

> http://w3c.github.io/webappsec/specs/subresourceintegrity/#recommendations-1

Hm, not sure we're talking about the same thing? That deals with
integrity cache, which isn't my concern. The attack I'm worried is
what you describe in section 6.3, but implemented with the specific
goal of obtaining cross-domain secrets that have a reasonably small
search space. So, let's say:

1) https://www.example.com/homepage.html is a document that looks like this:

<html>...<h1>Hello, $first_name!</h1>...</html>

...where all the content except for $first_name is static, and
$first_name is the given name associated with the user profile, as per
existing session cookies of the user.

2) I set up an evil page in another origin, and precompute hashes of
homepage.html with 10,000 most common given names substituted in place
of $first_name. I then specify these hashes when attempting to
repeatedly https://www.example.com/homepage.html while my site is
visited by a victim logged into example.com

3) I have a report-only policy and watch DOM report events to see
which of these attempts resulted in a failure (suggesting that the
name associated with the current hash is not the correct guess), and
which ones go through without an error (suggesting a correct
$first_name).

The attack would be simpler if https://www.example.com/homepage.html
is privately cacheable (in the normal, non-integrity browser cache) to
avoid HTTP roundtrips, although either way, this seems like a concern,
unless I'm missing something?

Section 6.3 mentions "User agents should mitigate the risk by refusing
to trigger elements’ error handlers for cross-origin resources", but
I'm not sure what this means; the remaining text suggests that
reporting events would be triggered for cross-origin documents, too?
(Either way, as noted in the doc, other success / failure signals
should be available in most cases.)

/mz

Received on Thursday, 9 January 2014 06:36:02 UTC