1419222 - iframe CSP is blocking content in the parent document

Status: RESOLVED FIXED

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

Description

[thiagotbl]

Attachment: cspbug.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce:

Firefox version 56.0.1 (64-bit)

CSP applied to iframe is interfering in parent CSP rules (even after iframe is removed)

Steps to repro:
1. Please open the attached html in Firefox. Please note that there is no img-src CSP is set to "* data:"
2. See that it correctly loads the image
3. Click the button -> it will append an iframe to the document body with the following CSP: "default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; font-src 'self';", and it will also append the same image that was loaded in the html


Actual results:

img is not loaded


Expected results:

img should load fine, since the CSP restriction is applied to the iframe
All other browsers (Chrome and Edge) load the image.

The bug also happens if you remove the iframe before inserting the new img tag

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

This is probably another case where we accidentally shared an nsIPrincipal with CSP on it and propagated things when we shouldn't.

We should really consider doing bug 965637 in the near future.

Comment 2

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Ben Kelly [:bkelly] from comment #1)
> We should really consider doing bug 965637 in the near future.

I agree, I am all up for moving the CSP away from nsIPrincipal.

Comment 3

[thiagotbl]

Thanks for looking into that issue so quickly everyone.
In the meantime, is there any workaround that can be done to overcome this?
I can't change the behavior since I use a 3rd party library that adds the iframe with a CSP set (which I want to be more restrictive than the parent document).

Thanks

Comment 4

[Christoph Kerschbaumer [:ckerschb]]

It seems what's happening here is the following: the page creates a new iframe using
> frame = document.createElement("iframe");
> document.body.appendChild(frame);
and then adds a CSP to that iframe. Since it's a same origin iframe, we reuse the principal of the top-level page and literally add a CSP to that principal, which in turn applies the CSP to the top-level document.

Boris, what do you think, should we generate a copy of the principal in that case? If so, where should we ideally do that, within docshell or does it need to happen earlier?

Comment 5

[Christoph Kerschbaumer [:ckerschb]]

(In reply to thiagotbl from comment #3)
> Thanks for looking into that issue so quickly everyone.
> In the meantime, is there any workaround that can be done to overcome this?
> I can't change the behavior since I use a 3rd party library that adds the
> iframe with a CSP set (which I want to be more restrictive than the parent
> document).

In that case I guess there is not much you can do as a workaround at this time - sorry.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Boris, what do you think, should we generate a copy of the principal in that case?

No, what you should do is stop tying CSP to principals.  See comment 1.  You can't sanely "generate a copy of the principal" and have things work correctly if it's representing a unique origin.

That said, it's not clear what the right behavior here even is, per spec.  See https://github.com/w3c/webappsec-csp/issues/207 which hasn't gotten a useful response from anyone working on the spec in over 6 months now.

Comment 7

[Boris Zbarsky [:bzbarsky]]

And to be clear, the spec talks about the CSP of the iframe in this case aliasing something about the parent, but isn't very clear on what, exactly.  If it's supposed to alias the CSP of the parent, then our behavior is correct per spec.  Please just keep pinging Mike West until you have at least the desired behavior clear.

Comment 8

[Christoph Kerschbaumer [:ckerschb]]

For what it's worth, we are discussing spec options at:
https://github.com/w3c/webappsec-csp/issues/207

Comment 9

[Christoph Kerschbaumer [:ckerschb]]

FWIW, we agreed on updating the spec to be more explicit. In turn, that means that the iframe in that scenario should 'copy' the CSP from the parent but the CSP from the iframe should not hoist to the embedding document/parent.

As explained, this problem can not easily be fixed because the CSP hangs of nsIPrincipals within Firefox. Ultimately we have to fix Bug 965637 by moving the CSP from the nsIPrincipal over to ClientInfo. This requires some major refactoring; I will update our roadmap accordingly.

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

Comment 12

[Jonas Allmann [:jallmann]]

Attachment: Bug 1419222, Add test for correct handling of iFrame CSPs, r=ckerschb

Comment 13

[Jonas Allmann [:jallmann]]

It seems like this bug has been resolved in the meantime, it's not reproducible anymore.
I wrote a test to show that and suggest the bug is closed after the test lands.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Looks to me like bug 965637 fixed this, in particular.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bf2586dc8256
Add test for correct handling of iFrame CSPs, r=ckerschb

Comment 16

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/bf2586dc8256