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

      <script src="//www.google-analytics.com/analytics.js"

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.

Received on Tuesday, 19 May 2015 13:13:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:49 UTC