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

Re: [SRI] providing good defaults when the expected content type is missing?

From: Joel Weinberger <jww@chromium.org>
Date: Thu, 08 Jan 2015 16:04:01 +0000
Message-ID: <CAHQV2Kk-60P-mO0E2Rk3M8usEOQa-=5e99QB9TPNJBBHTFw4NQ@mail.gmail.com>
To: Mike West <mkwst@google.com>, Brad Hill <hillbrad@gmail.com>
Cc: Francois Marier <francois@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
It also just smells wrong to me to put this into the SRI spec. Content type
checking is hard, but it's certainly not unique here, and I also don't
particularly see why integrity would require it in particular.

On Thu Jan 08 2015 at 2:43:26 AM Mike West <mkwst@google.com> wrote:

> I also don't think this is a good idea; if we wish to enforce content type
> checking, let's just bite the bullet and make the `ct` parameter mandatory
> (and disallow opt-out entirely).
> -mike
> --
> Mike West <mkwst@google.com>, @mikewest
> 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 Tue, Dec 30, 2014 at 7:16 PM, Brad Hill <hillbrad@gmail.com> wrote:
>> I'm not sure I'm onboard with this.  The point of allowing different
>> types, or specifying them explicitly as with the link tag, is to allow
>> extensibility.  We may not be aware of all circumstances in which these
>> extensibility points are being used, and we definitely cannot anticipate
>> where they might be used in the future.   Monkey patching these high-level
>> features out of existence with SRI doesn't seem like a good idea.
>> -Brad
>> On Mon Dec 29 2014 at 5:59:12 PM Francois Marier <francois@mozilla.com>
>> wrote:
>>> The spec currently says:
>>> "The hash function and digest MUST be provided in order to validate a
>>> resource’s integrity. The MIME type SHOULD be provided, as it mitigates
>>> the risk of certain attack vectors."
>>> I've added a warning in the Firefox devconsole when the content type is
>>> missing, but I was just thinking that in a lot of (most?) cases, we
>>> could provide a good default for developers and let them override it if
>>> they want to.
>>> Specifically, I'm thinking that when the integrity attribute is on a:
>>> - <script> tag: default the expected type to "application/javascript"
>>> - <link rel="stylesheet"> tag: default to "text/css"
>>> I can see two consequences of this:
>>> 1. It means that a developer who forgets to include the content type
>>> would still get the benefits of an explicit ct parameter.
>>> 2. It means that to opt out of content-type matching, we would need to
>>> add a new kind of syntax (maybe something like "ct=*").
>>> Consequence 1 would be nice since SRI would be stronger by default but
>>> maybe #2 would be a problem in practice?
>>> Are there any other potential problems I'm not thinking of?
>>> Francois
Received on Thursday, 8 January 2015 16:04:28 UTC

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