CSP integration for javascript: URLs seems to be broken

[bzbarsky]

For simplicity, let's start at https://html.spec.whatwg.org/multipage/links.html#following-hyperlinks-2 for a javascript: URL.

Step 12 creates a new request. It's not clear what its client is at this point (see whatwg/fetch#907), but given that various parts of the navigation algorithm set the client to things (e.g. in https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate-fetch), I'm going to assume it's null at the moment.

We then call into https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate which in step 13 calls into https://html.spec.whatwg.org/multipage/browsing-the-web.html#javascript-protocol. Step 2 of this calls into https://w3c.github.io/webappsec-csp/#should-block-navigation-request which in step 2 does:

For each policy in navigation request’s client’s global object’s CSP list:

So by that point we should really have a client set up, but we don't seem to.

In terms of what implementations do... For the specific case of <a href>, Chrome doesn't support targeting it, so there is only one sane global to use around. But for location.href sets or modifications of the src attribute of <iframe>, it should be observable which global's CSP gets used here.

[domenic]

OK, so the action here is to write tests involving multi-global situations, where one global has CSP applied and one doesn't, and to try to invoke javascript: URLs. When we figure out which global's CSP policy applies, we can use that to specify a client.

(Unless there is a clearly-sensible answer a priori, that we should get browsers to converge on regardless of what they currently do?)

[bzbarsky]

It's not at all clear to me what the "right" answer is, even from first principles of what the goal of preventing inline script via CSP is. And yes, I agree that we need tests to see what browsers are actually doing here.

[bzbarsky]

OK, I wrote some tests:

• https://web.mit.edu/bzbarsky/www/testcases/security/csp-javascript-url-no-source-csp.html
• https://web.mit.edu/bzbarsky/www/testcases/security/csp-javascript-url-source-csp.html
• https://web.mit.edu/bzbarsky/www/testcases/security/csp-javascript-url-auxiliary-no-source-csp.html
• https://web.mit.edu/bzbarsky/www/testcases/security/csp-javascript-url-auxiliary-source-csp.html

(They're not WPTs because I needed a simple way to run them in release browsers). The first two tests test doing javascript: loads in subframes that may or may not have CSP that blocks scripts. The second test has a CSP that blocks inline scripts on the toplevel page. The third and fourth tests are similar but use auxiliary browsing contexts (popups) instead of subframes. These tests do not try to tease out the difference between incumbent and entry objects for location sets. They also do not try to tease out when and whether CSP gets snapshotted and/or the exact timing of the CSP checks (this can matter given that <meta> can modify CSP).

Observed behavior seems to be as follows, as far as I can tell, where source and target correspond to the documents of source and browsingContext in https://html.spec.whatwg.org/multipage/browsing-the-web.html#javascript-protocol

• Chrome 76.0.3800.0 dev: Blocks the execution if either source or target has a CSP that would block execution, which just isn't supported at all by the current spec, since that only does one CSP check. Incidentally, it looks like https://bugs.chromium.org/p/chromium/issues/detail?id=889891 may be fixed now?
• Safari TP 57: Blocks execution if target has a CSP that would block execution. The anchor tests are meaningless because of https://bugs.webkit.org/show_bug.cgi?id=13543
• Firefox 67: Blocks execution if source has a CSP that would block execution.
• Firefox nightly as of today: Seems to match Chrome 76 dev for subframes but matches Safari TP 57 for auxiliary browsing contexts. This was a behavior change from a commit yesterday which is what got me looking into this to start with...

[bzbarsky]

and/or the exact timing of the CSP checks (this can matter given that <meta> can modify CSP).

It also matters because CSP violations get reported, and these reports are observable (possibly even within the page, with reporting API). If the Chrome behavior is decided on, then obviously the order of the two CSP checks needs to be specified, because it will affect the reporting that happens.

@mikewest @ckerschb

[bzbarsky]

@dveditz

[bzbarsky]

Given the state of the spec and implementations, by the way, I'm pretty curious what the WPTs at https://wpt.fyi/results/content-security-policy/navigation are based on, if anything.

[bzbarsky]

So one plausible path to interop and greater security here is:

1. Navigations should snapshot the CSP of their client at navigation start time. That client should be determined in an identical way for javascript: navigations and fetch navigations.
2. javascript: navigations should perform CSP checks against both the snapshot CSP and the CSP of the document in whose global they will be executed. This is basically the Chrome behavior, which is the strictest of the above behaviors, but presumably web-compatible enough, since Chrome is shipping it.
3. javascript: loads from user (or extension?) actions should presumably be exempted from both CSP checks. The extent to which this sort of thing can be standardized is not clear to me.

[bzbarsky]

@mikewest Could you, or whoever is actively doing CSP work in Chrome, please take a look at #4651 (comment) and respond with thoughts?