Re: [integrity]: Origin confusion attacks.

On Thu, Jan 9, 2014 at 7:34 PM, Devdatta Akhawe <dev.akhawe@gmail.com>wrote:

> > 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?
>

By opt-out I meant to disable the caching by integrity all together. In
other words the developer is declaring "I want to be able to use
subresource integrity, but I don't want it to load the resource from cache
by integrity hash lookup".

It is possible in *theory* that an attacker could generate a malicious
script with a hash that collides with another script. In practice this is
probably near impossible without finding a weakness in the supported hash
algorithms. I know it's far fetched, but I think people would want to be
able to use integrity's without worrying about this theoretical issue.

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).
>

Correct. I can think of a few advantages to whitelisting the origin instead
of the integrity:

1) You can be explicit about which origins you will trust, which mitigates
hash collision issues but still allows some performance gains
(security/performance)
2) Specifying a few origins may take less bytes than specifying multiple
hashes (performance)
3) More human friendly when looking at and producing the headers
(complexity)

Whitelisting the origin instead of the integrity also has some
disadvantages:

1) The origin may have other scripts that could be harmful (security)
2) More cache misses (performance)
3) Larger cache size (performance)
4) Cache needs to keep track of origins as well as integrity, consider http
vs https as well (performance/complexity)


> 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.
>

Ok cool, I was just making up header names :)


> 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.
>

You are totally correct, that option will not work.

-pete