- From: Jeff Kaufman <jefftk@google.com>
- Date: Tue, 19 May 2015 09:12:44 -0400
- To: Adam Langley <agl@google.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Joel Weinberger <jww@google.com>
On Mon, May 18, 2015 at 7:02 PM, Adam Langley <agl@google.com> wrote:
> if the browser uses a content-addressable store in its cache and
> never makes the HTTP request then an attacker could prime the
> cache with a value with hash $h, then reference https://other.origin/
> with that hash and have the browser believe that "other.origin"
> actually served that data.
Yes, that's not safe, and that's not what I'm proposing. This is only
for resources that are already in cache under a given URL. So we
have:
example.com:
<script src="//www.google-analytics.com/analytics.js"
integrity="nointegrity-sha256-HASH"></script>
If www.google-analytics.com/analytics.js is not in the browser's
cache, or if it is in cache and is still valid, the browser does what
it would normally do. If the browser has a stale
www.google-analytics.com/analytics.js in cache, however then if the
supplied hash matches the cached hash we skip revalidation.
> (One difference with your suggestion is that your examples are only
> ever same origin. I don't know whether that was deliberate. If so,
> then the impact would be very different, although the benefits would
> be reduced too. I've not thought about that subset of the idea
> however.)
Sorry, I should have included cross-origin examples. The benefits are
much larger if you can preemptively revalidate all your resources.
Jeff
Received on Tuesday, 19 May 2015 13:13:17 UTC