Open Bug 1557114 Opened 5 years ago Updated 2 years ago

Evaluate if we use the right CSP for frame navigations


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





(Reporter: ckerschb, Unassigned)


(Blocks 1 open bug)


(Whiteboard: [domsecurity-backlog1])


(1 file, 1 obsolete file)

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 or something else in the spec?


Attached file frame-src scenarios (obsolete) —

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.

Attached file frame-src scenarios
Attachment #9070122 - Attachment is obsolete: true
Attachment #9070123 - Attachment description: bug1555050.html → frame-src scenarios

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

I'm not quite sure what to make of

To be clear, this is only relevant for the navigate-to and form-action directives, right? It's using 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 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 step 2.4 calling 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?

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.

Flags: needinfo?(dveditz)

OK, I put a version of that testcase that I think doesn't have the inheritance problem up at

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 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?

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

Flags: needinfo?(dveditz)

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.

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(ckerschb)
Flags: needinfo?(ckerschb)
Priority: -- → P2
Severity: normal → S3

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

Assignee: ckerschb → nobody
Blocks: csp-w3c-3
Whiteboard: [domsecurity-active] → [domsecurity-backlog1]
You need to log in before you can comment on or make changes to this bug.