CRXcavator – Chrome Extension Security Policy
CRXcavator scans the entire Chrome Web Store, making it easier for enterprise security teams to evaluate extensions before allowing them to be downloaded and used. Duo is a proud Chrome Enterprise partner helping bridge this gap by providing this tool to our customers.
Extensions may have low, medium, or high alert risk levels. You can learn more about permission risk levels here.
Security Policy
Browser extensions add a lot of functionality to the Chrome platform, and often have access to sensitive user data. This can create a variety of security threats, such as man-in-the-middle attacks. To mitigate these threats, the Chrome Web Store requires developers of extensions to certify their privacy practices and data use. Chromium also provides mitigations through default content policy settings for extensions.
These security controls are intended to ensure that extensions have the least amount of access to user data possible to function. However, despite the best efforts of developers, vulnerabilities can occur, leaving data at risk. A recent vulnerability in popular extension CCleaner illustrates this point. To mitigate these vulnerabilities, organizations should deploy a centralized management system for chrome extensions such as Google’s Browser Cloud Management (CBCM). CBCM allows IT administrators to review the functionality of an extension, and prevent it from running on a managed device. It also provides visibility into extension usage within an organization.
Authentication Policy
Authentication policies are part of the chrome extensions manifest, and are intended to control the scope and behavior of authentication scripts in an extension. This allows developers to write extensions that prevent users from entering credentials into web sites (a type of phishing attack) or protect against cross-site scripting attacks.
However, these policies are not foolproof. It is possible for an extension to bypass the Authentication Policy, for example by injecting a content script that executes in the main world. This is not a bug in Chromium, but rather a flaw in the extension code itself.
Despite this, it is still important to consider the authenticity of an extension. This can be done by reviewing the extension’s manifest and checking for vulnerabilities. Alternatively, using a tool like FuzzAPI can help you automatically test an extension’s API endpoints for vulnerabilities. Also, if you’re testing an unpacked extension, be sure to disable chrome://extensions in the developer console to ensure that the extension is not being loaded from another source.
Access Control Policy
Since extensions are more privileged than the web pages they run on, they can sometimes bypass restrictions put in place by those pages. This access is usually critical to extension functionality.
If an extension modifies data or injects script into a page, the modification persists after the extension is uninstalled. This can include modifying security-sensitive headers like Content-Security-Policy and HTTP Strict-Transport-Security. It can also include mutating cache, installing service workers on sites, and changing proxy settings.
Some extensions need access to chrome-untrusted:-scheme pages (such as chrome://settings). This is a fundamental part of the function of many password managers, for example. However, it is very easy for attackers to hide malicious code in these pages. IT security teams need ways to detect and investigate these attacks when they occur.
Content Policy
For extensions that need to access sensitive user data (like password managers), users should be able to see the permissions requested by the extension during installation and can choose not to install the extension if they’re uncomfortable with the request.
An extension’s content scripts run in a separate isolated JS world, which should make it harder for attackers to cross from the main browser into the extension world and steal data or execute XSS attacks. However, some variable names are shared between the isolated and main worlds, allowing attackers to use a shared value as a path into the extension’s world.
This policy allows developers to relax the default Content Security Policy for their extensions, if necessary for functionality reasons. For example, if an extension uses a backend that runs in an untrusted domain, you can add the ‘unsafe-eval’ rule to allow the extension to evaluate strings as executable code.
