Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistency: Default content_security_policy #98

Open
2 tasks
carlosjeurissen opened this issue Oct 3, 2021 · 22 comments
Open
2 tasks

Inconsistency: Default content_security_policy #98

carlosjeurissen opened this issue Oct 3, 2021 · 22 comments
Labels
inconsistency Inconsistent behavior across browsers topic: csp Related to content security policy enforcement

Comments

@carlosjeurissen
Copy link
Contributor

carlosjeurissen commented Oct 3, 2021

Background

Currently no good documentation is present on what the default content_security_policy is for every context (extension_pages, content_scripts and sandbox). This is a must when composing a custom CSP, especially when default-src is not set.

Firefox documentation gives:
script-src 'self'; object-src 'self';
See: MDN Docs

Chrome documentation gives:
default-src 'self'; connect-src * data: blob: filesystem:; style-src 'self' data: 'unsafe-inline'; img-src 'self' data:; frame-src 'self' data:; font-src 'self' data:; media-src * data: blob: filesystem:;
See: Chrome Docs. However, this seems to only apply to the legacy Chrome Apps.

Also no info is present on what the default is in MV3 or if it differs from MV2.

Action items

  • Have an overview of each default CSP in each context for each browser and manifest_version
  • Streamline the default CSP across browsers

Proposals

  1. To best showcase what an extension does, how it's permissions are used and to decrease the attack surface with security vulnerabilities, requiring default-src in custom CSP could be proposed.
  2. Have a default CSP (either as replacement or in addition to the above default) which won't be overridden by the extension custom CSP which will function next to the custom CSP. This could make restrictions more understandable / technically implementable.

See also:

@xeenon xeenon added the inconsistency Inconsistent behavior across browsers label Oct 25, 2021
@Rob--W
Copy link
Member

Rob--W commented Feb 17, 2022

The documentation that you've linked for Chrome is specific to Chrome apps, and the source code confirms that this is Chrome app-specific: https://source.chromium.org/chromium/chromium/src/+/main:extensions/common/manifest_handlers/csp_info.cc;l=44;drc=2d18bf1fec6017d20ced5b6110fdbfc8a342ebb5

Extensions have a default CSP similar to Firefox: https://source.chromium.org/chromium/chromium/src/+/main:extensions/common/manifest_handlers/csp_info.cc;l=33;drc=ce6c3b02c5cc847a3febdef23416e1ae7feaa9f9

@bradcush
Copy link

Linking this specific Chromium bug related to WASM support and the extension specific wasm-eval directive. https://bugs.chromium.org/p/chromium/issues/detail?id=1173354#c48 As mentioned, with the most recent updates in Chrome when run with the flag --enable-features=AllowWasmInMV3, wasm-eval can now be specified but WASM works as well now with no CSP specified whether the extension is run as MV2 or MV3.

@Rob--W Rob--W added the topic: csp Related to content security policy enforcement label Apr 22, 2022
@Rob--W
Copy link
Member

Rob--W commented Apr 22, 2022

