1785821 - Enforce "strengthen only" approach with CSP modifications by webRequest in MV3

Status: RESOLVED FIXED

(WebExtensions :: Request Handling, enhancement)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

At the moment ManifestVersion 2 extensions are allowed to fully replace the websites CSP if no other extension has also modified the same response headers before (see Bug 1635781 and Bug 1462989).

For ManifestVersion 3 extensions, we'd like to still allow this but lock it behind a separate permission that the extension that needs to fully override Website CSP will need to require through their manifest.json permissions.

To summarize the expected behaviors for ManifestVersion 3 extensions:

• without the additional permission, MV3 extensions will only be allowed to add more restriction to a pre-existing CSP header (if the website did have one)
• with the additional permission, MV3 extensions will behave like the MV2 extensions (and so an extension be allowed to fully replace the website CSP if no extension did change the header before, otherwise the CSP change will be added to the currently computed one)

Comment 1

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Bug 1785821 - Only allow manifest_version 3 extensions to merge CSP in the short run. r?mixedpuppy!,robwu

This patch includes:

• changes to WebRequest.jsm to always default to only merge the CSP headers returned by MV3 extensions

• changes to the test_ext_webRequest_mergecsp.js xpcshell test to cover the behavior expected with MV3 extensions and combinations of both MV2 and MV3 extensions changing CSP headers for the same intercepted web request.

For MV3 extensions we would prefer a more explicit and predictable way for the
extensions to be allowed to replace the CSP header, instead of keeping the same
unpredictable and implicit one that we currently support for MV2 extensions.

Comment 2

[Rob Wu [:robwu]]

Do we want to be specific about CSP headers (Content-Security-Policy and maybe also the non-enforcing Content-Security-Policy-Report-Only)?

Or are we looking for a general mechanism to make it more obvious when extensions can potentially downgrade the security of websites?
Other potentially security-relevant headers besides CSP are:

• XFO (= X-Frame-Options, comparable to CSP frame-ancestors)
• CORS: Access-Control-Allow-* response headers, Origin request header.
• COOP
• CORP
• COEP

CSP, COOP, CORP, XFO offer opt-ins to better security, so removing them degrades security.
CORS offers opt-in to relaxed security, so adding them degrades security, whereas removing them may impair functionality.
COEP offers opt-in to tighter security guarantees in order to unlock SharedArrayBuffer. Adding it doesn't degrade security (other than exposing a powerful API to content), but removing it may break functionality.

Comment 3

[Shane Caraveo (:mixedpuppy)]

After some lengthy discussion around site security and csp, in conjunction with product, we've decided to only follow the "MV3 extensions will only be allowed to add more restriction" pattern for all security headers without any option to downgrade security. In places where we might impact significant use cases we will consider alternative functionality next year.

Comment 4

[Rob Wu [:robwu]]

Fixed typo in subject. And while I am at it, I made it a bit more specific to avoid confusion with the extension's own CSP. The title mentions webRequest, but the policy will consistently be enforced in DNR.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b39e2a7cff0a
Only allow manifest_version 3 extensions to merge CSP in the short run. r=mixedpuppy

Comment 6

[Atila Butkovits]

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