SRI: Fine grained "require integrity" option #16

Open
devd opened this Issue Apr 5, 2014 · 11 comments

Projects

None yet

7 participants

@devd
Contributor
devd commented Apr 5, 2014

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.

@mikewest mikewest added the SRI label Aug 18, 2014
@devd
Contributor
devd commented Mar 2, 2015

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
Contributor

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?

@mozfreddyb mozfreddyb added this to the SRI-next milestone Mar 2, 2015
@fmarier
Member
fmarier commented Mar 2, 2015

Should set this to the newly created V2 milestone?

@mozfreddyb
Contributor

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

@devd
Contributor
devd commented Mar 3, 2015

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
Contributor

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

@metromoxie
Contributor

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
dveditz commented Oct 23, 2015

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
dveditz commented Oct 23, 2015

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
Contributor

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
#16 (comment).

@devd
Contributor
devd commented Oct 26, 2015

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.. ?

@jonathanKingston jonathanKingston referenced this issue in w3c/webappsec-subresource-integrity Dec 23, 2015
Open

Add an SRI control as either a CSP directive or a new header #23

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment