Closed Bug 1642376 Opened 4 years ago Closed 4 years ago

Content Security Policy violation on devtools launch

Categories

(DevTools :: Inspector, defect, P4)

defect

Tracking

(firefox-esr68 unaffected, firefox-esr78 wontfix, firefox77 wontfix, firefox78 wontfix, firefox79 verified)

VERIFIED FIXED
Firefox 79
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:

  1. Navigate to about:blank.
  2. Open the Browser Console and clear it.
  3. 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.

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]

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.

See Also: → 1228985

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.

Depends on D77721

The proposed solution here involves two parts:

  1. Associating a system principal with the inline style tags created when devtools is rendered.
  2. 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?

Flags: needinfo?(xeonchen)

Looks good to me, but I'm not an expert to answer this question. Pass the ball to baku.

Flags: needinfo?(xeonchen) → needinfo?(amarchesini)

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.

Regressed by: 1397876
Has Regression Range: --- → yes

Are these 2 patches ready to be reviewed? Do you mind adding them to my review queue? Thanks.

Flags: needinfo?(amarchesini) → needinfo?(bwerth)

(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.

Flags: needinfo?(bwerth)

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.

Attachment #9153268 - Attachment is obsolete: true
Attachment #9153269 - Attachment is obsolete: true

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.

Pushed by bwerth@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/431597af517c Move inline style for panel popups into each theme's popup.css. r=dao
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 79

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.

Flags: needinfo?(bwerth)
Flags: needinfo?(bwerth)

Confirmed issue with 77.0.1 on Windows 10.
Verified fix with 79.0b3 on Windows 10, macOS 10.15.5, Ubuntu 18.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: