Open Bug 1786919 Opened 1 month ago Updated 2 days ago

prevent downgrade of security headers in webrequest mv3

Categories

(WebExtensions :: Request Handling, enhancement, P2)

enhancement

Tracking

(Not tracked)

People

(Reporter: mixedpuppy, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [addons-jira])

Attachments

(1 file)

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.

Blocks: 1787155

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.

(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).

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.

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.

You need to log in before you can comment on or make changes to this bug.