Skip to content

Commit

Permalink
Cause a Content-Security-Policy: sandbox header to unregister the Ser…
Browse files Browse the repository at this point in the history
…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
jyasskin committed Jul 27, 2014
1 parent 451e11b commit b4c950f
Showing 1 changed file with 11 additions and 1 deletion.
12 changes: 11 additions & 1 deletion spec/service_worker/index.html
Original file line number Diff line number Diff line change
Expand Up @@ -95,6 +95,7 @@ <h1>Dependencies</h1>
<li><a href="http://tools.ietf.org/html/rfc6454">The Web Origin Concept</a></li>
<li><a href="http://url.spec.whatwg.org/">URL Living Standard</a></li>
<li><a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a></li>
<li><a href="http://www.w3.org/TR/CSP2/">Content Security Policy Level 2</a></li>
</ul>
</spec-section>

Expand Down Expand Up @@ -137,7 +138,7 @@ <h1>Concepts</h1>
<ol>
<li><em>Fetch</em>:
<br>
The script URL provided by the author (via a call to <code><a href="#navigator-service-worker-register">navigator.serviceWorker.register(<var>scriptURL</var>, <var>options</var>)</a></code> from a document) is fetched without <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.2">heuristic caching</a>. If the return status code of the fetch is not <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2">2xx</a>, installation aborts.</li>
The script URL provided by the author (via a call to <code><a href="#navigator-service-worker-register">navigator.serviceWorker.register(<var>scriptURL</var>, <var>options</var>)</a></code> from a document) is fetched without <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.2">heuristic caching</a>. If the return status code of the fetch is not <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2">2xx</a> or it is served with a <code><a href="http://www.w3.org/TR/CSP2/#content-security-policy-header-field">Content-Security-Policy</a></code> header that disallows use as a Service Worker, installation aborts.</li>
<li><em>Startup</em>:
<br>
If fetching the worker script is successful, it is <a href="http://www.w3.org/TR/workers/#processing-model">executed</a> in a <code><a href="#service-worker-global-scope">ServiceWorkerGlobalScope</a></code>. These scripts may call <code><a href="http://www.w3.org/TR/workers/#importing-scripts-and-libraries">importScripts</a></code> resulting in further fetches. Imported scripts are fetched, <a href="https://people.mozilla.org/~jorendorff/es5.1-final.html#sec-5.1.4">parsed</a> and <a href="https://people.mozilla.org/~jorendorff/es5.1-final.html#sec-10.4.1">executed</a> in turn, per the ECMA-262 and <a href="http://www.w3.org/TR/workers/#importing-scripts-and-libraries">Web Workers specifications</a>. All resources downloaded as part of the very first startup of a Service Worker are cached along with the worker script as described in <a href="#update-algorithm">"Worker Script Caching"<!--TODO(jungkees): add worker script caching section--></a>.
Expand Down Expand Up @@ -1747,6 +1748,15 @@ <h1>[[Update]]</h1>
<li>Abort these steps.</li>
</ol>
</li>
<li>Else if the server returned a <code>Content-Security-Policy</code> header including a <code><a href="http://www.w3.org/TR/CSP2/#directive-sandbox">sandbox</a></code> directive, then:
<p class="fixme">Once Service Workers use the <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#run-a-worker">run a worker</a> algorithm to start the Service Worker execution process, this should probably move inside the <a href="#installation-algorithm">[[Install]]</a> algorithm and refer to the worker's <a href="http://www.w3.org/TR/html5/browsers.html#sandboxed-origin-browsing-context-flag">sandboxed origin browsing context flag</a> inside its <a href="#forced-sandboxing-flag-set">forced sandboxing flag set</a>.</p>
<ol>
<li>Reject <var>promise</var> with a "<code><a href="http://dom.spec.whatwg.org/#securityerror">SecurityError</a></code>" exception.</li>
<li>Set <var>registration</var>.<a href="#update-promise-internal-property">[[UpdatePromise]]</a> to null.</li>
<li>Invoke the <a href="#unregister-algorithm">[[Unregister]]</a> algorithm passing <var>registration</var>.<var>scope</var> as its argument.</li>
<li>Abort these steps.</li>
</ol>
</li>
<li>Let <var>fetchedScript</var> be the fetched script.</li>
<li>Let <var>newestWorker</var> be the result of running the <a href="#get-newest-worker-algorithm">[[GetNewestWorker]]</a> algorithm passing <var>registration</var> as the argument.</li>
<li>If <var>newestWorker</var> is not null, and <var>newestWorker</var>.<var>scriptURL</var> is equal to <var>registration</var>.<a href="#script-url-internal-property">[[ScriptURL]]</a> and <var>fetchedScript</var> is a byte-for-byte match with the script of <var>newestWorker</var>, then:
Expand Down

5 comments on commit b4c950f

@annevk
Copy link

@annevk annevk commented on b4c950f Jul 28, 2014

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?

@jyasskin
Copy link
Owner Author

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

@annevk
Copy link

@annevk annevk commented on b4c950f Jul 28, 2014

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.

@jyasskin
Copy link
Owner Author

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 or Content-Security-Policy: context not-serviceworker or something else), I think it'll make sense to keep the behavior from this patch for Content-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.

@annevk
Copy link

@annevk annevk commented on b4c950f Jul 29, 2014

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.

Please sign in to comment.