W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2015

Re: SRI for preemptive cache validation

From: Jeff Kaufman <jefftk@google.com>
Date: Tue, 19 May 2015 09:12:44 -0400
Message-ID: <CAMJ6YUvpC+rS9KHKX2UJa8cS_K=krpN37bqND6ERmJnx2WcjEA@mail.gmail.com>
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

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