w3c / webappsec

Web Application Security Working Group repo
https://www.w3.org/groups/wg/webappsec/
Other
608 stars 148 forks source link

SRI: Fine grained "require integrity" option #16

Open devd opened 10 years ago

devd commented 10 years ago

A simple use case that I can't figure out how to implement with the current spec is: "require integrity for all script loads"

I am beginning to think that instead of a new "integrity-policy" directive, we should just have new keywords for the existing CSP directives like script-src. OR some other way to declare integrity requirements for each type of sub-resource.

I am just creating a placeholder issue for now. I am traveling and don't have the time/connectivity required to start and participate in a thread on public-webappsec.

devd commented 9 years ago

I am bubbling this back up for comments from @fmarier @metromoxie @mozfreddyb . If I were to implement this at Dropbox, it is extremely unlikely that I would implement require-for-all for all styles; only for scripts more likely.

And, thinking about this further , require-for-all seems brittle. Lets say next we add support for object tags. Then, someone who had support for links and scripts suddenly finds that the object tag stops working because browsers upgraded. And this will be a recurring pain for every type of resource.

mozfreddyb commented 9 years ago

We had a "integrity policy" section that I ripped out for v1, but yes your comment holds true against it:

We'll have to enumerate attributes, I guess – like in CSP?

fmarier commented 9 years ago

Should set this to the newly created V2 milestone?

mozfreddyb commented 9 years ago

I created a milestone called SRI-next (so we don't have discuss if it should be 1.1 or 2 ;))

devd commented 9 years ago

I am fine with moving it out to SRI-next, but in that case, should we remove require-for-all from v1 (because of the compat concerns I bought up above)? The only CSP policy for SRIv1 can be block or report.

mozfreddyb commented 9 years ago

(for the record, #201 removed the require-for-all)

joelweinberger commented 9 years ago

For the record, this seems reasonable to me. It seems like there's a lot of nuance to figure out still, so I'd rather not hoist an imperfect directive on users.

dveditz commented 9 years ago

There's basically two ways this could fit into CSP: A. add a keyword to existing -src directives: script-src 'self' https://othersite.com 'require-integrity'; B. add a new directive, with a bunch of optional resource types:

dveditz commented 9 years ago

B continued: integrity (integrity-required?) 'script' 'style'; Of the two options I prefer A, adding a keyword to existing directives. (don't care about the keyword name, could be 'integrity', 'integrity-required', 'require-integrity' or maybe someone can come up with a better option).

jonathanKingston commented 9 years ago

Does having just 'always on'/'potentially on' states capture the use case here?

Having the ability to enable SRI just on JavaScript CDN URLs to me seems most useful to not break other scripts.

However I perhaps might want to force nonces on all other scripts.

Something like sri-require-exempt-src however that would move away from restrictive only directives but only based on the restrictive directive you mention.

On Fri, 23 Oct 2015 19:16 Daniel Veditz notifications@github.com wrote:

B continued: integrity (integrity-required?) 'script' 'style'; Of the two options I prefer A, adding a keyword to existing directives. (don't care about the keyword name, could be 'integrity', 'integrity-required', 'require-integrity' or maybe someone can come up with a better option).

— Reply to this email directly or view it on GitHub https://github.com/w3c/webappsec/issues/16#issuecomment-150652679.

devd commented 9 years ago

If we version the CSP header, we could just do sri- as a new source expression and then include that in the script-src? something like script-src sri-sha256-abcdef.. ?