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

attempt to write down `require-sri-for` directive as part of SRI #32

Merged
merged 7 commits into from Jun 6, 2016

Conversation

Projects
None yet
6 participants
@shekyan
Contributor

shekyan commented May 5, 2016

Background: w3c/webappsec-csp#85.

@@ -343,7 +354,47 @@ implementation detail. It is not an API that implementors
provide to web applications. It is used in this document
only to simplify the algorithm description.
## Response verification algorithms ## {#verification-algorithms}
## Request verification algorithms ## {#request-verification-algorithms}

This comment has been minimized.

@mozfreddyb

mozfreddyb May 9, 2016

Contributor

Don't we still want to verify the response?

@mozfreddyb

mozfreddyb May 9, 2016

Contributor

Don't we still want to verify the response?

This comment has been minimized.

@shekyan

shekyan May 9, 2016

Contributor

It is still there

@shekyan

shekyan May 9, 2016

Contributor

It is still there

This comment has been minimized.

@mozfreddyb

mozfreddyb May 10, 2016

Contributor

Right, sorry. I got confused by the diff viewer.

@mozfreddyb

mozfreddyb May 10, 2016

Contributor

Right, sorry. I got confused by the diff viewer.

Show outdated Hide outdated index.bikeshed.bs
@mozfreddyb

This comment has been minimized.

Show comment
Hide comment
@mozfreddyb

mozfreddyb May 9, 2016

Contributor

Please don't remove index.html in your branch.

Contributor

mozfreddyb commented May 9, 2016

Please don't remove index.html in your branch.

@shekyan

This comment has been minimized.

Show comment
Hide comment
@shekyan

shekyan May 9, 2016

Contributor

Please don't remove index.html in your branch.

I thought approach here is the same as in CSP, where maintainer commits bikeshed output.
I amended commit to include index.bikeshed.html.
I haven't changed spec.markdown, which is the producer of index.html assuming development was switched to used Bikeshed. Should I port my changes to Markdown after we are done, to get updated index.html?

Contributor

shekyan commented May 9, 2016

Please don't remove index.html in your branch.

I thought approach here is the same as in CSP, where maintainer commits bikeshed output.
I amended commit to include index.bikeshed.html.
I haven't changed spec.markdown, which is the producer of index.html assuming development was switched to used Bikeshed. Should I port my changes to Markdown after we are done, to get updated index.html?

@mozfreddyb

This comment has been minimized.

Show comment
Hide comment
@mozfreddyb

mozfreddyb May 10, 2016

Contributor

spec.markdown and index.html are SRI version 1, which we can't modify lightly.
require-sri-for should land in the next SRI version, so I'd prefer you only patch index.bikeshed.bs :)

Contributor

mozfreddyb commented May 10, 2016

spec.markdown and index.html are SRI version 1, which we can't modify lightly.
require-sri-for should land in the next SRI version, so I'd prefer you only patch index.bikeshed.bs :)

@mozfreddyb mozfreddyb added the SRI-next label May 10, 2016

@mozfreddyb

This comment has been minimized.

Show comment
Hide comment
@mozfreddyb

mozfreddyb May 10, 2016

Contributor

Looks good from my side. Thank you for writing this down, Sergey!
paging other spec editors @metromoxie, @devd @fmarier

Contributor

mozfreddyb commented May 10, 2016

Looks good from my side. Thank you for writing this down, Sergey!
paging other spec editors @metromoxie, @devd @fmarier

Show outdated Hide outdated index.bikeshed.bs
Show outdated Hide outdated index.bikeshed.bs
Show outdated Hide outdated index.bikeshed.bs
@metromoxie

This comment has been minimized.

Show comment
Hide comment
@metromoxie

metromoxie May 13, 2016

Contributor

lgtm % nits/minor comments. Thanks a lot, @shekyan!

Contributor

metromoxie commented May 13, 2016

lgtm % nits/minor comments. Thanks a lot, @shekyan!

Show outdated Hide outdated index.bikeshed.bs
Show outdated Hide outdated index.bikeshed.bs
@mikewest

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest May 15, 2016

Member

This looks like a good start, but I have some questions that I've left inline. Thanks!

Member

mikewest commented May 15, 2016

This looks like a good start, but I have some questions that I've left inline. Thanks!

@shekyan

This comment has been minimized.

Show comment
Hide comment
@shekyan

shekyan May 16, 2016

Contributor

@mikewest , please review if this looks sane when you have a chance.

Contributor

shekyan commented May 16, 2016

@mikewest , please review if this looks sane when you have a chance.

