1557114 - Evaluate if we use the right CSP for frame navigations

Status: NEW

(Core :: DOM: Security, defect, P2)

Description

[Christoph Kerschbaumer [:ckerschb]]

This is a follow up bug to Bug 1555050 where Boris raised the following questions [1,2]:

I'm solely talking about navigations, and in particular subframe navigations. Do we apply frame-src checks to those, even if the navigation was not due to changing the "src" attribute?

If so, the issue is that for subframe navigations in our impl GetCsp() always returns the CSP of the <iframe> element's owner document, not the CSP of the navigation's fetch's client, right?

Where do we do frame-src enforcement, and which CSP do we use for it? Which CSP does the spec say to use for it? Is frame-src enforcement done by https://w3c.github.io/webappsec-csp/#should-block-request or something else in the spec?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1555050#c8
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1555050#c9

Comment 1

[Daniel Veditz [:dveditz]]

Attachment: frame-src scenarios

Here's a test file with various scenarios testing a parent document's CSP frame-src, both from the parent and from inside the frame.

Comment 2

[Daniel Veditz [:dveditz]]

Attachment: frame-src scenarios

Comment 3

[Daniel Veditz [:dveditz]]

With these tests I get the same behavior with Firefox, Safari, and Chrome. At least wrt which ones are blocked: when a frame load is blocked Chrome puts up an error placeholder while Firefox and Safari just cancel the load and leave the old content in place.

Whether the frame is navigated from without or within the frame-src directive rules. The "request's client" appears to be where the navigation is taking place, not the context it was started from.

I'm not quite sure what to make of https://w3c.github.io/webappsec-csp/#should-block-navigation-request -- at least it does mention there's two browsing contexts, source and target, but then doesn't mention them again. Does it imply checking appropriate CSP context of both? For framed content we'll eventually have to check navigate-to in the framed document as well as the frame-src of the parent.

Comment 4

[Boris Zbarsky [:bzbarsky]]

I'm not quite sure what to make of https://w3c.github.io/webappsec-csp/#should-block-navigation-request

To be clear, this is only relevant for the navigate-to and form-action directives, right? It's using https://w3c.github.io/webappsec-csp/#directive-pre-navigation-check which is only implemented for those two directives. But no, there's no "imply" going on: this check uses "request’s client’s global object’s CSP list" explicitly, which is going to be the GetCSPToInherit in our implementation. That's what we already do for form-action, because in the form submission case the client is the global of the owner document of the form, which is where we get the CSP from for that check.

I do notice that we have a bunch of failure annotations for form-action WPTs. Have we looked into why, and whether the tests match the spec? Also, why we have failure annotations for tests that https://wpt.fyi/results/content-security-policy/form-action?label=master&product=chrome%5Bexperimental%5D&product=edge&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned&q=form-action seems to think we are passing?

And while we're here, do we have any form-action WPTs where the source and target have different CSP? My spot-checking hasn't found any. We may need better test coverage here.

Anyway, frame-src would get applied via https://fetch.spec.whatwg.org/#concept-main-fetch step 2.4 calling https://w3c.github.io/webappsec-csp/#should-block-request which would use "request’s client’s global object’s CSP list" and then call into the various policy pre-request checks, etc. It sounds like for navigation requests this is all completely broken if the intended behavior is the one observed in browsers in the attached testcase. Who's the right person to get the spec here fixed?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Wait, I read the testcase again, and I don't get it. We have three documents here (toplevel, and the two iframes) but all three have the same CSP, no? That's because both data: and about:blank inherit CSP.

So this testcase isn't really telling us anything about which CSP gets applied, because all the CSPs in sight are identical, unless I'm missing something.

Comment 6

[Boris Zbarsky [:bzbarsky]]

OK, I put a version of that testcase that I think doesn't have the inheritance problem up at https://web.mit.edu/bzbarsky/www/testcases/security/csp-frame-src-parent.html

As far as I can tell, the basic conclusion holds, for this specific testcase: frame-src is enforced based on the parent document of the iframe targeted by the load, no matter what the client of the load is. I tried some other things (e.g. opening https://web.mit.edu/bzbarsky/www/testcases/security/csp-frame-src-parent.html as a new window from a same-origin page and poking newWindow.frames[0].location) and the conclusion seems to hold there too.

So it seems like the spec here is just bogus and needs to be fixed, no?

Comment 7

[Boris Zbarsky [:bzbarsky]]

I filed https://github.com/w3c/webappsec-csp/issues/400

Comment 8

[Daniel Veditz [:dveditz]]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #5)

So this testcase isn't really telling us anything about which CSP gets applied, because all the CSPs in sight are identical, unless I'm missing something.

I was not trying to distinguish between different CSPs but that browsers were consistent in applying the parent's "frame-src" rules to various ways to navigate the frames from within and without.

In the "about:blank" case once you load https://example.com into it then it no longer inherits from the parent, so it is in fact different in that case (but not in any interesting way).

Comment 9

[Boris Zbarsky [:bzbarsky]]

but that browsers were consistent in applying the parent's "frame-src" rules

The point is that the testcase was not distinguishing between it being the parent's rules or the navigation-starter's rules. But yes, if the question was whether frame-src applies at all to location-triggered navigations, fine.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:ckerschb, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 11

[Christoph Kerschbaumer [:ckerschb]]

We have higher priority projects we need to take care off right now - putting this one back in the backlog...