forked from w3c/ServiceWorker
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Cause a Content-Security-Policy: sandbox header to unregister the Ser…
…vice Worker at that scriptURL. Joshua Peek suggested that this should work (http://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0109.html) because `sandbox` gives the resource a unique origin, which combines with Service Workers' same-origin policy to disallow execution. See w3c#113 and w3c#224.
- Loading branch information
Showing
1 changed file
with
11 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
b4c950f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this rejection not follow from the origin comparison?
b4c950f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can't quite: the origin comparison is syntactic on the scriptURL in [[Register]], but here it needs to be logical on the future worker context. I'm not even sure they can be unified in the long run since a syntactic mismatch should prevent the fetch that would discover the logical mismatch. The 'fixme' does suggest using the sandboxed origin browsing context flag instead of inspecting the header directly.
Implementing the 'fixme' depends on both w3c#378 and the fact that the spec of
sandbox
in CSP2 doesn't yet apply to workers, since it acts through the forced sandboxing flag set, which is only used as "The flags set on the Document's resource's forced sandboxing flag set, if it has one.")b4c950f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. So the idea is that you sandbox workers and that therefore they have unique origin and fail? Seems a bit hackish.
b4c950f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's totally a hack, but it seems to be consistent with existing meanings of existing syntax. Even when we get a better dedicated syntax (any of
Content-Security-Policy: serviceworker block
orContent-Security-Policy: context not-serviceworker
or something else), I think it'll make sense to keep the behavior from this patch forContent-Security-Policy: sandbox
since what else could that mean?Of course, if a better approach gets agreement on webappsec, I'm happy to drop this patch.
b4c950f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well if sandboxing doesn't make sense for workers unless allow-same-origin is set, I'm not sure we really want the same kind of sandboxing there, for instance. Would need some more careful consideration.