Re: Subresource Integrity and fingerprinting

I agree that the attack you're describing is one we need to be quite
concerned about. I'll update the text in 6.3 to ensure that we keep it in
mind.

What is the mitigation that you're agreeing with, Michal? Only performing
integrity checks on resources delivered with explicitly public
cache-control or CORS headers?

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


On Thu, Jan 9, 2014 at 7:35 AM, Michal Zalewski <lcamtuf@coredump.cx> wrote:

> >
> 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 07:20:28 UTC