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

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

From: Mike West <mkwst@google.com>
Date: Thu, 8 Jan 2015 11:40:43 +0100
Message-ID: <CAKXHy=c=_=jVB9UMog2Po8k=gNO42=n0njmUGUo-=_AduL2A2g@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: Francois Marier <francois@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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 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
(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 10:41:30 UTC

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