Proposal: assign a code signed "origin" URL to webextensions

[minfrin]

Right now, the window.postMessage() function is able to target code that was served at an explicit URL, where the security of that URL is enforced by the browser:

https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

Concrete example, an attempt to send a message as follows:

window.postMessage("The user is 'bob' and the password is 'secret'",
                  "https://secure.example.net");

Means that the recipient of this message will be code that was hosted at the TLS protected secure.example.net, and the browser has ensured that the code came from secure.example.net.

It is proposed that each webextension be given a URI, and the name in the URI be verified by the browser using the browser's chosen code signing mechanism.

Example:

window.postMessage("The user is 'bob' and the password is 'secret'",
                  "webextension://awesomefunctionality.example.net");

This will allow webextensions to be targeted securely by webpages and other webextensions.

[xeenon]

I would prefer we go with Chrome's externally connectible messaging API for this.

[minfrin]

Externally connectible seems to be solving the opposite problem to the problem described in this ticket.

What externally connectible appears to be about is the "server" side of the connection declaring who it will allow to connect.

What this ticket about is the "client" side of the connection receiving assurance that the message that was just sent is targeted at an explicit extension, and being sure you are connecting to the correct extension by backing things up with a code signing certificate.

This problem is identical to the problem that TLS solves for us - are we connecting to the "server" we want to connect to, or are we connecting to an imposter.

[jcblw]

In the externally connectable API, you need to explicitly input the extension id to send a message or connect to the extension. Does this not suffice for the "client" knowing it is connecting to the correct extension? Chrome, Edge, and I think Safari extensions, are signed in a way the ids should not be easily spoofable.

[minfrin]

Looking at the docs for externally connectable here:

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/externally_connectable#browser_compatibility

There is an "ids" element, which specifies "List of extension IDs that extension wishes to communicate with", and a "matches" element which specifies "Regular expression patterns specifying web pages".

Both of these are the target extension saying "I want...".

What I'm describing affects the source webpage that wants to talk to the target extension. I want for the source webpage to have a way to say "check that I am connecting to the correct target extension, that has been code-signed". What the target wants isn't important in terms of this capability.

[Rob--W]

What I'm describing affects the source webpage that wants to talk to the target extension. I want for the source webpage to have a way to say "check that I am connecting to the correct target extension, that has been code-signed". What the target wants isn't important in terms of this capability.

You are asking for something that cannot be guaranteed. Even externally_connectable does not offer this guarantee, and this is also why I am not in favor of implementing it in Firefox. For discussion including security considerations, see the thread at https://bugzilla.mozilla.org/show_bug.cgi?id=1319168#c19

I would prefer we go with Chrome's externally connectible messaging API for this.

What value do you see in externally_connectable? When any content script is allowed to run in a web page, there is no added security benefit.

There is a scenario where the APIs could be useful, when the extension is not allowed to run scripts in the web page, e.g. by browser's choice (e.g. the Chrome Web Store or addons.mozilla.org) or enterprise policies. In that case, the externally_connectable API would offer a way for the web page to communicate with the extension. In this kind of scenario, the web page would consider itself to be more trusted than the extension, which is quite unusual.

[minfrin]

You are asking for something that cannot be guaranteed.

Can you give more detail as to why this cannot be guaranteed? The purpose of TLS is to ensure that you are connecting to who you think you are connecting to. I want the same level of assurance that I am talking to a legitimate extension as I do to talk to a legitimate website.

[Rob--W]

You are asking for something that cannot be guaranteed.

Can you give more detail as to why this cannot be guaranteed? The purpose of TLS is to ensure that you are connecting to who you think you are connecting to. I want the same level of assurance that I am talking to a legitimate extension as I do to talk to a legitimate website.

TLS ensures that two independent endpoints can talk to each other over a secure channel.

An extension and a web page are not independent. An extension can run scripts in the web page, and because of that a web page cannot rely on any built-in APIs. A third party non-legitimate extension can try to modify the web page and its execution environment (and even the resources that it loads) to bypass any checks that the web page hopes to perform.

In your TLS analogy: an API like you're asking for would be similar to the use of TLS with weak ciphers. Knowledgeable people will immediately recognize the setup as insecure. Other people would rely on the belief that "TLS is secure", and build stuff on top of an unreliable foundation.

As long as arbitrary extensions are able to modify the web page, the author behind the web page cannot distinguish legitimate and non-legitimate extensions. Enterprise policies can be used to lock down behavior, but there would not be a general ability for web pages to block extensions, as that could easily be abused by malicious websites to block add-ons that are meant to protect users.

[minfrin]

An extension and a web page are not independent

This is at the core of the problem. Despite all the attempts to put native apps in their own sandbox and separate from each other, the native apps are forced to share data with each other, and are forced to have root access to webpages, and thus undoing all the benefits.

In your TLS analogy: an API like you're asking for would be similar to the use of TLS with weak ciphers. Knowledgeable people will immediately recognize the setup as insecure

You need to expand on this - what specifically will knowledge people recognise as insecure, and how is this comparable to a weak cipher?

Other people would rely on the belief that "TLS is secure", and build stuff on top of an unreliable foundation.

Unreliable foundations in webextensions have long been established, thus this standardisation effort:

https://duo.com/labs/tech-notes/message-passing-and-security-considerations-in-chrome-extensions
https://owasp.org/www-chapter-london/assets/slides/OWASPLondon_PostMessage_Security_in_Chrome_Extensions.pdf
https://insight.claranet.co.uk/technical-blogs/hunting-postmessage-vulnerabilities
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

As long as arbitrary extensions are able to modify the web page

(Via the content scripts) - exactly - this is the core of the problem.

I have raised #94 to pin down this issue.

[rektide]

Making extensions addressable would be such an amazingly powerful way to make them a better part of the web. This would be such an incredible & common-sense way to evolve things towards what the web really truthfully honestly is: a system of resources. Making things declarative- giving them names & addresses- is obviously much better / much more "web" than a long elaborate system of APIs.

This idea would add much sense & clarity & it was like a bright light going off on my head to run across this commonsense & yet brilliant idea.

This issue makes a host of web security concerns basically irrelevant while inventing nearly nothing. #57 for example is a nest of concerns we can outright disregard if we did this.