What does it mean to alias a policy from a CSP list?

[bzbarsky]

https://w3c.github.io/webappsec-csp/#initialize-document-csp talks about aliasing policies from opener/parent documents.

But as far as I can tell, policies are immutable, really. What can mutate is the "CSP list" of the document. For example, https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-content-security-policy calls https://w3c.github.io/webappsec-csp/#enforced which just inserts the policy into the CSP list. So what does it mean to alias things when initializing the document's CSP?

[andypaicu]

What I take it to mean is just to insert a pointer to the parent policy in the CSP list of the child.

I think that is consistent with the general idea of aliases as way to access the same memory space using different "names" or "handles".

This could be spelled out in more details of course just to remove ambiguity.

[bzbarsky]

My point is that you have a "CSP list", which contains "policies". Policies are immutable as currently specced, as far as I can tell. The "CSP list" can be mutated by adding or removing policies.

So there's no observable difference between copying and aliasing a policy, because policies are immutable anyway. If the idea is to "use whatever policies the parent/opener is using", you have to alias the "CSP list", not policies.

[bzbarsky]

@mikewest Can you please get this sorted out? Browsers are not interoperable here, which seems like a serious problem for CSP deployment...

[ckerschb]

@mikewest, we just experienced a bug [1] where a page creates an iframe using

frame = document.createElement("iframe");
document.body.appendChild(frame);

and then adds a meta CSP to that iframe. Since it's a same origin iframe, the iframe and the top-level page share the same principal. Ultimately, since the CSP hangs of the principal within Firefox, the CSP hoists to the embedding page and starts blocking content on the top-level document :-(

It seems Chrome behaves differently. Even though it sounds odd, I am not sure Firefox behavior is wrong here. Anyway, what do you think?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1419222#c4

[mikewest]

Thanks to you both for raising this. I agree that the language in the spec today isn't good. We should fix it together.

I think that we should have typed something like "copy" rather than "alias" in a few places. That is, I think Chrome's behavior is what I'd like to keep, but we should chat about it.

In the scenario you've spelled out, it seems valuable for a page to be able to break off a piece of itself and lock it down in a frame. Doing that in a way that doesn't persist the policy back up to the containing document is desirable in that case, as the framed page should have less privilege than the container.

Would you be willing to build that kind of behavior into Firefox if we did a better job specifying it? Or do you think Firefox's behavior is what we ought to run with in general?

Also, have you looked at Safari/Edge's behavior in the same scenario? If Chrome is the odd one out, I'm sure we can change our behavior instead.

[ckerschb]

I personally think Chrome's behavior is more intuitive and Firefox wants to get away from having the CSP on the nsIPrincipal anyway. I think I am willing to change Firefox behavior if we can spell out the behavior more explicitly in the spec.

[andypaicu]

Coincidentally I have a PR that replaces alias with copy which should separate the policies after the init part.

#273

Is there anything else that should be spelled out? Is the concept of a copy of a policy self-explanatory enough?

[bzbarsky]

What would need to be copied is the policy list, presumably.

[andypaicu]

I will close this bug since everyone seems to be happy now.