Chrome has landed a patch that changed the default CSP to script-src 'self' 'wasm-unsafe-eval'; object-src 'self'; (https://bugs.chromium.org/p/chromium/issues/detail?id=1173354#c60).

Firefox is about to support 'wasm-unsafe-eval' too, but will only include 'wasm-unsafe-eval' in MV2's default CSP, and removes it from the MV3 CSP.

I have filed two follow-up bugs to work towards the resolution of the differences:

P.S. As noted in the Chromium report, there is not that much point in requiring object-src, because plugin support has been dropped from browsers. We may as well remove object-src from the default CSP to clean up the platform.

@rdcronin
Copy link
Contributor

Hi folks!

We're looking into this (Extension CSP) on the Chrome side to address a number of outstanding issues we have. I'd like to see if we can align with other browser vendors where possible.

I've written up a doc with a proposal here:
https://docs.google.com/document/d/1m82BcCPWDTEzy1R6gbCbUwe-ma-bCTTF_JwRnt3O_IA/edit#heading=h.uvfu5unrnahu

(World-viewable, feel free to request comment access.)

Please let us know what you think.

@carlosjeurissen
Copy link
Contributor Author

carlosjeurissen commented Oct 21, 2022

@rdcronin Thanks so much! Good to see this! Can you grant comment access? (As far as I know requesting comment access directly in Google Docs is not possible at this moment)

@rdcronin
Copy link
Contributor

We've had issues in the past with various spam when opening up comments to anyone on the web with the link — for anyone who wants access, go ahead and request edit access and I'll grant comment access to the email address from the request.

(Separately, @dotproto , can we create a WECG Google Group so that we can easily share docs with that alias?)

@dotproto
Copy link
Member

@rdcronin, I started looking into this. I've created a Google Group, but I think I will need W3C assistance to populate and maintain the group's members. Reaching out now.

@rdcronin
Copy link
Contributor

I've seen (and responded to) Rob's comments on the doc; does anyone else have concerns with the proposed approach?

@hanguokai
Copy link
Member

The proposal document focus on script-src and object-src. I'm not very familiar with CSP. I would like to ask what are other CSP instructions, like font-src, img-src, style-src, frame-src, media-src?

PS: I see @dotproto created a google group and I am in it, but I don't see I have comment permission in that document.

@Rob--W
Copy link
Member

Rob--W commented Oct 28, 2022

The proposal document focus on script-src and object-src. I'm not very familiar with CSP. I would like to ask what are other CSP instructions, like font-src, img-src, style-src, frame-src, media-src?

I suppose that you are wondering why the document only mentions script-src and object-src? Does the documentation at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/content_security_policy help?

In case it wasn't clear: the browser uses CSP in extensions to restrict remote code execution. In MV1 there were no restrictions. In MV2 insecure scripts (http:) were blocked, and remote code from eval and https were allowed via an opt-in, to protect the extension against XSS. In MV3 all remote scripts are blocked, no exceptions, to protect the user from unverified code.

Other CSP directives (img-src etc) aren't set because these do not govern privileged script execution. In #303 there is a proposal to use the CSP to restrict insecure schemes (http:).

@hanguokai
Copy link
Member

Ok. So there aren't any other CSP restrictions other than remote script and (proposed) upgrade-insecure-requests.

@rdcronin
Copy link
Contributor

Ok. So there aren't any other CSP restrictions other than remote script and (proposed) upgrade-insecure-requests.

Mostly correct. The minimum CSP is what would enforce the CSP restrictions, and is proposed to be:

script-src 'self' 'wasm-unsafe-eval' http://localhost:* http://127.0.0.1:*; object-src 'self';

This restricts scripts to the extension origin and localhost, allows wasm to be used, and restricts object-src to self (though note the object-src restriction is mostly obsolete, as mentioned in issue 204).

The upgrade-insecure-requests change would not be a restriction, per se, but rather a default (which could then be overridden by the extension).

@rdcronin
Copy link
Contributor

rdcronin commented Nov 1, 2022

Hi folks!

I think the only outstanding question here is one that Rob raised in the doc about whether allowing localhost / 127.0.0.1 as a script source should only be allowed for unpacked extensions. Since the main purpose here is development, the idea is that this would be sufficient to allow folks to use these locally-hosted scripts during the development process, while avoiding opening up any security concerns for packed extensions. Our question is whether this would be sufficient for localhost use cases or if this would still break a number of important flows. Does anyone have concrete examples of issues that would arise if we only allow localhost for unpacked extensions?

@hanguokai
Copy link
Member

I agree with Rob, there is generally no need to load localhost scripts in extension pages. Could you scan localhost CSP in Web store extensions? (only browser vendors can do it)

@rdcronin
Copy link
Contributor

rdcronin commented Nov 9, 2022

We could scan it in the webstore, but if the propose in the comment above is reasonable, we can restrict it at the platform level, as well.

Since there haven't been any objects to this here, we'll proceed with that approach. We can relax it if necessary in the future.

@rdcronin
Copy link
Contributor

rdcronin commented Nov 9, 2022

@Rob--W , I'm going to tentatively move forward with the changes to sandboxed page CSP and allowing localhost in unpacked extensions, if there are no further concerns here.

@Rob--W
Copy link
Member

Rob--W commented Nov 9, 2022

@Rob--W , I'm going to tentatively move forward with the changes to sandboxed page CSP and allowing localhost in unpacked extensions, if there are no further concerns here.

Sounds good to me. The proposed minimum CSP (base CSP is the terminology used in Firefox) an default CSP look good. Other questions that I had are already noted in the document as follow-ups, so I see no blockers against proceeding as is.

One thing that I didn't mention before - the proposal currently lists object-src 'self' in the minimum CSP. I suppose that this is there to block the use of plugins in Chrome. Its presence prevents developers from using <object> and <embed> to load content, with the alternative being <iframe>. Do you intentionally want to block <embed> and <object>, or do you just want to block usage of plugins in extensions?

If you want to block plugins in extensions, then a platform-level way to block it independent of CSP can help with keeping the (minimum) CSP concise. I noted that in the last sentence at #204.

@carlosjeurissen
Copy link
Contributor Author

@rdcronin Thanks for writing up the document!

MV3 CSP DOC: Technically, we could remove all requirements (since the minimum CSP will take hold). The disadvantage to this is that developers would not see an error if they specify a CSP that will otherwise be ignored. Because of this, we propose leaving the enforcement for other directives.

As in between option we can consider a warning instead of an error. This would give more freedom in future changes regarding the minimum extension CSP and allows browsers and browser versions to differ with their minimum extension CSP.

MV3 CSP DOC: The minimum CSP applied by the browser can be confusing to extension developers, since it is not supplied by them but the error is a generic CSP error. It would be nice if we could differentiate errors from the minimum CSP and the extension-provided CSP.

This would be very welcome for the overall web platform itself. Being able to see which of the potentially many CSPs set triggered a certain CSP error is very helpful in debugging CSP issues.

aarongable pushed a commit to chromium/chromium that referenced this issue Dec 15, 2022
Allow remote sources in manifest V3 extension sandboxed pages. Add
browsertests for the same.

This is discussed in more detail at
w3c/webextensions#98.

Bug: 770271
Change-Id: Ibd0f24a2fda69bf8bfc1027c3ebe1e688afe2f20
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3969158
Reviewed-by: David Bertoni <[email protected]>
Commit-Queue: Devlin Cronin <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1083512}
@hanguokai
Copy link
Member

