Below we would like to list considerations about web extension security that we consider important while implementing end-to-end email encryption comparing with traditional web applications.
Delivery model. Authenticity.
Web extension delivery is controlled by the end-user who can:
- Install web extension from the store (Chrome web store, Firefox Add-ons, ...) delegating the store owner checking authenticity, security, privacy policy.
- Install web extension manually verifying its authenticity and security using corresponding scanners and utilities
- Get web extension as preinstalled with the corporate version of the browser.
NOTE that in a web application case, the user doesn’t have control over the webserver that is providing the web application, any web service provider can potentially provide a malicious version that could compromise the encryption.
It's valid for webmail encryption services like ProtonMail, Tutanota, ...
Fine-grained permissions
Web extensions have a permissions model to give users fine-grained control over what information and resources could be accessed by any extensions they install.
Each extension comes packaged with a list of permissions, which govern access to the browser APIs and web domains. If an extension has a core vulnerability, the attacker will only gain access to the permissions the vulnerable extension already has.
Privilege separation
Extensions are built from two types of components, which are isolated from each other - content scripts and extension cores. Content scripts interact with websites and execute with no privileges. Extension cores do not directly interact with websites and execute with the extension's full privileges.
Process Isolation
"Each component of the extension runs in a different process. The extension core and the native binary each receive dedicated processes. Content scripts run in the same process as their associated web pages.
This process isolation has two benefits: it defends against browser errors and low-level exploits.
Process isolation helps protect the extension core from browser implementation errors, such as cross-origin JavaScript capability leaks because JavaScript objects cannot leak from one process to
another.
another.
Process isolation also defends against low-level exploits in the browser. For example, if a malicious web site operator manages to corrupt the renderer process (e.g., via a buffer overflow), the attacker will not be granted access to the extension APIs because the extension core resides in another process."
Web extension isolated world
Important to note that the extension's content script runs in an isolated world. "Isolated worlds do not allow for content scripts, the extension, and the web page to access any variables or functions created by the others. This also gives content scripts the ability to enable functionality that should not be accessible to the web page" [2]
Moreover, the extension's content script is completely cut off from the background script (an invisible page that holds the main logic of the extension) and can communicate with it only via Chrome messages https://developer.chrome.com/extensions/messaging. So that message content can be validated and sanitized in a favor of security.
Vulnerability analysis
Web extensions have more privileges thus vulnerabilities in browser extensions put users at risk by providing a way for website and network attackers to gain access to users' private data and credentials.
Following researches like An Evaluation of the Google Chrome Extension Security Architecture browser vendors improve web extensions platform security regularly at the same time making extension developers publish and follow strict data privacy policies.
