1500083 - Consider exempting TYPE_XBL loads from CSP

Status: RESOLVED FIXED

(Core :: DOM: Security, enhancement, P2)

Description

[Christoph Kerschbaumer [:ckerschb]]

Once we move the CSP away from the Principal and into the Client (See Bug 965637) and in particular once we let systemPrincipal calls through to CSP (see Bug  1496418) we will be starting to block loads of TYPE_XBL within default-src if not whitelisted by the CSP. I don't think we want that actually, because XBL is a browser internal thing.

Potentially we should update subjectToCSP() and give loads of TYPE_XBL a free pass.

Comment 1

[Christoph Kerschbaumer [:ckerschb]]

As an example, the activity stream code which uses default-src 'none' will start blocking chrome://global/content/platformHTMLBindings.xml.

Comment 2

[Christoph Kerschbaumer [:ckerschb]]

Attachment: bug_1500083_whitelist_type_xbl_for_csp.patch

Dan, please see comment 0 for description of the problem.

Acceptable, or am I missing something?

Please note that at the moment such loads will never get through to CSP because the are system principal loads anyway which we already shortcut and green light within nsContentPolicyUtils.

Comment 3

[Daniel Veditz [:dveditz]]

Why is CSP blocking any chrome: url? I thought chrome: and moz-extension: resources got a free pass regardless of the CSP settings. Otherwise we're breaking add-ons/WebExtensions.

Or is this special-cased so that we only check chrome: urls (presumably against a CSP whitelist with path, or at least with package) for system privileged pages? In that case we'd _want_ to block XBL that wasn't whitelisted, and default-src: 'none' really means "none -- I want no scripty things at all here".

Comment 4

[Christoph Kerschbaumer [:ckerschb]]

Attachment: bug_1500083_whitelist_type_xbl_for_csp.patch

(In reply to Daniel Veditz [:dveditz] from comment #3)
> Why is CSP blocking any chrome: url? I thought chrome: and moz-extension:
> resources got a free pass regardless of the CSP settings.

Initially all chrome: and resource: URIs where whitelisted and not subject to any CSP restrictions. Then we encountered Bug 1432358 and updated that setting. (Folowing we whitelisted a little more within Bug 1490793).

So, I guess you are right, I slightly changed the patch to only allow XBL if we are trying to load a chrome: or resource: URI.

Comment 5

[Daniel Veditz [:dveditz]]

Comment on attachment 9019013 [details] [diff] [review]
bug_1500083_whitelist_type_xbl_for_csp.patch

Review of attachment 9019013 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks, seems better to have a more limited exception like this. Of course the original problem could have been solved by Activity Stream changing their default-src from 'none' to chrome://whatever (but then possibly having to add more directives with explicit 'none'). Hopefully more than just this one page will benefit from this change.

r=dveditz

Comment 6

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Daniel Veditz [:dveditz] from comment #5)
> Thanks, seems better to have a more limited exception like this. Of course
> the original problem could have been solved by Activity Stream changing
> their default-src from 'none' to chrome://whatever (but then possibly having
> to add more directives with explicit 'none'). Hopefully more than just this
> one page will benefit from this change.

Indeed, though there are more pages that would have to be updated. So ultimately more pages benefit from that change.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f09bd717691e
Exempt TYPE_XBL loads from CSP. r=dveditz

Comment 8

[Andrei Ciure[:aciure]]

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