Show outdated Hide outdated index.bikeshed.bs
Show outdated Hide outdated index.bikeshed.bs
Show outdated Hide outdated index.bikeshed.bs
Show outdated Hide outdated index.bikeshed.bs
Show outdated Hide outdated index.bikeshed.bs
Show outdated Hide outdated index.bikeshed.bs
Show outdated Hide outdated index.bikeshed.bs
@mikewest

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest May 17, 2016

Member

Seems pretty reasonable to me % the comments I left. I'll leave the question of which files to touch to the SRI editors who know what's up there.

Member

mikewest commented May 17, 2016

Seems pretty reasonable to me % the comments I left. I'll leave the question of which files to touch to the SRI editors who know what's up there.

@mozfreddyb

This comment has been minimized.

Show comment
Hide comment
@mozfreddyb

mozfreddyb May 17, 2016

Contributor

Again, thank you Sergey for bearing with our endless feedback :-)
(Also thanks to @mikewest for reviewing!)

I think this PR needs wording that suggests a missing integrity attribute will trigger a CSP violation report.

Contributor

mozfreddyb commented May 17, 2016

Again, thank you Sergey for bearing with our endless feedback :-)
(Also thanks to @mikewest for reviewing!)

I think this PR needs wording that suggests a missing integrity attribute will trigger a CSP violation report.

shekyan added some commits May 5, 2016

attempt to write down `require-sri-for` directive as part of SRI
please ignore missing references. Once we agree on the content I'll clean things up.
change `require-sri-for` parsing algorithm
Initialize protected resource type set as empty, not null.
@shekyan

This comment has been minimized.

Show comment
Hide comment
@shekyan

shekyan May 19, 2016

Contributor

Addressed @mikewest and @mozfreddyb comments. I don't know if we want to allow this directive be delivered through header only or within <meta> element as well. Thoughts?

Contributor

shekyan commented May 19, 2016

Addressed @mikewest and @mozfreddyb comments. I don't know if we want to allow this directive be delivered through header only or within <meta> element as well. Thoughts?

@shekyan

This comment has been minimized.

Show comment
Hide comment
@shekyan

shekyan Jun 2, 2016

Contributor

Folks, there is currently a problem in @mozfreddyb's implementation around resources loaded from CORS-disabled servers. It needs to be reflected in the spec, so I'll start the discussion here:

require-sri-for matching algorithm should allow requests that are missing both integrity metadata and CORS setting attribute, Otherwise, require-sri-for usage is limited to pages that load resources only from CORS-enabled servers.

Example: Content-Security-Policy: require-sri-for script implies that all script elements should have integrity metadata present, but it is not possible to have integrity metadata on resources that are served by CORS-disabled servers, like https://www.google-analytics.com/analytics.js.

What do you think?

P.S. Is there a way to load a resource anonymously from CORS-unaware servers without violating SOP?
Do not see why crossorigin='anonymous' requires server to be CORS-aware.

Contributor

shekyan commented Jun 2, 2016

Folks, there is currently a problem in @mozfreddyb's implementation around resources loaded from CORS-disabled servers. It needs to be reflected in the spec, so I'll start the discussion here:

require-sri-for matching algorithm should allow requests that are missing both integrity metadata and CORS setting attribute, Otherwise, require-sri-for usage is limited to pages that load resources only from CORS-enabled servers.

Example: Content-Security-Policy: require-sri-for script implies that all script elements should have integrity metadata present, but it is not possible to have integrity metadata on resources that are served by CORS-disabled servers, like https://www.google-analytics.com/analytics.js.

What do you think?

P.S. Is there a way to load a resource anonymously from CORS-unaware servers without violating SOP?
Do not see why crossorigin='anonymous' requires server to be CORS-aware.

@metromoxie

This comment has been minimized.

Show comment
Hide comment
@metromoxie

metromoxie Jun 2, 2016

Contributor

FWIW, lgtm with this PR now that @mikewest has approved the change. @devd do you want to review the change? Or should we go ahead and merge?

Contributor

metromoxie commented Jun 2, 2016

FWIW, lgtm with this PR now that @mikewest has approved the change. @devd do you want to review the change? Or should we go ahead and merge?

@devd

This comment has been minimized.

Show comment
Hide comment
@devd

devd Jun 3, 2016

Contributor

My understanding is that this only affects scripts/styles inserted through HTML elements. (because that's what SRI is defined for right now). If so, should the tokens be named script-element rather than just script? e.g., what if a service worker is served with a CSP policy of require-sri-for? How will that work?

Contributor

devd commented Jun 3, 2016

My understanding is that this only affects scripts/styles inserted through HTML elements. (because that's what SRI is defined for right now). If so, should the tokens be named script-element rather than just script? e.g., what if a service worker is served with a CSP policy of require-sri-for? How will that work?

@mikewest

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Jun 3, 2016

Member

I think it's substantially cleaner to reuse the terms from Fetch (https://fetch.spec.whatwg.org/#concept-request-destination) rather than inventing new subsets. Doing so ensures that you'll actually have the detail necessary to block requests. Note, for instance, that Fetch doesn't have any information that would allow it to distinguish <script src='whatever'> and importScripts(whatever).

The argument that SRI doesn't yet support importScripts seems like a poor reason for introducing more complexity to script loading. It instead seems like a good reason to extend SRI to support more resource types, which I think y'all are planning to do anyway. :)

Member

mikewest commented Jun 3, 2016

I think it's substantially cleaner to reuse the terms from Fetch (https://fetch.spec.whatwg.org/#concept-request-destination) rather than inventing new subsets. Doing so ensures that you'll actually have the detail necessary to block requests. Note, for instance, that Fetch doesn't have any information that would allow it to distinguish <script src='whatever'> and importScripts(whatever).

The argument that SRI doesn't yet support importScripts seems like a poor reason for introducing more complexity to script loading. It instead seems like a good reason to extend SRI to support more resource types, which I think y'all are planning to do anyway. :)

@devd

This comment has been minimized.

Show comment
Hide comment
@devd

devd Jun 3, 2016

Contributor

But we ship this and then turn on support for importScripts or @import,
then sites might break?
On Jun 2, 2016 9:58 PM, "Mike West" notifications@github.com wrote:

I think it's substantially cleaner to reuse the terms from Fetch (
https://fetch.spec.whatwg.org/#concept-request-destination) rather than
inventing new subsets. Doing so ensures that you'll actually have the
detail necessary to block requests. Note, for instance, that Fetch doesn't
have any information that would allow it to distinguish <script src='whatever'> and importScripts(whatever).

The argument that SRI doesn't yet support importScripts seems like a poor
reason for introducing more complexity to script loading. It instead seems
like a good reason to extend SRI to support more resource types, which I
think y'all are planning to do anyway. :)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#32 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAIXGc94g4j3_sNmNP-lu0h-hpYDrvaNks5qH7R2gaJpZM4IYdBU
.

Contributor

devd commented Jun 3, 2016

But we ship this and then turn on support for importScripts or @import,
then sites might break?
On Jun 2, 2016 9:58 PM, "Mike West" notifications@github.com wrote:

I think it's substantially cleaner to reuse the terms from Fetch (
https://fetch.spec.whatwg.org/#concept-request-destination) rather than
inventing new subsets. Doing so ensures that you'll actually have the
detail necessary to block requests. Note, for instance, that Fetch doesn't
have any information that would allow it to distinguish <script src='whatever'> and importScripts(whatever).

The argument that SRI doesn't yet support importScripts seems like a poor
reason for introducing more complexity to script loading. It instead seems
like a good reason to extend SRI to support more resource types, which I
think y'all are planning to do anyway. :)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#32 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAIXGc94g4j3_sNmNP-lu0h-hpYDrvaNks5qH7R2gaJpZM4IYdBU
.

@mikewest

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Jun 3, 2016

Member

They'd break right away in the presence of this directive, since we'd be blocking the requests. They'd start working once we support those mechanisms. Sounds like a good reason to start widening our support. :)

Member

mikewest commented Jun 3, 2016

They'd break right away in the presence of this directive, since we'd be blocking the requests. They'd start working once we support those mechanisms. Sounds like a good reason to start widening our support. :)

@devd

This comment has been minimized.

Show comment
Hide comment
@devd

devd Jun 3, 2016

Contributor
Contributor

devd commented Jun 3, 2016

@shekyan

This comment has been minimized.

Show comment
Hide comment
@shekyan

shekyan Jun 3, 2016

Contributor

@mikewest, I agree with @devd. In Fetch, destination "script" is for both <script> and importScripts(). Or, destination "media" is for HTML's <audio>, <track>, <video>. So if we reuse terms from Fetch 1-to-1, it might lead to less granular control in the future.

Contributor

shekyan commented Jun 3, 2016

@mikewest, I agree with @devd. In Fetch, destination "script" is for both <script> and importScripts(). Or, destination "media" is for HTML's <audio>, <track>, <video>. So if we reuse terms from Fetch 1-to-1, it might lead to less granular control in the future.

