MV3 web_accessible_resources fails to match requests from a sandboxed document, should fall back to precursor
Categories
(WebExtensions :: General, defect)
Tracking
(Not tracked)
People
(Reporter: robwu, Unassigned, NeedInfo)
References
Details
Bug 1685123 is working on support for the manifest sandbox key, which would enable extensions to declare extension pages as sandboxed. Such pages have an opaque origin (null principal) and are unable to load extension subresources, unless explicitly allowed in web_accessible_resources.
In Chrome, the mere presence of web_accessible_resources is enough for a resource to become eligible from loading by an extension. This is because any resource declared as web-accessible is automatically accessible by an extension itself (by definition, this is documented), and Chrome's implementation falls back to the precursor in case of opaque origins (relevant Chromium source code). This logic applies to any opaque origin (e.g. sandboxed web pages, not just sandboxed extension documents).
In Firefox we currently do not fall back to the precursor; we just use whatever the principal serializes to, which in case of null principals is an useless moz-nullprincipal:-URL that does not match anything (except for the logic introduced in bug 2033905 that permits <all_urls> and *://*/*).
Currently, the only work-around is to use MV2 or to add matches: ["<all_urls>"]. Neither are ideal if all that an extension wants is to expose a resource to a specific website or extension.
What we should do is to fall back to the precursor if a null principal is encountered. There is one subtle detail that we need to decide on: whether we want to require an item to be in web_accessible_resources before considering exposing it to a sandboxed extension document.
Relevant code:
WebExtensionPolicyCore::SourceMayAccessPath ultimately checks whether an extension resource can be loaded, given the requested path and a "source URI". This URI is received a bit higher in the call stack, from nsScriptSecurityManager::CheckLoadURIFlags, which in turn receives the URI from its (two) callers in nsScriptSecurityManager::CheckLoadURIWithPrincipal, effectively derived from a principal's URI. That logic is mostly all right, except in case of sandboxed documents.
Comment 1•2 days ago
|
||
The severity field is not set for this bug.
:rpl, could you have a look please?
For more information, please visit BugBot documentation.
Description
•