W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2014

Re: Subresource Integrity and fingerprinting

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Wed, 8 Jan 2014 22:35:15 -0800
Message-ID: <CALx_OUBq8ju-NxnogDk74EN91aThHRvprFopYDG-AwZzoSHiGg@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, Joel Weinberger <jww@chromium.org>, Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Frederik Braun <fbraun@mozilla.com>
> 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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC