New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SRI: Fine grained "require integrity" option #16

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

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

This comment has been minimized.

Show comment
Hide comment
@devd

devd Mar 2, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@mozfreddyb

mozfreddyb Mar 2, 2015

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?

Contributor

mozfreddyb commented Mar 2, 2015

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

This comment has been minimized.

Show comment
Hide comment
@fmarier

fmarier Mar 2, 2015

Member

Should set this to the newly created V2 milestone?

Member

fmarier commented Mar 2, 2015

Should set this to the newly created V2 milestone?

@mozfreddyb

This comment has been minimized.

Show comment
Hide comment
@mozfreddyb

mozfreddyb Mar 2, 2015

Contributor

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

Contributor

mozfreddyb commented Mar 2, 2015

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

@devd

This comment has been minimized.

Show comment
Hide comment
@devd

devd Mar 3, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@mozfreddyb

mozfreddyb Mar 4, 2015

Contributor

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

Contributor

mozfreddyb commented Mar 4, 2015

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

@metromoxie

This comment has been minimized.

Show comment
Hide comment
@metromoxie

metromoxie Mar 5, 2015

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.

Contributor

metromoxie commented Mar 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@dveditz

dveditz 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 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

This comment has been minimized.

Show comment
Hide comment
@dveditz

dveditz 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).

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

This comment has been minimized.

Show comment
Hide comment
@jonathanKingston

jonathanKingston Oct 23, 2015

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

Contributor

jonathanKingston commented Oct 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@devd

devd Oct 26, 2015

Contributor

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

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

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