@mozfreddyb

This comment has been minimized.

Show comment
Hide comment
@mozfreddyb

mozfreddyb Jun 3, 2016

Contributor

require-sri-for matching algorithm should allow requests that are missing both integrity metadata and CORS setting attribute, Otherwise, require-sri-for usage is limited to pages that load resources only from CORS-enabled servers.

I thought that's the intention behind all this? That nobody can use scripts without using integrity (and thus requesting from a CORS-enabled server or a same-origin server).

Contributor

mozfreddyb commented Jun 3, 2016

require-sri-for matching algorithm should allow requests that are missing both integrity metadata and CORS setting attribute, Otherwise, require-sri-for usage is limited to pages that load resources only from CORS-enabled servers.

I thought that's the intention behind all this? That nobody can use scripts without using integrity (and thus requesting from a CORS-enabled server or a same-origin server).

@mozfreddyb

This comment has been minimized.

Show comment
Hide comment
@mozfreddyb

mozfreddyb Jun 3, 2016

Contributor

To answer the other question: require-sri-for should work in <meta> CSP policies. Firefox Nightly does not this and that's a bug 🐞 .

Contributor

mozfreddyb commented Jun 3, 2016

To answer the other question: require-sri-for should work in <meta> CSP policies. Firefox Nightly does not this and that's a bug 🐞 .

@shekyan

This comment has been minimized.

Show comment
Hide comment
@shekyan

shekyan Jun 3, 2016

Contributor

I thought that's the intention behind all this? That nobody can use scripts without using integrity (and thus requesting from a CORS-enabled server or a same-origin server).

Yes, but if SRI does not provide a way to verify integrity of a resource from CORS-disabled server, then that resource should not be subject to require-sri-for, no?

Contributor

shekyan commented Jun 3, 2016

I thought that's the intention behind all this? That nobody can use scripts without using integrity (and thus requesting from a CORS-enabled server or a same-origin server).

Yes, but if SRI does not provide a way to verify integrity of a resource from CORS-disabled server, then that resource should not be subject to require-sri-for, no?

@mikewest

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Jun 3, 2016

Member

Again, that sounds to me like an argument that SRI should be extended to support resource types it doesn't yet support, not that the current model is a bad one.

Member

mikewest commented Jun 3, 2016

Again, that sounds to me like an argument that SRI should be extended to support resource types it doesn't yet support, not that the current model is a bad one.

@mozfreddyb

This comment has been minimized.

Show comment
Hide comment
@mozfreddyb

mozfreddyb Jun 3, 2016

Contributor

Yes, but if SRI does not provide a way to verify integrity of a resource from CORS-disabled server, then that resource should not be subject to require-sri-for, no?

I strongly disagree. If there's no way to verify integrity, then there's no way that resource is safe to use. The keyword quite literally says require integrity ;)

Contributor

mozfreddyb commented Jun 3, 2016

Yes, but if SRI does not provide a way to verify integrity of a resource from CORS-disabled server, then that resource should not be subject to require-sri-for, no?

I strongly disagree. If there's no way to verify integrity, then there's no way that resource is safe to use. The keyword quite literally says require integrity ;)

@shekyan

This comment has been minimized.

Show comment
Hide comment
@shekyan

shekyan Jun 4, 2016

Contributor

I strongly disagree. If there's no way to verify integrity, then there's no way that resource is safe to use. The keyword quite literally says require integrity ;)

Ultimately, I agree with you, e.g. SRI should be able to verify the integrity of all <script> elements, except if they should not be verified for security reasons.
Practically, require-sri-for would have very limited usage today, because, for example, Google Analytics serves it's code without Access-Control-Allow-Origin, so no way to load the resource anonymously, thus enable SRI on it.
I don't know if anything can be done on SRI land to fix this.
I'll try to tackle CORS spec authors to understand why it is not possible to send anonymous requests to CORS-disabled servers.

Contributor

shekyan commented Jun 4, 2016

I strongly disagree. If there's no way to verify integrity, then there's no way that resource is safe to use. The keyword quite literally says require integrity ;)

Ultimately, I agree with you, e.g. SRI should be able to verify the integrity of all <script> elements, except if they should not be verified for security reasons.
Practically, require-sri-for would have very limited usage today, because, for example, Google Analytics serves it's code without Access-Control-Allow-Origin, so no way to load the resource anonymously, thus enable SRI on it.
I don't know if anything can be done on SRI land to fix this.
I'll try to tackle CORS spec authors to understand why it is not possible to send anonymous requests to CORS-disabled servers.

