TL;DR: It may not be in your threat model, but browser extensions may present a significant threat depending on the business. Currently, the security responsibilities and capabilities are mostly in the browser’s extension store. In order to be able to manage this risk, IT and security professionals have to use scanners with parsers for each browser extension model. However, A standard extension management API could improve the ecosystem.



Historical Context of the Browser Ecosystem

The browser wars, a term that evokes nostalgia for many in the tech industry, were not just a battle for market share but also a struggle for technological supremacy. In the late ’90s, Netscape Navigator and Internet Explorer were the titans, each vying for dominance by introducing proprietary HTML tags and JavaScript features. This led to a fragmented web, where developers had to create multiple versions of websites to ensure cross-browser compatibility. As the years passed, the browser landscape evolved, but the issues stemming from the lack of standardization persisted. Take Microsoft’s Internet Explorer, for example, which employed ActiveX controls. These controls were proprietary to IE, creating a walled garden that other browsers couldn’t penetrate. This not only complicated web development but also posed significant security risks, as ActiveX was notorious for being a vector for malware. Then came the era of multimedia technologies like Adobe’s Flash (the first programming environment I have worked writing ActionScript 2.0, oh memories!) and Microsoft’s Silverlight. While they offered rich experiences, they were not based on open standards. The industry eventually moved towards HTML5, but not before countless security vulnerabilities were exploited. The fragmentation didn’t stop at multimedia. Even something as fundamental as CSS saw the introduction of vendor-specific prefixes like -webkit- for Chrome and Safari, and -moz- for Firefox. These prefixes enabled browser-specific features, but at the cost of complicating the developer experience. JavaScript, the lifeblood of modern web applications, wasn’t immune to these challenges either. Its standardization as ECMAScript was fraught with difficulties due to varying implementations across browsers like IE, Firefox, and Chrome. And let’s not forget the inconsistencies in DRM systems and video codecs. Firefox, for instance, initially resisted implementing DRM but eventually had to yield to market pressures. Similarly, technologies aimed at enhancing real-time communication, such as WebRTC and WebSockets, faced slow adoption and inconsistent implementation across browsers. Even the well-intentioned “Do Not Track” privacy standard failed to gain uniform adoption, leaving users with inconsistent privacy experiences across the web. Newer protocols like HTTP/2 and QUIC are making strides in performance but still suffer from varying levels of support among vendors.

The reason I started with the historical context it to mention the lack of standardization and the causes of it. The history of the browser ecosystem teaches us about the delicate balance between innovation and standardization, and the unintended consequences that can arise when that balance is upset. The competitive drive for new features has sometimes overshadowed the need for security and interoperability, leading to a fragmented landscape that complicates cybersecurity efforts.

Security Implications of Browser Extensions

Do you remember NPAPI? The Netscape Plugin Application Programming Interface (NPAPI) was one of the earliest technologies designed to extend browser functionality. Introduced by Netscape in 1995, NPAPI allowed third-party developers to create plugins that could be embedded within web pages and interact with the browser. This was a significant step in the evolution of web browsers, as it opened the door for rich multimedia content and interactive features. The ActiveX -a fancy name for COM objects accessible from browser utilizing NPAPI- came later, deeply coupled with two Microsoft products: Windows and Internet Explorer. As you can infer, the browser sandbox was not a thing. However, like ActiveX controls that came later, NPAPI plugins also had their share of security concerns. Over time, modern web technologies like HTML5 and JavaScript have largely replaced the need for such plugins, and many browsers have phased out support for NPAPI due to security risks (I will drop the PPAPI as another abbreviation for a shorter story here if a reader would like to fancy reading).

But that was not the end. Because addons, extensions or plugins, however you name it, are here to exist. Browsers are improving themselves as a new layer of virtualization through the sandboxes. Yet, isolation between the the applications in the sandbox and the operation system does not apply to these extensions. Depending on the permissions, the extensions can access and modify resources in and/or out of the sandbox. Just like any package manager, the security responsibility relies on the repository providing the distribution environment, such as Chrome Web Store or Addons.mozilla.org (AMO).

Recent studies, such as the one conducted by Spin.AI, have illuminated the security risks associated with browser extensions. The study, which analyzed approximately 300,000 extensions, found that 51% were categorized as high-risk, capable of capturing sensitive data and executing malicious JavaScript. Furthermore, a significant number of these extensions were authored anonymously, exacerbating the risk profile. These findings are corroborated by specific incidents, such as the malicious ChatGPT extension that compromised thousands of Facebook accounts.

What can we do?

At present, organizations employ various methods for managing browser extensions, often relying on group policies or vendor-specific solutions. While these approaches offer some control, they are inherently limited by their lack of standardization and are not universally applicable across different browsers and platforms. Given the aforementioned security landscape, there is a compelling case for the development of a standardized API for browser extension management. Such an API would facilitate a unified interaction model, enabling Configuration Management Databases (CMDB), Endpoint Management, Mobile Device Management (MDM), and Endpoint Detection and Response (EDR) systems to interface with browsers in a vendor-agnostic manner. Importantly, this API should extend beyond mere inventory querying by giving way to different integration methods, as primitively demonstrated by this proof of concept application which makes use of CRXcavator by DUO security. You can find similar applications such as neto and ExtAnalysis focusing only on this aspect while many security and IT asset management software implements the same feature. Think of the wasted manhours tying to replicate the same simple task all around the world! By saving these hours, A standard API should encompass a comprehensive set of management functionalities, akin to package managers like apt or yum, but with additional security-focused features.

It’s worth noting that not all organizations share the same threat model; thus, the absence of a standardized API may not constitute a significant risk for many. However, the proposal aims to elevate the security maturity of the broader ecosystem and could be integral to the threat models of numerous organizations.

The history of browser development has been characterized by a tension between innovation and standardization, often at the expense of security. As browser extensions become increasingly integral to user experience and productivity, their potential as attack vectors grows correspondingly. A standardized API for managing browser extensions would not only streamline administrative workflows but also fortify the security posture of organizations. While the endeavor is challenging, given the historical context, it is a necessary step towards a more secure and manageable browser ecosystem.


<
Previous Post
Back to Basics 1: The Microsoft Leak and the Ironies of Automation
>
Next Post
Responsibility v. Authority: the Good, the Bad and the Ugly