- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 24 Oct 2014 14:47:47 +1100
- To: mgoodwin@mozilla.com, WebAppSec WG <public-webappsec@w3.org>
Catching up... > 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. Developers need to clear cache to check their changes anyway, and so they should catch the integrity mismatch. That's a feature, I think; it'll remind them to update if they forget. Good tooling will help, of course. Perhaps browsers won't want to do SRI-based caching when the user explicitly reloads, for example. > To mitigate this, user agents would need to ensure that simply setting an integrity attribute does not result in a content-accessible cache entry becoming available. Perhaps entries could be written if a matching resource is observed from a number of different origins, for example. I'm sure others will have thoughts on this. That's interesting, but a determined attacker just needs n+1 origins; domain names are cheap. I hesitate to mention it, but an explicit opt-in from the server sending the cached content (e.g., a new Cache-Control directive) would probably do the trick here; presumably it would only be sent on *really* public things (such as common JS libraries). Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Friday, 24 October 2014 03:48:14 UTC