Re: [integrity]: Origin confusion attacks.

A few things:

1. The cache definition in the spec is quite intentionally something user
agents "MAY" do. I don't at all want to require user agents to implement
it, but I know that several folks are quite interested in the positive
impacts such a caching mechanism could have on performance, so I want to
make sure that the spec recommends policies that mitigate the potentially
negative side-effects such a cache might have. As Brad noted on Twitter,
marking it as "at risk" is a) premature, b) not the right way of expressing
it as an optional component.

2. I don't like a manual opt-out solution; if we decide that origin
confusion attacks are dangerous, then we should have a sane default setup
that protects authors from that risk. At one end of the spectrum, we could
simply recommend that such a cache be disabled for any requests for which
origin-based restrictions are in effect.

In fact, the simplicity of that approach makes it fairly appealing: if a
CORS check is required, or a CSP is in place that governs a resource, or
etc, bypass the integrity-based cache, and hit the origin-based cache (or
network). Worst case, we have no worse performance than we have today, and
in cases where the origin doesn't matter, we'll have better performance.

3. A manual opt-in solution might be reasonable, however. One of the
following approaches might make sense:

    1. We could add an 'unsafe-integrity' source expression to CSP's
grammar.
    2. We could look at the integrity-based cache only if a nonce was
applied to the script.
    3. We could take Michal's approach, and whitelist external hashes.
    4. Moar ideas?

WDYT?

-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 Fri, Jan 10, 2014 at 1:34 AM, Devdatta Akhawe <dev.akhawe@gmail.com>wrote:

> Hi
>
> (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?
>
>
> Thanks
> Dev
>