1571937 - CSP blocks default extension icon for extensions on AMO that don't declare an icon in their manifest

Status: VERIFIED FIXED

(DevTools :: about:debugging, defect, P1)

Description

[Trevor Rowbotham [:rowbot]]

Using latest Nightly on Windows 10.

STR:

1. Install Link Cleaner extension.
2. Open about:debugging.
3. Choose "This Nightly" to find the list of installed extensions to debug.

The icon for the Link Cleaner extension in about:debugging is missing. The following is logged to the Web Console:

Content Security Policy: The page’s settings blocked the loading of a resource at https://addons.cdn.mozilla.net/static/img/addon-icons/default-64.png (“img-src”). react-dom.js:2584:13

I think what is happening is that extensions listed on AMO, that don't declare an icon in their manifest, are served this[1] default icon or its 32px[2] variant. Extensions that are installed, but are not listed on AMO, such as the Devtools ADB Extension, are served a different default icon[3] with the chrome: scheme. The later is compatible with the devtools CSP.

A quick fix could be to listen for the error event on the image, displaying [3] in the event that an extension's icon fails to load.

Alternatively, you could add https://addons.cdn.mozilla.net to the CSP, but that may be undesirable.

In the long run, AMO should probably be using the same icon default icon[3] as the browser does for consistency, though that still doesn't solve the CSP issue.

[1] https://addons.cdn.mozilla.net/static/img/addon-icons/default-64.png
[2] https://addons.cdn.mozilla.net/static/img/addon-icons/default-32.png
[3] chrome://mozapps/skin/extensions/extensionGeneric.svg

Comment 1

[Julian Descottes [:jdescottes]]

Thanks for logging, this is a regression from our recent change to add a CSP to about:debugging: https://bugzilla.mozilla.org/show_bug.cgi?id=1499064

Christoph, could we relax the CSP to allow http/https as image-src for about:debugging or would it create a security issue? As reported by Trevor, some addons apparently point to http icons, and about:debugging currently tries to display them directly.

If it's a problem, for now we could show the default icon and maybe later on simply fetch the icon on the server and pipe it as base 64 to the client.

Comment 2

[Christoph Kerschbaumer [:ckerschb]]

That's fine - I'll fix that. The most important thing is to not execute remote script or inline script which is not the case here. Images are fine.

Comment 3

[Christoph Kerschbaumer [:ckerschb]]

It seems that adding |https:| to the img-src directive should suffice to get things working again. If we really need we could relax the CSP further to also allow to load http: images, but if possible we should try to keep https: only.

Comment 4

[Christoph Kerschbaumer [:ckerschb]]

Attachment: Bug 1571937: Relax CSP for images on about:devtools to allow loading https images.r=jdescottes

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b5f39465aebf
Relax CSP for images on about:devtools to allow loading https images.r=jdescottes

Comment 6

[Razvan Maries]

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

Comment 7

[Cristian Fogel [:cfogel]]

Confirmed issue with 70.0a1 (2019-08-06)
Verified fix with 71.0a1 (2019-09-19) , 70.0b7 on Windows 10, macOS 10.13, Ubuntu 16.04.