Brave-browser: Greaselion should provide an API for validating that message is from Greaselion

Created on 26 Aug 2020  路  8Comments  路  Source: brave/brave-browser

This issue came up during a security review for https://github.com/brave/brave-core/pull/5440.

Greaselion content scripts are currently downloaded on-the-fly and given a dynamically-generated extension ID when installed locally. The problem with this approach is that other extensions could send messages to Brave and the browser would have no way to authenticate that they were sent by Greaselion extensions.

One idea I can think of is to enhance the Greaselion.json file to support an id key, allowing content script creators to specify a static extension ID for Greaselion to use. The Greaselion service could then insert this id into the manifest when generating the given extension.

ODesktop QNo greaselion release-noteexclude security

Most helpful comment

So it seems like we _may_ be able to get any APIs we want to run in content scripts instead of only background scripts by adding the content_script context to the relevant _api_features.json file, e.g. https://source.chromium.org/chromium/chromium/src/+/master:extensions/common/api/_api_features.json;l=517?q=_api_features.json.

However, I have to think there's a reason chrome doesn't do this, instead confining _all_ browser APIs to the background process and only allowing message passing from the _page content script thread_. Given that, I have performance and security concerns around allowing our APIs from the content script (I assume it's on the page process?), and would love it if someone more expert (@diracdeltas, @bridiver ?) could weigh in on that.

@petemill that would be an extremely bad idea and even if you added it to api_features, I'm pretty sure it still wouldn't work correctly. The APIs that content scripts can access are intentionally limited for security reasons

All 8 comments

cc: @pilgrim-brave @diracdeltas @NejcZdovc

Every greaselion script I've prototyped and spec'ed so far needs communication to the brave extension with which to call some APIs, since we don't have background script support in greaselion and therefore can only call another extension's background script.

Since the greaselion component and therefore Brave knows which extensions are greaselion extensions at runtime, the brave extension external message handler can check to see if the calling message is from a greaselion extension. Something like:

chrome.greaselion.isGreaselionExtension(extensionId)

This would be a pretty simple addition.

Other alternative I can think of is to have a dedicated communication channel only allowed from internal component extensions, e.g. chrome.greaselion.sendMessageToBraveExtension(...) and the corresponding chrome.runtime.onMessageFromGreaselion(...) handler.

@diracdeltas Do you think @petemill's suggestion above would meet our security needs? It seems like it would be the most expedient approach for us in the near-term.

That sounds fine as long as all greaselion scripts are maintained by us.

So it seems like we _may_ be able to get any APIs we want to run in content scripts instead of only background scripts by adding the content_script context to the relevant _api_features.json file, e.g. https://source.chromium.org/chromium/chromium/src/+/master:extensions/common/api/_api_features.json;l=517?q=_api_features.json.

However, I have to think there's a reason chrome doesn't do this, instead confining _all_ browser APIs to the background process and only allowing message passing from the _page content script thread_. Given that, I have performance and security concerns around allowing our APIs from the content script (I assume it's on the page process?), and would love it if someone more expert (@diracdeltas, @bridiver ?) could weigh in on that.

So it seems like we _may_ be able to get any APIs we want to run in content scripts instead of only background scripts by adding the content_script context to the relevant _api_features.json file, e.g. https://source.chromium.org/chromium/chromium/src/+/master:extensions/common/api/_api_features.json;l=517?q=_api_features.json.

However, I have to think there's a reason chrome doesn't do this, instead confining _all_ browser APIs to the background process and only allowing message passing from the _page content script thread_. Given that, I have performance and security concerns around allowing our APIs from the content script (I assume it's on the page process?), and would love it if someone more expert (@diracdeltas, @bridiver ?) could weigh in on that.

@petemill that would be an extremely bad idea and even if you added it to api_features, I'm pretty sure it still wouldn't work correctly. The APIs that content scripts can access are intentionally limited for security reasons

chrome.runtime.sendMessage allows an extension ID and that is how greaselion content scripts can communicate with rewards background page, for example.

Great thanks for the closure that I was hoping for! So we're back at moving forward with a message source check in the lines of

chrome.greaselion.isGreaselionExtension(extensionId)

...and/or move forward with background script support for greaselion (only if lazy and infrequently accessed, i.e. only on user action!)

Was this page helpful?
0 / 5 - 0 ratings