Cloned iframe in addon is blocked by CSP

NEW
Unassigned
(NeedInfo from)

Status

()

P5
normal
a year ago
3 months ago

People

(Reporter: calixte, Unassigned, NeedInfo)

Tracking

(Blocks: 1 bug)

59 Branch
Points:
---

Firefox Tracking Flags

(firefox59 affected)

Details

(Whiteboard: [domsecurity-backlog])

Attachments

(1 attachment)

(Reporter)

Description

a year ago
Created attachment 8931359 [details]
test-case.tar.gz

In test-case.tar.gz, get foo.html and serve it on localhost
Load the addon.
And open http://localhost/foo.html, only the first and third iframes are correctly loaded, the second one is blocked because of CSP.
In the addon, they use "cloneNode(true)" to clone an iframe, then add it to the DOM. Looks like that when we use cloneNode we lose the fact that it comes from an add-on ?
Component: DOM → DOM: Security
Kris: is it Web Extension code that's tracking whether nodes are created by extensions and should bypass CSP?
Flags: needinfo?(kmaglione+bmo)
(In reply to Daniel Veditz [:dveditz] from comment #2)
> Kris: is it Web Extension code that's tracking whether nodes are created by
> extensions and should bypass CSP?

No, it's DOM code.

I intentionally ignored the cloneNode case, and I'm still on the fence about whether we should handle it.
Blocks: 1267027
Flags: needinfo?(kmaglione+bmo)
At least this should be documented somewhere. Is there a place where we documented the CSP exceptions to web extensions-inserted code ?
(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #3)
> I intentionally ignored the cloneNode case, and I'm still on the fence about
> whether we should handle it.

Why wouldn't we allow it? It's still something the add-on is doing, and we allow the equivalent effect of the add-on inspecting the node and creating a new copy property by property.
Flags: needinfo?(kmaglione+bmo)
Priority: -- → P5
Whiteboard: [domsecurity-backlog]
You need to log in before you can comment on or make changes to this bug.