14 DAY TRIAL // Browser extensions and add-ons are great for extending functionality and customizing the experience to enable users to get the most out of their browsers. Firefox solidified and popularized the concept, leading to all browsers offering some way of extending functionality.
But the flip side of this is that it opens up core parts of the browser and even the system to third-party developers and that it also creates potential vulnerable points in a browser since many add-ons take fewer security precautions than the browsers themselves and add-on developers may be less experienced with these issues as well.
The solution to this is to design the add-on platform in such a way as to remove or limit the danger of exposing powerful functionality to web pages via add-ons.
Mozilla is showcasing some of the things it's done with the Add-on SDK, formerly known as Jetpack, its web technology-based add-on platform to ensure that add-ons aren't a weak point.
The most important thing it's done is to isolate the different layers of functionality and content. The idea is to make it as hard as possible for web content, which is by definition untrusted and could be malicious, to access the browser or the user's system underneath.
"Firefox add-ons have powerful capabilities, including the ability to read and write the user’s file system, access the network, and access stored passwords," Mozilla wrote.
"At the same time they interact directly with untrusted web content (that is, arbitrary web pages, and the scripts they load). If add-ons aren’t carefully designed, malicious web sites can exploit their vulnerabilities to access these capabilities," it added before continuing to detail the measures taken to achieve this.
The explanation falls squarely on the technical side, which may be of interest to developers but not of much use to regular users.
The add-on platform is designed to keep the different layers separated. Web content can't directly interact with the add-ons, rather a "content proxy" is used to serve web content to the add-ons, specifically to the content scripts.
Further down the pipe, a mechanism, the postMessage() method, is used to facilitate communications between content scripts and core add-on scripts inside the add-on itself.
A final defence mechanism is that add-ons have to declare in advance, via require(), what APIs they need to use. This way, if malicious code from a website manages to take over an add-on, it will still only be able to do and access what the add-on could in the first place. You can check out Mozilla's post for more details and code examples.