SRI: explain CORS requirement clearly

[jonathanKingston]

The CORS requirement in the specification I feel isn't clear enough for developers to understand why CORS was made as a requirement.

This comment clearly explains the reason it was added:
#338 (comment)

A clear example of an attacker being able to bypass firewall security by:

• loading local URLs until they stop triggering hash errors
• using the hash to calculate the content of the file

Clearly explaining that:
This attack bypasses the current security of the attacker only able to execute the code instead of being able to know all of its contents.

[joelweinberger]

cc @devd @fmarier @mozfreddyb, and maybe of interest to @annevk and @mikewest

[jonathanKingston]

This came about from a discussion raised on trying to get Ember to default SRI to be enabled by default which is risky if it is deployed over multiple origins.

The only safe thing I can get my addon to do is to only add integrities to relative URLs unless the user explicitly sets a crossorigin. (As mentioned in previous bugs this will harm implementations although a solution isn't clear either).

The only next best thing is to explain clearly to developers and library writers why CORS is required for assets on their servers.

[annevk]

I'm not sure this needs additional clarification. It's no different from cross-origin scripts not throwing useful exceptions unless CORS is used.

[annevk]

But also, SRI is more generic than just scripts.

[jonathanKingston]

@annevk I would argue it could be overlooked by a new programmer being forced to implement SRI. Clearly explaining why things are harder than they might expect should lower the barrier to them giving up etc.

Is there was a more generic place like the CORS spec itself this one could cite that might be better for future specs also?

[annevk]

Hmm, https://fetch.spec.whatwg.org/#http-cors-protocol just has a basic explanation of what it protects. If anything <script> should elaborate on how it hacks around CORS by executing opaque responses.

[fmarier]

IMHO, we should re-phrase section 5.3 under Security Considerations to cover what Jonathan is asking for. I've had to explain it to a few people already, so I don't think it will be non-obvious to a lot of readers of this spec.

Additionally, the last sentence of that section no longer makes sense:

User agents SHOULD mitigate the risk by refusing to fire error events on elements which loaded non-CORS cross-origin resources, but some side-channels will likely be difficult to avoid.

We don't allow non-CORS cross-origin loads with SRI.

[devd]

filed #422 for removing the note.

The broader issue about CORS and why we need it: I think it is best fixed by browser warnings and blogging etc. Do developers read specs as much as stack overflow, html5rocks.com etc?

[jonathanKingston]

Certainly some developers do read standards which use what they learn to trickle down to the wider community.

I would actually suggest formalising all the gotchas from:

• https://www.w3.org/Security/wiki/Same_Origin_Policy
• https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
• https://annevankesteren.nl/2015/02/same-origin-policy

These may be obvious to people who have worked in the industry a long time or have a vested interest in specs however as the whole internet security pins from it I think it would be useful to have a published note that was a centralised resource.

That way other specs could also reference different rationale in the note rather than rewriting it each time.

[jonathanKingston]

So as I discussed with @wseltzer it would be useful to have a from the security interest group a SOP note on how SOP works in the wild as a definitive source.

However this doesn't solve this clarity issue here as it shouldn't hold up rec on SRI.

As crossorigin isn't specified anywhere a small note may be useful.

[annevk]

What do you mean isn't specified?

[jonathanKingston]

@annevk we are not linking to: https://html.spec.whatwg.org/multipage/infrastructure.html#cors-settings-attributes and also explaining clearly the integrity checking exploit why CORS is required for non SOP requests.

[mozfreddyb]

With #422, we should add a sentence to (at least) the security considerations, that explain why we do CORS (i.e. very briefly re-iterate the danger of leaks). We should also link to the cors attributes, I'm sure.

[devd]

hmm .. so I am confused. What do we want to do finally (in addition to #422)? I think regardless of what we do, this is gonna be a problem until there are articles and developer resources outside of the spec.

[fmarier]

I took a stab at this in #485.

[FrankBWalsh]

This thread is brilliant! I was trying to wrap my head around why the relationship between SRI and CORS and without this thread I would have been left scratching my head!