hanguokai commented Nov 11, 2023

(I'm preparing a slide about Extension MV3)

Edit: add Firefox's CSP

Let me summarize the current state.

By default, if there is no explicit declaration of CSP, it is:

"content_security_policy": {
    // Chrome
    "extension_pages": "script-src 'self'; object-src 'self';",
    // Firefox
    "extension_pages": "script-src 'self'; upgrade-insecure-requests;",
    "sandbox": "..."
}

The minimum CSP (maximum allowable CSP by developers) is:

"content_security_policy": {
    // Chrome
    "extension_pages": "script-src 'self' 'wasm-unsafe-eval' http://localhost:* http://127.0.0.1:*; object-src 'self';",
    // Firefox
    "extension_pages": "script-src 'self' 'wasm-unsafe-eval'; upgrade-insecure-requests;",
    "sandbox": "..."
}

wasm-unsafe-eval and localhost need to be added manually by developers. localhost is only be allowed for unpacked extensions.

@Rob--W
Copy link
Member

Rob--W commented Nov 12, 2023

In Firefox, MV3's default CSP is script-src 'self'; upgrade-insecure-requests; - see #303 for rationale.

In Firefox, localhost cannot be allowlisted. Chrome intentionally supports localhost in the CSP in unpacked extensions only.

Firefox doesn't restrict object-src since it does not support plugins. Chrome has object-src 'self' in the default and minimum CSP as explained in #204.

@Rob--W
Copy link
Member

Rob--W commented Nov 20, 2023

On Firefox's end, we decided that we are willing to support localhost/127.0.0.1 scripts in temporarily loaded MV3 extensions (was already supported in MV2). Follow https://bugzilla.mozilla.org/show_bug.cgi?id=1864284 for progress.

@hanguokai
Copy link
Member

@rdcronin Chrome has a worker-src bug, that I reported at https://crbug.com/1504703 . worker-src 'self' should prevent from using new Worker(a_blob_url). It works on Web pages, but doesn't work on extension pages at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
inconsistency Inconsistent behavior across browsers topic: csp Related to content security policy enforcement
Projects
None yet
Development

No branches or pull requests

7 participants