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

Re: [integrity] Different ways to associate integrity information

From: Mike West <mkwst@google.com>
Date: Fri, 24 Oct 2014 12:00:24 +0200
Message-ID: <CAKXHy=f=fhKjKx8UX=ck7RXqhfWstX3x=W+5KJn4MLTDiZ=4Dg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: WebAppSec WG <public-webappsec@w3.org>
The security improvement we get from integrity checks comes from the fact
that the digest is delivered out-of-band with the resource. If jQuery's
server is compromised, it's only the sloppiest of attackers who would
update the resource, but not the headers.

It's not clear to me what benefit we'd obtain from a response header that
contained information that could be easily calculated from the resource
itself. Could you explain the use-case a little bit?


Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Fri, Oct 24, 2014 at 5:47 AM, Mark Nottingham <mnot@mnot.net> wrote:

> Has there been any discussion of how the integrity information is
> associated with a resource?
> I think using the integrity attribute on the link makes sense for the most
> current use case -- assuring that off-site content (e.g., on a CDN) is what
> you think it's going to be. That's because in these cases, the URL is most
> likely to be a version-specific one (<e.g.,
> https://cdn.com/foolib.1.2.3.js>), so if the author wants to update the
> library version used, they'll need to update the link, and the integrity
> information is right next to it.
> However, in the cache reuse case -- which seems to be getting *some*
> traction (or at least consideration) -- next to the link is about the worst
> place the integrity information can go; if the author updates the library,
> they'll need to update each and every instance of a link to it, which can
> be quite onerous.
> In that use case, it makes more sense to put integrity information into
> HTTP headers or even a separate resource, so that it can more easily be
> updated (e.g., by a separate process, or automatically by the server at
> response time).
> So, I'm wondering if the WG would consider allowing integrity information
> to be carried in HTTP response headers (e.g., Link), at least for the cache
> reuse case.
> Cheers,
> --
> Mark Nottingham   https://www.mnot.net/
Received on Friday, 24 October 2014 10:01:13 UTC

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