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

Re: [integrity]: Origin confusion attacks.

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Thu, 9 Jan 2014 16:34:34 -0800
Message-ID: <CAPfop_0gtBm9ZrOBSiUCsXouvj+fTYdgw1T3ioLD=+ezyw+t2g@mail.gmail.com>
To: Pete Freitag <pete@foundeo.com>
Cc: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>

(trying to summarize some of the discussion)

> I think the document/server needs a way to either opt-out of (if enabled by
> default) or opt-in to unknown-origin sub resource integrity caching.

I am not sure about shipping it with the opt-out: it would mean we are
kinda breaking CSP for sites that enabled it and don't know anything
about this spec. I think opt-in is how we wanna go. Am I
misunderstanding what you meant by opt-out?

With opt-in, we need to whitelist resources that can "load" (so to
speak) the integrity cache. Michal's proposal seems to be whitelisting
hashes. Your proposal in 1,3 whitelists origins (such as CDN origins).
Minor nit: I believe the CH- prefix is for client hints and
Integrity-Allow-Origin is a server side header so shouldn't have the
CH- prefix.

I am not sure about 4, since the fundamental problem that we are
fighting is that the markup is untrusted. the attacker has inserted
attacker.com code into the integrity-cache and also inserted some
markup that will hit the integrity cache to load evil javascript.

It seems we can have both whitelisting origins and whitelisting
hashes: the integrity-policy directive in CSP can also include a
whitelist of hash and origins that can hit the integrity cache.

Now, one problem with whitelisting origins is that it complicates
implementation of the integrity-cache: it will need to also list the
origin that the file originally came from. So, instead of the
integrity-cache just being a map of hashes and (sub)resources, it will
also need to have "I got this script/img from cdn.google.com and so
only load it if the CSP for document whitelists cdn.google.com"

Whitelisting origins has one more complication: do I whitelist
"http://cdn.google.com" as a trusted source? On one hand, CDNs like to
use HTTP. On the other, this has a vulnerability: a powerful network
attacker to load up lots of evil scripts and then we have the original
attack still working.

Due to this complication, I am liking Michal's "whitelist hash"
proposal more and more.

What do others think?

Received on Friday, 10 January 2014 00:35:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:36 UTC