Closed Bug 1419222 Opened 2 years ago Closed 5 months ago
iframe CSP is blocking content in the parent document
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
Component: Untriaged → DOM: Security
Product: Firefox → Core
Assignee: nobody → ckerschb
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
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.
See Also: → 965637
(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.
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
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?
(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.
> 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.
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.
For what it's worth, we are discussing spec options at: https://github.com/w3c/webappsec-csp/issues/207
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.  https://bugzilla.mozilla.org/show_bug.cgi?id=965637#c10
Assignee: ckerschb → nobody
Status: ASSIGNED → NEW
Priority: P2 → P3
Whiteboard: [domsecurity-active] → [domsecurity-backlog1]
Assignee: nobody → jallmann
Status: NEW → ASSIGNED
You need to log in before you can comment on or make changes to this bug.