Content Security Policy violation on devtools launch
Categories
(DevTools :: Inspector, defect, P4)
Tracking
(firefox-esr68 unaffected, firefox-esr78 wontfix, firefox77 wontfix, firefox78 wontfix, firefox79 verified)
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | wontfix |
firefox77 | --- | wontfix |
firefox78 | --- | wontfix |
firefox79 | --- | verified |
People
(Reporter: bradwerth, Assigned: bradwerth)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file, 2 obsolete files)
Steps to Reproduce:
- Navigate to about:blank.
- Open the Browser Console and clear it.
- Open Devtools Inspector.
Expected Results:
Nothing appears in the Browser Console.
Actual Results:
Content Security Policy: The page’s settings blocked the loading of a resource at inline (“default-src”). panel.js:78
This is leading to confused reporting of CSP issues in unrelated bugs.
Assignee | ||
Comment 1•4 years ago
|
||
Here's a more complete JS stack when this CSP error is hit:
0 initialize() ["chrome://global/content/elements/panel.js":78:24]
this = [object XULPopupElement]
1 connectedCallback() ["chrome://global/content/elements/panel.js":46:13]
this = [object XULPopupElement]
2 HTMLTooltip(toolboxDoc = "[object HTMLDocument]", (destructured parameter) = "[object Object]") ["resource://devtools/client/shared/widgets/tooltip/HTMLTooltip.js":404:29]
this = [object Object]
3 initializeTooltip() ["resource://devtools/client/shared/components/menu/MenuButton.js":175:19]
this = [object Object]
4 MenuButton(props = "[object Object]", "[object Object]") ["resource://devtools/client/shared/components/menu/MenuButton.js":115:9]
5 constructClassInstance(workInProgress = "[object Object]", ctor = [function], props = "[object Object]", renderExpirationTime = "1073741823") ["resource://devtools/client/shared/vendor/react-dom.js":8270:17]
6 updateClassComponent(current$$1 = "null", workInProgress = "[object Object]", Component = [function], nextProps = "[object Object]", renderExpirationTime = "1073741823") ["resource://devtools/client/shared/vendor/react-dom.js":10592:26]
Assignee | ||
Comment 2•4 years ago
|
||
This has some interesting similarities with Bug 1228985, in that the failed resource load is from a style element with no triggering principal. Which style element it is, and what created it I'm not clear yet. If the style element had a triggering principal upon creation, it would load without a CSP error.
Assignee | ||
Comment 3•4 years ago
•
|
||
Style element seems to be created by menupopup.js and instantiated when the tooltip is added to the document in the HTMLTooltip constructor. The style element is created with no triggering principal. Part of the problem is that HTMLStyleElement::BindToTree
does not set the principal before triggering the initial update of the stylesheet. When that update happens, there's no principal, so inline style is blocked by -- I think -- the CSP declaration for the devtools application.
Edit -- that is not the relevant CSP declaration. The CSP is associated with the "about:devtools-toobox" document, and is declared in devtools/client/framework/toolbox.xhtml.
Assignee | ||
Comment 4•4 years ago
|
||
Assignee | ||
Comment 5•4 years ago
|
||
Depends on D77721
Assignee | ||
Comment 6•4 years ago
|
||
The proposed solution here involves two parts:
- Associating a system principal with the inline style tags created when devtools is rendered.
- Making system principals allow inline style by default.
I've proposed the second change before, in another bug where we were trying to allow devtools to edit inline style on pages with a CSP. Instead, in that case, we added a flag to a CSP object to skip the inline check. Here is another case where, if system principals skipped the inline style check, we would get a helpful result. Is this an acceptable change to the behavior of the inline style check? If not, what sort of security problems would it create?
Comment 7•4 years ago
|
||
Looks good to me, but I'm not an expert to answer this question. Pass the ball to baku.
Assignee | ||
Comment 8•4 years ago
|
||
This was a surprising regression result. I expected that the CSP added around the same time in Bug 1577446 would be responsible, but apparently not.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 9•4 years ago
|
||
Are these 2 patches ready to be reviewed? Do you mind adding them to my review queue? Thanks.
Assignee | ||
Comment 10•4 years ago
|
||
(In reply to Andrea Marchesini [:baku] from comment #9)
Are these 2 patches ready to be reviewed? Do you mind adding them to my review queue? Thanks.
Thank you for offering to review. I'm not sure this is the right approach yet. I want to understand the regressing bug better first, as well as understand which CSP is being applied when the triggering principal is null -- I'm not yet confident that it is the CSP mentioned in comment 3.
Assignee | ||
Comment 11•4 years ago
|
||
I'm exploring alternatives. One way to solve this would be to change the CSP declared in devtools/client/framework/toolbox.xhtml. When I do that, we hit an assert in nsContentSecurityUtils::AssertAboutPageHasCSP
which enforces that "about:" pages can't have inline-src.
Another idea is to prevent the XUL parser from using injected style tags, and instead inject link tags that point to approved CSS files. I'll see if I can put together a patch that does that. It might be non-trivial for me, in which case I'll seek approval of my original approach, because I don't have any other proposals on how to solve this.
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 12•4 years ago
|
||
This supports the fact that devtools, which is hosted in an "about:" page,
does not use inline styles. They are prevented from working by the CSP defined
at devtools/client/framework/toolbox.xhtml. This patch moves The styles that
are added by the MozPanel.initialize method into the popup.css files for each
theme, where the other .panel-arrowcontent class selectors live.
Comment 13•4 years ago
|
||
Comment 14•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Comment 15•4 years ago
|
||
The patch landed in nightly and beta is affected.
:bradwerth, is this bug important enough to require an uplift?
If not please set status_beta
to wontfix
.
For more information, please visit auto_nag documentation.
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 16•4 years ago
|
||
Confirmed issue with 77.0.1 on Windows 10.
Verified fix with 79.0b3 on Windows 10, macOS 10.15.5, Ubuntu 18.
Description
•