Re: [integrity] content-addressable cache?

Issue #1 - history scraping

I don't think there's ever been a question that some of these
cache-timing things would be possible with SRI.  The question is, are
we making things worse?  To some extent, cache timing by making blind
cross-origin transclusions (<img src="foreign.com/loggedInImage.gif">)
or CORS will already reveal through timing whether the content is
already cached.  If we require that anything entering the cache have
CORS Access-Control-Allow-Origin *, does SRI meaningfully change this
threat model?

Issue #2 - cache poisoning, origin spoofing, etc.

I see two issues here with opposite tensions:

2.1) How to prevent poisoning the effective origin of content in a CAS
(content-addressable-store)?  e.g.  a Java applet retains permissions
based on where it was loaded *from*, not the origin in to which it is
loaded.  So an attacker can push an evil applet into the cache, then
inject an <object> tag referencing it by hash but with a different
origin (sensitive.example.com) for the source.  If the browser just
loads the content without verifying that it is indeed present on
sensitive.example.com, we've created a big vulnerability.  This argues
for sandboxing the origin (give it a GUID with no meaningful
permissions) of any content retrieved from the CAS.  Not a problem for
the "standard' Same Origin Policy, but it breaks the ability to use
SRI for variant SOPs like used by Java, Silverlight, etc.  (not sure
I'll cry too many tears over that one)

Sandboxing the origin also seems to be the only logical answer to
dealing with content where the src/href and non-canonical are on
different origins.

2.2) How to interact with CSP.  Sandboxed origins for anything
retrieved from CAS means that whitelisting such content by-origin
becomes impossible.  You'd have to specify a hash-src in CSP, and the
same hash again in the integrity attribute.  Not terrible to speed up
the loading of a few large libraries like JQuery, but it does limit
the usefulness of SRI in building a completely-verifiable web
application without a very large policy.  Nonces also seem to miss the
point, because we're aiming to take advantage of caching, and you
can't effectively cache a page with nonces.

Maybe having a large policy isn't the worst solution for the cases
where a large number of integrity-tagged sub resources exist.



On Mon, Oct 6, 2014 at 8:03 AM, Mark Goodwin <mgoodwin@mozilla.com> wrote:
>> Currently, the spec tries to address this by requiring that resources
>> that can be content-addressed need to be publicly cacheable or open
>> via CORS.
>> see
>> http://w3c.github.io/webappsec/specs/subresourceintegrity/#is-resource-eligible-for-integrity-validation
>>
>> Wdyt?
>
> My apologies; I missed this section.
>
> Technically, I think a mechanism along these lines could work but, for caching, more detail is needed. It may be that integrity checks are allowed for the original on-domain use of that resource (on and for target.example.com in my example)... but if that same integrity value is used for content-addressing some cache later, what are the rules? Caching changes this from being about confidentiality of the resource to also being about confidentiality of the user's visit - it might be clear that private.js shouldn't be cached but we also need to make it explicit that unique.js is also tricky.
>
>> I am not sure why this counts as an opaque bug though. Maybe you can
>> clarify?
>
> It is roughly equivalent to the existing possibilities that you mention. The difference is that that, once the cache entries can come from other origins, it becomes more likely that a document with a resource that has never had a good src / integrity combination will appear to work fine for many users (including the developer), especially if it's a common library.
>

Received on Monday, 6 October 2014 17:23:25 UTC