CSPs for opaque-origin subresources

[jeffkaufman]

The interaction of Content Security Policy (CSP) and the urn:uuid web bundle subresources is not ideal. Imagine a site that configures a CSP:

Content-Security-Policy: script-src 'self'

Now they want to run urn:uuid scripts from the bundle (ex: #624). This will look like:

<link rel=webbundle href="/wbn" resources="urn:uuid:1234...">
<script src="urn:uuid:1234..."></script>

As implemented in the current origin trial, if they want to continue to use a url-based policy and allow the script to execute they must open up their CSP to urn:uuid resources:

Content-Security-Policy: script-src 'self' urn:uuid:*

Unfortunately, the CSP is now mostly useless. An attacker who can inject content into the page can do:

<link rel=webbundle href="https://evil.example/wbn" resources="urn:uuid:1234...">
<script src="urn:uuid:1234..."></script>

Even if we change subresource bundles from <link> to <script> (#580) there's the same issue for other types of resource. For example, if a site has frame-src 'self' they can't use subresource bundles, and if they open frame-src to allow urn:uuid:* they've opened the door to frames from any origin.

A related, but less severe, issue is that adopting subresource bundles requires CSP changes when it arguably shouldn't. For example, imagine a site that trusts ads.example to show ads on their page, and so has the CSP:

Content-Security-Policy: script-src 'self' https://ads.example;
                         frame-src https://ads.example

When ads.example tries to run a script from a urn:uuid subresource or use a urn:uuid subresource to create an ad iframe, it will be blocked. While this site has already indicated that they want to allow running JS and iframes loaded from ads.example, the current spec would require them to update their CSP to load them via bundles.

Unlike other opaque-origin resources like data: or blob:, which are directly under the control of the containing page, a urn:uuid subresource is a reference to a component of something with a globally-accessible URL. One way to fix these issues with urn:uuid subresources loaded from bundles, then, would be to evaluate the CSP restrictions against the source of the bundle instead of to the literal urn:uuid url. This would allow a site with:

Content-Security-Policy: script-src 'self'

to run:

<link rel=webbundle href="/wbn" resources="urn:uuid:1234…">
<script src="urn:uuid:1234..."></script>

without allowing:

<link rel=webbundle href="https://evil.example/wbn" resources="urn:uuid:1234...">
<script src="urn:uuid:1234..."></script>

We propose applying this to CSP directives concerning the URL only. For example, a site using a nonce-based policy would still put the nonce on the script element:

<link rel=webbundle href="/wbn" resources="urn:uuid:1234…">
<script src="urn:uuid:1234..." nonce=12345></script>

When loading any other resources from a bundle, either ones for which the bundle is authoritative or through some future mechanism like embedded signed exchange, this indirection would not apply.

[kinu]

/cc @mikewest here as well in case he wants to share more thoughts (or wants to add others here). It looked you're roughly on board when this was discussed on other thread but I might be misreading something!

[mikewest]

I think this is a reasonable approach conceptually.

Practically, I'm not at all sure how to integrate this into the CSP spec, however. We currently hook into Fetch, and examine the request's URL to determine whether it matches the page's policy. Do y'all have ideas about how you'd pipe through a concept of the request's URL's physical location in the webpackage case? Is this something for which you've already through about infrastructure? Similar questions will, I'm sure, come up during implementation...

(See step 6 of main fetch, for example, which pushes through to https://w3c.github.io/webappsec-csp/#should-block-request, and eventually https://w3c.github.io/webappsec-csp/#match-url-to-source-expression after a bit of indirection)

[horo-t]

I created a Chromium CL: https://crrev.com/c/2886721

I don't have concrete idea of how to integrate into the spec yet. But when we will convert the explainer to a specification, we will lookup the <link rel=webundle>s (or <script type=bundle>s?) in the document (request’s client) in https://fetch.spec.whatwg.org/#fetching , and use the matching bundle URL for https://w3c.github.io/webappsec-csp/#should-block-request.