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

Re: [integrity] content-addressable cache?

From: Mark Goodwin <mgoodwin@mozilla.com>
Date: Mon, 6 Oct 2014 04:27:54 -0700 (PDT)
To: Frederik Braun <fbraun@mozilla.com>, public-webappsec@w3.org
Message-ID: <362778695.16114765.1412594874068.JavaMail.zimbra@mozilla.com>
I've been thinking about a couple of things related to caching.

The first of these relates to history leakage. Consider this scenario:
* an attacker discovers that a site of interest (say, target.example.com) serves a file with a given hash to visitors
* the attacker crafts their own document on some other origin containing an element with an integrity attribute matching the resource on the target (target.example.com) and a broken (e.g. missing document) src.
* By comparing the behaviour of visitors they can ascertain which visitors have also visited the target.

We could, perhaps, mitigate this by denoting (e.g. in a response header - maybe via a new CSP directive?) which resources may be content-addressed off-domain (or maybe I've missed something).

The second relates to opaque bugs related to caching issues:
* A developer creates or modifies a document such that the integrity attribute no longer matches the supplied source
* User A visits the document with a cache that has a valid entry for the integrity attribute supplied (from visiting another site or, perhaps, a previous version of this document before a breaking change). The document behaves correctly in this case.
* Another user, User B, visits the same document with no such cache entry (perhaps it's a first visit, or maybe the entry has expired). The user agent attempts to load the resource at the specified source and fails.

Maybe this isn't something that should be addressed by the specification; even so, it's something implementers could think about (e.g. developer tools which allow you to visit with a clear cache, always fetch the 'src' resource and compare, etc).
Received on Monday, 6 October 2014 13:17:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC