1786919 - prevent downgrade of security headers in webrequest mv3

Status: RESOLVED FIXED

(WebExtensions :: Request Handling, enhancement, P2)

Description

[Shane Caraveo (:mixedpuppy)]

Our MV3 approach is to disallow security downgrades.

Allow changes to increase security
XFO (= X-Frame-Options, comparable to CSP frame-ancestors)
COOP
CORP
COEP

Disallow any changes:
CORS: Access-Control-Allow-* response headers, Origin request header.

Comment 1

[Shane Caraveo (:mixedpuppy)]

Attachment: Bug 1786919 restrict the types of header changes webrequest can make

Comment 2

[dessant]

Disallowing the modification of Access-Control-Allow-* response headers will impact extensions that need to download page content.

Search by Image sets CORS headers for some images in order to download them from the content script before uploading to a search engine. In many cases an asset will only be served if the request contains the correct origin, referrer and cookies. Reproducing such a fetch request was impossible from a background page last time I tested, and even if configuring all aspects of a request becomes possible, it could still open up extensions to security issues, because it's difficult to figure out if certain data types would be sent by the browser if the request would be made from the page context, such as the referrer. We would also need to request additional permissions, such as access to HTTP cookies.

Extensions used for archiving pages would no longer be able to create faithful representations of the tab content. Advanced ad blockers such as uBlock Origin would be impacted as well. There is a general issue of extensions not being able to access certain parts of the page, such as a tainted canvas in Chrome, or a closed shadow DOM in Safari, and this restriction would make the problem worse.

Comment 3

[Rob Wu [:robwu]]

(In reply to dessant from comment #2)

Disallowing the modification of Access-Control-Allow-* response headers will impact extensions that need to download page content.

We'd like to disallow by default, to increase the security baseline of add-ons. Currently, any add-on with the webRequestBlocking permission can potentially downgrade security headers, even though most add-ons don't need such functionality. We want to restrict first, and consider the reintroduction of the functionality in a follow-up - bug 1787155.

Search by Image sets CORS headers for some images in order to download them from the content script before uploading to a search engine. In many cases an asset will only be served if the request contains the correct origin, referrer and cookies. Reproducing such a fetch request was impossible from a background page last time I tested, and even if configuring all aspects of a request becomes possible, it could still open up extensions to security issues, because it's difficult to figure out if certain data types would be sent by the browser if the request would be made from the page context, such as the referrer. We would also need to request additional permissions, such as access to HTTP cookies.

We'd prefer to offer a dedicated API to fetch data with the right request context. Bug 1670278 tracks the development of that feature (it mentions cookieStoreId, but the intent is for the method to be more generic and a viable replacement for fetch from a MV2 content script).

Comment 4

[Shane Caraveo (:mixedpuppy)]

To add a note from my perspective, this restriction will only affect MV3 addons. MV2 addons still have a life span long enough for us to gather and address use cases [in mv3] as described in comment 2. While we are not making a decision about how that will be addressed right now, one possible path is that it is just a new permission.

Comment 5

[sdaniele3]

CSP Stuff I don't really care about except reporting (which is still not fixed Bug 1588957). I do care about Origin / Referrer. There are times when I need to spoof them to get a server to respond properly.

Comment 6

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

Attachment: Bug 1786919 - Disallow to MV3 webRequest listener changes to existing security headers. r?mixedpuppy!

Comment 7

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

Attachment: Bug 1786919 - Disallow to MV3 webRequest listeners to bypass CORS checks on data: redirectUrl. r?mixedpuppy!

Depends on D161052

Comment 8

[Phabricator Automation]

Comment on attachment 9301618 [details]
Bug 1786919 - Disallow to MV3 webRequest listeners to bypass CORS checks on data: redirectUrl. r?mixedpuppy!

Revision D161070 was moved to bug 1798954. Setting attachment 9301618 [details] to obsolete.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bc31c04ba1b7
Disallow to MV3 webRequest listener changes to existing security headers. r=mixedpuppy

Comment 10

[dessant]

Would it be possible to postpone merging this until there is a viable alternative for making CORS requests from the context of a page? Introducing this limitation in MV3 without offering an alternative would prevent us from porting some of our extensions when MV3 lands in the release version of Firefox early next year, and we wouldn't be able to support Firefox ESR 115 if the alternative is not ready in time.

Comment 11

[Rob Wu [:robwu]]

The patch is already landing.

If you have a specific use case in mind that needs API support, please create a new feature request with the relevant details that blocks bug 1787155.

Comment 12

[dessant]

It must be possible to prevent a patch from being released in the stable version of Firefox. You must be aware that this change will make it difficult to port extensions that need to access arbitrary page content. Extension developers have enough work on their hands already, and we shouldn't need to spend more time submitting feature requests and then defending use cases that are already obvious to your team.

Comment 13

[Atila Butkovits]

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