@shekyan

This comment has been minimized.

Show comment
Hide comment
@shekyan

shekyan Jun 4, 2016

Contributor

Oh man. I totally missed @mikewest comment. I am ok with that and this PR seems to be ready to go then if there is no other objections!

Contributor

shekyan commented Jun 4, 2016

Oh man. I totally missed @mikewest comment. I am ok with that and this PR seems to be ready to go then if there is no other objections!

@devd

This comment has been minimized.

Show comment
Hide comment
@devd

devd Jun 4, 2016

Contributor

If we are going with "enforce this even for cases where you can't specify
integrity" then I would really prefer a note about that before landing.
On Jun 4, 2016 10:34 AM, "Sergey Shekyan" notifications@github.com wrote:

Oh man. I totally missed @mikewest https://github.com/mikewest comment.
I am ok with that and this PR seems to be ready to go then if there is no
other objections!


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#32 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAIXGek0onFU_zdZEudRIh1SKv-qkP0Tks5qIbdAgaJpZM4IYdBU
.

Contributor

devd commented Jun 4, 2016

If we are going with "enforce this even for cases where you can't specify
integrity" then I would really prefer a note about that before landing.
On Jun 4, 2016 10:34 AM, "Sergey Shekyan" notifications@github.com wrote:

Oh man. I totally missed @mikewest https://github.com/mikewest comment.
I am ok with that and this PR seems to be ready to go then if there is no
other objections!


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#32 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAIXGek0onFU_zdZEudRIh1SKv-qkP0Tks5qIbdAgaJpZM4IYdBU
.

@shekyan

This comment has been minimized.

Show comment
Hide comment
@shekyan

shekyan Jun 6, 2016

Contributor

@devd, added a note.

Contributor

shekyan commented Jun 6, 2016

@devd, added a note.

@devd devd merged commit d776be7 into w3c:master Jun 6, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@devd

This comment has been minimized.

Show comment
Hide comment
@devd

devd Jun 6, 2016

Contributor

thanks! this looks good. merging since everyone else ok'ed it.

Contributor

devd commented Jun 6, 2016

thanks! this looks good. merging since everyone else ok'ed it.

@mikewest

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Jun 21, 2016

Member

Would y'all mind publishing this document somewhere? It's tough to skim through sections when reviewing patches, as I end up needing to come back to this PR rather than reading a nicely formatted doc. :)

Member

mikewest commented Jun 21, 2016

Would y'all mind publishing this document somewhere? It's tough to skim through sections when reviewing patches, as I end up needing to come back to this PR rather than reading a nicely formatted doc. :)

@devd

This comment has been minimized.

Show comment
Hide comment
@devd

devd Jun 21, 2016

Contributor

done at https://w3c.github.io/webappsec-subresource-integrity/index.bikeshed.html

Since v1 is in the final stages of becoming a rec, I din't want to touch index.html. Once it is done, I will update index.html too.

Contributor

devd commented Jun 21, 2016

done at https://w3c.github.io/webappsec-subresource-integrity/index.bikeshed.html

Since v1 is in the final stages of becoming a rec, I din't want to touch index.html. Once it is done, I will update index.html too.

@ptoomey3

This comment has been minimized.

Show comment
Hide comment
@ptoomey3

ptoomey3 Jun 25, 2016

Just now saw this was merged. Thanks so much for the effort ❤️.

ptoomey3 commented Jun 25, 2016

Just now saw this was merged. Thanks so much for the effort ❤️.

@mozfreddyb

This comment has been minimized.

Show comment
Hide comment
@mozfreddyb

mozfreddyb Sep 12, 2016

Contributor

FYI, I started a discussion on the mailing list. It is about APIs that do not know about integrity metadata (e.g. CSS @import and importScript() and the new Worker constructor in JS) and whether they should be blocked by require-sri-for.

Please read the thread and send your feedback!
https://lists.w3.org/Archives/Public/public-webappsec/2016Sep/0027.html

cc @ptoomey3 @shekyan @devd

Contributor

mozfreddyb commented Sep 12, 2016

FYI, I started a discussion on the mailing list. It is about APIs that do not know about integrity metadata (e.g. CSS @import and importScript() and the new Worker constructor in JS) and whether they should be blocked by require-sri-for.

Please read the thread and send your feedback!
https://lists.w3.org/Archives/Public/public-webappsec/2016Sep/0027.html

cc @ptoomey3 @shekyan @devd

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