Remove "type:*" from integrity, add type attribute.

[neftaly]

I propose that we no longer provide a "type" directive in the SRI integrity attribute, and instead provide a HTML type attribute:

<script
    src="file.js"
    integrity="sha256-XXXX"
    type="application/javascript; charset=UTF-8">
</script>

RE w3c/webappsec/#176, the optional "type" directive in SRI is intended to prevent the server from having any say in how a script is parsed (GIFAR-style confusion-of-context attacks). It does this by enforcing a failure state, should an unexpected unexpected content-type be served -- even if the hash is valid. In practice, this rule would break the sub-resource whenever a content-type header changes.

Enforcing a parsing rule (via the type attribute), instead of failing outright (per the content-type header), would:

• Continue to prevent content-type confusion-of-context attacks
• Protect against any future confusion-of-context vulnerabilities caused by instructions other than content-type
• Lead to more robust sub-resource handling
• Increase semantic correctness/widen separation of concerns in generated elements
• Remove a potential avenue for the server to probe SRI support
• Allow correct handling of content-type directives (such as "charset")
• Allow library authors to provide one generic SRI-enabled element example for all CDN's, instead of a different element for every CDN (per content-type header)
• Negate the need for a custom parsing rule in mozilla/srihash.org (thus closing "Content-type" header is passed directly into result #38)

I also propose that use of the type attribute, and disuse of the "type" SRI directive, should be advised as a best-practice.

[fmarier]

If you think that's the approach we should use, it should be fixed in the spec, not here :)

Another way to look at it is that if the server starts returning a different content-type, then it's returning a different resource. SRI is about ensuring that the server always returns the same exact resource (otherwise it gets blocked). So the failure to load is a feature, not a bug.

Also, I'm not sure how good browsers are at enforcing the type attribute and whether it's always enforced or it's merely a suggestion. I suspect it's the latter.

[neftaly]

You are correct regarding the purpose/nature of SRI/"type". I don't necessarily think the "type" directive should be removed from the spec; just from this tool. To paraphrase what you said regarding 2079187 (specifically, the exclusion of SHA-512), srihash.org is built around the idea of making SRI easy-to-use.

In this case, I would interpret "easy to use" as being plug-and-play for any CDN (regardless of which Javascript content-type header they decide to use), and being unlikely to "break the web" should a CDN change their content-type header (be it through obsolescence of an old content-type, a change in proxying servers, an otherwise perfectly acceptable server reconfiguration, etc). The latter point is especially important; varying content-type headers have never been an issue before, but if SRI were to suddenly start breaking things unexpectedly, it'd have a negative effect on adoption.

Enforcement of the type attribute is a different nut. I haven't yet found a parallel in the HTML5 spec, but the HTML4.01 spec seems to imply it as being authoritative.

[neftaly]

These all load :( (Chrome/FF, Linux). Haven't tried <script> or <link>, they could be different.

<img src="http://upload.wikimedia.org/wikipedia/meta/0/08/Wikipedia-logo-v2_1x.png">
<img src="http://upload.wikimedia.org/wikipedia/meta/0/08/Wikipedia-logo-v2_1x.png" type="image/png">
<img src="http://upload.wikimedia.org/wikipedia/meta/0/08/Wikipedia-logo-v2_1x.png" type="image/jpg">
<img src="http://upload.wikimedia.org/wikipedia/meta/0/08/Wikipedia-logo-v2_1x.png" type="image/svg">
<img src="http://upload.wikimedia.org/wikipedia/meta/0/08/Wikipedia-logo-v2_1x.png" type="text/plain">

Maybe enforce-type should be a CSP2 policy? :P

[fmarier]

Interesting results :) Yeah, it would be nice is these were enforced more generally.

In this case, I would interpret "easy to use" as being plug-and-play for any CDN (regardless of which Javascript content-type header they decide to use), and being unlikely to "break the web" should a CDN change their content-type header (be it through obsolescence of an old content-type, a change in proxying servers, an otherwise perfectly acceptable server reconfiguration, etc). The latter point is especially important; varying content-type headers have never been an issue before, but if SRI were to suddenly start breaking things unexpectedly, it'd have a negative effect on adoption.

I think we should go for both security and ease-of-use. Giving people the choice to go for sha512 isn't a meaningful security improvement right now. If it were, we should just use it and remove sha256.

In the case of the content type, I think it's different. First of all, we're giving not an extra option to users, it's still a one-click process. Secondly, the spec insists that developers should specificy the content-type in order to prevent MIME type confusion attacks. As per that note, Firefox issues a warning in the devtools when it's missing. Finally, we're going to need the content type if version 2 of SRI adds the caching improvements that got removed in V1, so it's good to get it in there early.

You make good points about the possibility for breakage if CDNs end up changing their content-type. I suspect (maybe wrongly) that it's unlikely they will and that if they did, it may lead to other breakage. The good thing is that if it stops working (because of content-type mismatch) and a developer comes back to srihash.org to rehash the script, it will automatically refresh the content-type :)

[neftaly]

Fair enough. Tangentially related, I see that the big list of JS content-types I found before is actually a "must include" in the HTML5 spec. Should I add them to lib/resourceTypes.js?

[fmarier]

I see that the big list of JS content-types I found before is actually a "must include" in the HTML5 spec. Should I add them to lib/resourceTypes.js?

I suppose we should, yes.

Also, I noticed this in the spec (note the link to the canonical HTML5 spec, not the W3C fork ;-) ):

The following MIME types (with or without parameters) must not be interpreted as scripting languages:

• text/plain
• text/xml
• application/octet-stream
• application/xml

Perhaps we should return an error (instead of a warning) when we see these.

It would be worth creating a separate issue for this since it no longer has anything to do with this bug :)