Browser extension security system

Presented herein are techniques for automatically generating information about risks associated with browser extensions used by browsers in an enterprise network for purposes of determining whether to whitelist a browser extension in response to a request from a user. A request to install a browser extension is obtained from a user device of a plurality of user devices associated with an organization, wherein the request comprises an extension identifier for the browser extension. A risk score is generated for the browser extension based on risk values for each of one or more permissions requested by the browser extension. The risk score is compared to a threshold value to determine whether the browser extension satisfies risk standards of the organization, and if so, the browser extension is automatically added to a whitelist of permitted extensions for future installation on the plurality of user devices.

TECHNICAL FIELD

The present disclosure relates to network security, and more particularly to security of web browsers.

BACKGROUND

In enterprise networks, network administrators are charged with the task of ensuring the security of user's web browsers. In larger enterprises, this can be cumbersome because numerous users may desire to install a wide range of web browser extensions for various functions that those users may need to perform. However, enabling end-users permission to install web browser extensions without oversight can potentially expose a network to security risks. While network administrators may review user requests to install extensions, the review process may be time-consuming.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

In one embodiment, a computer-implemented method automatically generates information about risks associated with browser extensions used by web browsers in an enterprise network for purposes of determining whether to whitelist a browser extension in response to a request from a user. A request to install a browser extension is obtained from a user device of a plurality of user devices associated with an organization, wherein the request comprises an extension identifier and a business justification for the browser extension. A risk score is generated for the browser extension based on risk values for each of one or more permissions requested by the browser extension. The risk score is compared to a threshold value for the organization to determine whether the browser extension satisfies risk standards of the organization, and if so, the browser extension is automatically whitelisted for future installation on the plurality of user devices.

Example Embodiments

The present disclosure relates to automatically generating information about risks associated with browser extensions used by browsers in an enterprise network for purposes of determining whether to whitelist a browser extension in response to a request from a user. Conventional approaches to whitelisting may leave end users with no clear path to request access to extensions not already explicitly allowed, and may require manual review from a network administrator before each extension can added to the list of allowed extensions in the enterprise network. This makes the process for allowing a new application slow and expensive.

In contrast, presented embodiments automate the process of reviewing browser extensions to determine whether an extension may be included in an organization's whitelist of approved extensions. These techniques employ a special-purpose browser extension that is configured to gather information about browser extensions installed in a browser, a specialized process to generate a risk score associated with browser extensions, and a process to continuously scan a browser store to determine when updates are released to browser extensions.

In particular, the special-purpose browser extension, referred to as a gatherer extension, detects when a user has navigated to a browser extension store, such as the Chrome™ Web Store, and obtains a browser extension identifier. The gatherer extension then compares the extension identifier to a whitelist of the organization to determine whether the corresponding browser extension has been approved for installation, and if so, the user may install the browser extension on the user's device. However, if the extension identifier is not included on the organization's whitelist, the gatherer extension may prompt the user to see if the user would like to submit the extension for approval to be whitelisted.

When a request is made to whitelist an extension, present embodiments validate the extension by evaluating a risk assessment report for the extension against the risk standards of the organization. The risk assessment report may include a risk score that is generated for the extension based on risk values for permissions requested by the extension. If the extension is found to meet the organization's risk standards, then the extension may be added to the organization's whitelist so that the extension may be installed onto devices of the organization, including the device of the user who requested review of the extension. Present embodiments thus provide the ability to automatically whitelist web extensions for an organization, thereby providing security to a network without requiring manual intervention by an administrator, which can be time-consuming and costly. Moreover, present embodiments provide feedback to network administrators regarding the requested extensions, enabling administrators to obtain a better understanding of the risks imposed by extensions in the event that manual whitelisting decisions are necessary.

Referring first toFIG. 1, a block diagram is shown of a system100that includes an enterprise network110, a browser extension risk assessment server120, and a browser store service (server)130that distributes a plurality of browser extensions maintained in browser extension database140.

The enterprise network110is in communication with the Internet150to which the browser extension risk assessment server120and browser store server130have connectivity. The enterprise network110includes a plurality of user devices160(1)-160(K), a network administrator station170, a plurality of network devices (such as switches)180(1)-180(M) and one or more firewalls190.

Each user device160(i) includes a web browser162with a gatherer extension164and optionally, one or more installed extensions166(1)-166(N). Each user device160(i) may have a different selection of and number of extensions installed.

The browser extension risk assessment server120runs in the cloud, for example, as a Software-as-a-Service (SaaS) function to assess the risks associated with one or more browser extensions166(1)-166(N) in use on a user device in the enterprise network110. The browser extension risk assessment server120may include a whitelist121that stores a list of approved extensions. It should be understood that the browser extension risk assessment server120could reside within the enterprise network110.

As explained in more detail hereinafter, the gatherer extension164works in concert with the browser extension risk assessment server120to enable automated risk assessment and other operations. The gatherer extension164operates to report to the browser extension risk assessment server120information about browser extensions installed on the browser162of an associated user device160(i).

The browser extension risk assessment server120may perform browser risk assessment services for numerous enterprise networks (e.g., Enterprise A, Enterprise B, and so on), each with its own set of security policies that are configured on the browser extension risk assessment server120.

Reference now made toFIG. 2that illustrates an operational flow for an automatic browser extension explicit allow request process200. The process200involves force-installing the gatherer browser extension164to any users in the organization who would like this feature enabled. This gatherer extension164watches for when a user navigates to a Uniform Resource Locator (URL) that looks like it is pointing to browser store140. For example, in the case where the browser is a Chrome™ browser, then the URL may look like: http://chrome.google.com/webstore/detail/grammarly-for-chrome/kbfnbcaeplbcioakkpcpgfkobkghihen. Due to the fact that Chrome™ browser extensions are not able to use permissions or run content scripts on the Chrome™ Web Store, the gatherer extension164monitors the URL to detect when the user may be attempting to add an extension. The gatherer extension164may monitor URLs in an address bar, in a browser history or other log, or in any other location in which URLs may be found. The techniques presented herein are applicable to other types of web browsers, and Chrome™ is only one example.

When the gatherer extension164detects that the user is about to install a browser extension (shown at166(1)-166(N) inFIG. 2), the gatherer extension164obtains the extension identifier (ID) from the URL and at210submits it to an Application Programming Interface (API) to the browser extension risk assessment server120that checks if the extension is whitelisted for the organization's user base. If the extension is not whitelisted, the gatherer extension162will display a message to the user asking if they would like to request the extension be whitelisted in their domain. If the user clicks yes, they are taken to a form that shows information about the requested extension and a text box asking for the business justification for the extension to be whitelisted. Once they hit submit, at220, this extension request is submitted to browser extension risk assessment server120. When the request is submitted to browser extension risk assessment server120, a webhook is sent to a configured location. A webhook (also called a web callback or Hypertext Transfer Protocol (HTTP) push API) is a way for an application to provide other applications with real-time information. A webhook delivers data to other applications as it happens. This webhook contains details about the recent extension request. These details can include the extension ID, the business justification provided by the user, the identity of the user that is requesting the extension, and the status of the request. This webhook will trigger a function (such as an Amazon Web Services™ (AWS) Lambda serverless function) that will validate that the request came from the browser extension risk assessment server120, pull the latest risk assessment report from browser extension risk assessment server120, evaluate the risk report against the organization's risk standards (no blacklisted permissions, defined Content Security Policy, etc.), and at230notify a network/security administrator240that the extension is ready to be whitelisted and/or may automatically whitelist the extension. A whitelisted extension may be added to whitelist121. If the extension report is found to be too risky to allow an automatic whitelist, the Lambda function will notify an administrator of this and flag it for manual review.

Administrators can also view a list of the requested extensions in the browser extension risk assessment server120. Administrators are able to search by extension ID, the user that requested the extension, the business justification, and more. From this table, administrators can also view a link to the browser extension risk assessment server scan report where they can gain a better understanding of the risk imposed by the extension before making their whitelisting decision.

In one variation to the process200, an automatic and closed-loop process may be provided whereby, depending on a risk factor/score associated with the extension requested to be whitelisted, the browser extension risk assessment server120may return a message to the gatherer extension164that automatically permits (whitelists) the extension to be installed on a user's browser162, bypassing any security administrator review.

Reference is made toFIG. 3.FIG. 3illustrates an example user interface300, presented to a network/security administrator, which lists various extensions that have been requested for whitelisting in an enterprise. For each extension, there is an icon field302to show an icon representative of the extension, a name field304that includes the name of the extension, an extension ID field306that includes the extension ID, a user name field308that includes the name of the user who has requested that extension to be whitelisted, a business justification field310that contains a text explaining the business justification submitted by the user for that extension request, a status field312, and a timestamp field314indicating when the request was received by the browser extension risk assessment server120. The status field312has a drop-down menu for each entry that allows the administrator shows a status of Requested (pending review), Permit, and Deny the request. There may be other types of status tracked in the status field312.

In summary,FIGS. 2 and 3illustrate a process in which a detection is made for when a browser extension is installed on end users' browsers and in order to determine when a user is trying to install an extension that is not whitelisted. The browser extension risk assessment server120asks the user if they would like to whitelist an extension, and if so, prompts the user to provide a business justification for the request. The requested extension goes through an automatic security assessment and may be whitelisted based on the results of the assessment.

Collecting browser extension usage statistics is useful for organizations or enterprises for purposes ranging from general network security to incident response. Current options for gathering this data do not work on all platforms that support browser extensions, such as ChromeOS. In order to solve the problem of collecting browser extension usage statistics across all types of endpoints (e.g., user devices) in a fleet of user devices, the aforementioned gatherer browser extension164can collect this data. Whereas conventional solutions involve software that runs as an application directly on the operating system present embodiments include a browser extension to collect a list of browser extensions, thereby providing a platform-independent solution.

Reference is now made toFIG. 4, which illustrates an extension gathering process400, according to an example embodiment. As mentioned above, a gatherer extension164is provided. The gatherer extension164is force-installed throughout a fleet user devices with a managed policy. This policy contains a group secret that authenticates the gatherer extension164to a particular group in the browser extension risk assessment server120. When the gatherer extension is first installed on a browser162, it will use the browser's API to obtain both a list of extensions, e.g., extensions166(2)-166(4) that are installed, as well as the email address (or other identifier) of the user that is signed into or otherwise associated with the browser. This allows the browser extension risk assessment server120to attribute the list of extensions to a particular user. In addition to the extension ID, the browser extension risk assessment server collects, via the gatherer extension164, the name, version, and an indication of whether the extension is allowed in incognito mode. Once the gatherer extension164has these pieces of information, at it will send it to the browser extension risk assessment server120where the data is aggregated for searching and viewing.

At410, on a regular/periodic basis (e.g., every hour), the gatherer extension164will check to see if the list of installed extensions has changed. If so, at420, the gatherer extension164will send the updated list to browser extension risk assessment server120. If not, it does nothing. In the event the data in the browser extension risk assessment server120is deleted or otherwise inaccessible, the gatherer extension164will still send the browser extension usage data to the browser extension risk assessment server120once every several (e.g., seven) days.

Once the data is in the browser extension risk assessment server120, at430, a security administrator240can log in and view the aggregated data.FIG. 5illustrates an example user interface500that displays extension user statistics. The user interface500includes an icon field510for the extension icon, a name field512, an extension ID field514, an extension version field516, and a user field518that indicates how many users in an enterprise have installed a particular extension.

Specific users can be looked up to view what extensions and versions they have installed. Additionally, extensions link to risk assessment reports so that analysts can easily see how much risk a particular user is assuming. Extensions can also be sorted by the number of users that have a particular extension installed. This allows administrators to quickly sort extensions based on popularity within an organization.

Turning back toFIG. 4, since the browser extension risk assessment server120has been provided with information regarding the extensions that users have installed in addition to the risk reports for the extensions, at440, the browser extension risk assessment server120may automatically prompt end users to remove the extensions from their browser according to a policy of an enterprise.

In summary, as depicted inFIGS. 4 and 5, a gathering browser extension is provided that allows administrators to gain insight into the browser extensions that are used within their fleet of devices. This data can be used to regulate whitelists, consolidate similar extensions, and allow for streamlined incident response.

Browser extensions can introduce substantial risk to an organization, but it can be difficult for network administrators or security analysts to objectively determine the risk that a given extension may impose to the organization, especially if the analysts are not Javascript experts.

Browser extensions generally include the same elements: a manifest that defines capabilities and functions of the extension, and Hypertext Markup Language (HTML)/JavaScript/ Cascading Style Sheet (CSS) files. The browser extension risk assessment server120has the ability to automatically assess an extension based on a predetermined set of risky behaviors.

Reference is now made toFIG. 6.FIG. 6depicts a process600for generating an objective risk score associated with browser extensions. The risk score output of the process depicted inFIG. 6may be used in connection with any of the embodiments presented herein that involve evaluation of a risk score, such as those depicted inFIGS. 2 and 4.

At610, the browser extension risk assessment server120obtains (either manually or programmatically) an extension ID. A user can enter an extension ID manually, or the extension ID may be obtained by some automatic method, such as scripted API calls, or while scanning the web store. At620, the browser extension risk assessment server120downloads the specified extension package from the browser store140. The browser extension risk assessment server120then begins processing of the files in the extension package. At630, the analysis starts by reading particularly risky sections of the manifest. The permissions and optional permissions sections of the manifest defines what the extension is allowed to access. Each permission may have a particular risk value that is associated with the permission. The browser extension risk assessment server120will process the list of permissions and adjust the extension's risk score accordingly based on the severity of the permission and the number of permissions defined in the manifest.

One example of a scale is as follows:

Next, the browser extension risk assessment server120will ingest the extension's Content Security Policy from the manifest. For every entry in the connect-src, default-src, script-src, and object-src section of the Content Security Policy, one point of risk is added. If that entry contains an asterisk, five points of risk are added. If a connect-src, default-src, script-src object-src, or child-src policy is missing, twenty-five points of risk are added for each missing section.

The browser extension risk assessment server120will also pull the extension metadata from the browser extension's store. If an address for the developer is missing from the store, one point of risk is added. If an email for the developer is missing from the store, one point of risk is added. If a privacy policy for the extension is missing from the store, one point of risk is added. If less than 1,000 users have rated an extension at the time of scan, one point of risk is added. If a support site for the extension is missing from the store, one point of risk is added. If the extension has less than 100,000 users at the time of scan, one point of risk is added. If a website for the extension is missing from the store, one point of risk is added. It should be appreciated that these values provide only an example of one embodiment and do not imply any limitations with regard to the scoring of an extension or the aspects of an extension that are subject to evaluation.

As another example, the following points of risk may be added based on how long ago the browser extension was last updated at the time of scan:

Last updated one month or less from the current date: 0 points

Last updated between one and three months from the current date: 1 point

Last updated between three and six months from the current date: 2 points

Last updated between six and nine months of the current date: 3 points

Last updated between six and nine months of the current date: 4 points

Last updated between six and nine months of the current date: 5 points

The following points of risk may be added based on a rating, on a scale of zero to five stars, for the extension at the time of scan:

Greater than four stars: 0 points

Between three and four stars: 1 point

Between two and three stars: 2 points

Between one and two stars: 3 points

Less than one star: 4 points

At640, the next component of the browser extension assessed is the JavaScript. For every external JavaScript file found in HTML documents, 3 points of risk are added. This is due to the fact that changing the JavaScript on the external source can change the functionality of the extension without actually submitting an update to the store.

In addition to external JavaScript files, the browser extension risk assessment server120can also parse the JavaScript files of an extension to determine what external calls the extension is making. For every external call (for example: xhr, fetch, etc.) made in a JavaScript file, 1 point of risk is added.

Finally, the browser extension risk assessment server120runs a third party JavaScript library vulnerability scanner against the libraries used in the extension to discover if any have known vulnerabilities. Any vulnerabilities found will add points of risk based on their severity, such as:

At650, the browser extension risk assessment server120takes all of these findings and presents them to the user in an easy to use web interface that allows them to explore the results, and at660, the extension risk score is presented.

FIG. 7Aillustrates a user interface700providing information for an example risk score of an extension and the tabulation of that risk score for individual risk components.FIG. 7Billustrates a user interface710providing information for an example risk score of another extension and the tabulation of that risk score for individual risk components

In summary, as depicted inFIGS. 6, 7A and 7B, a method is provided by which a browser extension is scanned to determine its overall risk score, and that risk score is presented to the user in an easily digestible manner. This allows security conscious users and security operations analysts to determine if the extension is imposing an acceptable amount of risk to their user base.

When maintaining a browser extension whitelist, it is useful to know when an updated version of an extension becomes available in a browser extension store so that the new version can be re-reviewed and potentially removed from the whitelist if the new version is deemed too risky.

Reference is now made toFIG. 8, which shows a process800performed by the browser extension risk assessment server120to scan for risk changes due to updates to browser extensions. The browser extension risk assessment server120may continuously monitor extensions in order to determine when a browser extension receives an update. The browser extension risk assessment server120continuously scans the browser store140for new updates and publishes a Rich Site Summary (RSS) feed from which information can be shared regarding updates to extensions.

The browser extension risk assessment server120detects updates to browser extensions by reading the sitemap of the browser store140, and recording the timestamps for each shard of the sitemap as shown at810. At820, the browser extension risk assessment server120then triggers serverless code execution (e.g., via an AWS Lambda function) for each shard to download the shard and record every identified extension ID as well as the “last changed” timestamp associated with each extension.

If the “last changed” timestamp for an extension is different than what has been previously recorded in a database825, the browser extension risk assessment server120will re-download and analyze the extension. Once analysis is complete, an RSS feed for the extension is updated with the new version of the extension and a link to the scan report. At830, these RSS feeds can then be subscribed to by interested parties allowing them to get prompt notifications about new updates.

Additionally, in order to support the continuous scanning of unlisted extensions (e.g., extensions that are accessible with a link but do not appear in a web-based search or a browser store's sitemap), the browser extension risk assessment server120may perform a secondary continuous scan process. On a regularly-scheduled basis (e.g., every three hours), at840, the browser extension risk assessment server120will read a list of all extension IDs in its database. These extension IDs are then put in a queue that invokes an AWS Lambda function that will provide to an API for the browser store in order to obtain the current version of the extension and compare it to the current version that the browser extension risk assessment server120has scanned.

In addition to the RSS feeds that the browser extension risk assessment server120publishes, the browser extension risk assessment server120also makes available for download every version of every extension it has ever scanned. This allows an administrator to be able to install the old version of the extension for testing purposes and validate themselves what is in the report.

In summary, the browser extension risk assessment server120scans the entire browser continuously and publishes an RSS feed for every extension. This allows users to subscribe to it and be notified of updates to new extensions, which was previously not possible.

FIG. 9is a flow chart depicting a method900for automatically performing a risk assessment for a browser extension, according to an example embodiment. Reference is also made toFIG. 1for purposes of the description ofFIG. 9.

A request is received from a user to install an extension at operation910. This request for review of the extension may include a business justification for the extension, and may be transmitted by the gatherer extension164to the browser extension risk assessment server120. When a user of a device, such as user device160(1), navigates to a browser extension store page, the gatherer extension164may detect that the user has visited the page and may obtain the corresponding extension ID. In some embodiments, the gatherer extension164obtains the extension ID from the address bar of the web browser162. The gatherer extension164may transmit the extension ID to the browser extension risk assessment server120, which consults the whitelist121to determine whether the extension is included and is therefore approved for installation.

If the extension is included in the whitelist, then the extension may be installed on the web browser162of the user device; however, if the extension is not whitelisted, then the gatherer extension164may prompt the user to indicate whether the user would like to install the extension, and if so, may prompt the user to provide a business justification for the extension to be added to the whitelist. Once the request and business justification for the request are collected, the information may transmitted to the browser extension risk assessment server120.

A risk assessment report is generated for the extension at operation920. The risk assessment report may include an analysis of the risks associated with an extension. The risk assessment report may be generated by accessing, e.g., via an API, browser extension data from the browser extension store. The browser extension risk assessment server120may generate the risk assessment report by analyzing information obtained from the browser extension data, including manifest information, permission information, content security policy, and extension metadata. In some embodiments, the information obtained from the browser extension data is analyzed to determine whether the browser extension includes any vulnerabilities in third-party libraries (such as JavaScript libraries), any dangerous functions (e.g., functions deemed dangerous to the web browser162, operating system and/or other software of web browser162, or other devices in the enterprise network), and/or any dangerous entry points.

A risk score is generated for the extension at operation930. The risk score may be generated by summing the individual values associated with the permission, content security policy information, extension metadata, identified risks, and the like, that have been identified as associated with the extension. Thus, the risk score may be a value that represents the overall risk associated with an extension.

Operation940determines whether the extension satisfies the risk standards of the organization. The browser extension risk assessment server120may compare the risk score to a predetermined threshold to determine whether the browser extension exceeds a permissible threshold of risk for an organization. If the extension's score does not exceed the threshold, then the extension is automatically whitelisted at operation950. In some embodiments, when an extension is whitelisted, browser extension risk assessment server120may transmit instructions to the device of the user to install the browser extension. If the extension's score does not exceed the threshold, the extension is flagged for manual review at operation960. Extensions flagged for manual review may be reviewed by a network administrator, who may then add the extension to the whitelist, or may exclude the extension from the whitelist.

FIG. 10illustrates a hardware block diagram of a computing device1000that may perform the functions of any of the browser extension risk assessment server120(and user devices), referred to herein in connection withFIGS. 1-10. It should be appreciated thatFIG. 10provides only an illustration of one embodiment and does not imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made.

As depicted, the device1000includes a bus1012, which provides communications between computer processor(s)1014, memory1016, persistent storage1018, communications unit1020, and input/output (I/O) interface(s)1022. Bus1012can be implemented with any architecture designed for passing data and/or control information between processors (such as microprocessors, communications and network processors, etc.), system memory, peripheral devices, and any other hardware components within a system. For example, bus1012can be implemented with one or more buses.

Memory1016and persistent storage1018are computer readable storage media. In the depicted embodiment, memory1016includes random access memory (RAM)1024and cache memory1026. In general, memory1016can include any suitable volatile or non-volatile computer readable storage media. Instructions for the browser extension risk assessment logic1017may be stored in memory1016or memory1018for execution by processor(s)1014.

One or more programs may be stored in persistent storage1018for execution by one or more of the respective computer processors1014via one or more memories of memory1016. The persistent storage1018may be a magnetic hard disk drive, a solid state hard drive, a semiconductor storage device, read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, or any other computer readable storage media that is capable of storing program instructions or digital information.

The media used by persistent storage1018may also be removable. For example, a removable hard drive may be used for persistent storage1018. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into a drive for transfer onto another computer readable storage medium that is also part of persistent storage1018.

Communications unit1020, in these examples, provides for communications with other data processing systems or devices. In these examples, communications unit1020includes one or more network interface cards. Communications unit1020may provide communications through the use of either or both physical and wireless communications links.

I/O interface(s)1022allows for input and output of data with other devices that may be connected to computer device1000. For example, I/O interface1022may provide a connection to external devices1028such as a keyboard, keypad, a touch screen, and/or some other suitable input device. External devices1028can also include portable computer readable storage media such as database systems, thumb drives, portable optical or magnetic disks, and memory cards.

Software and data used to practice embodiments can be stored on such portable computer readable storage media and can be loaded onto persistent storage1018via interface(s)1022. I/O interface(s)1022may also connect to a display1030. Display1030provides a mechanism to display data to a user and may be, for example, a computer monitor.

Data relating to operations described herein may be stored within any conventional or other data structures (e.g., files, arrays, lists, stacks, queues, records, etc.) and may be stored in any desired storage unit (e.g., database, data or other repositories, queue, etc.). The data transmitted between entities may include any desired format and arrangement, and may include any quantity of any types of fields of any size to store the data. The definition and data model for any datasets may indicate the overall structure in any desired fashion (e.g., computer-related languages, graphical representation, listing, etc.).

In one form, a computer-implemented method is provided comprising: obtaining, from a user device of a plurality of user devices associated with an organization, a request to install a browser extension for a browser of the user device, wherein the request comprises an extension identifier and a business justification for the browser extension; generating, for the browser extension, a risk score that is based on risk values for each of one or more permissions requested by the browser extension; determining whether the browser extension satisfies risk standards of the organization by comparing the risk score to a threshold value for the organization; and in response to determining that the browser extension satisfies the risk standards, automatically adding the browser extension to a whitelist of permitted extensions for approved installation on the plurality of user devices. A risk assessment report may be generated by accessing, via an application programming interface, information pertaining to the browser extension from a browser extension store; and analyzing the information to generate the risk assessment report. The information may include one or more of manifest information, permission information, content security policy, and extension metadata. In response to automatically whitelisting the browser extension, an instruction may be transmitted to the user device to install the browser extension. The browser may include a gatherer extension that obtains the extension identifier from the browser. The request may include a business justification for installation of the browser extension.

The operation of analyzing the information may include determining whether the browser extension includes one or more of: a vulnerability in a third-party library, a dangerous function, and a dangerous entry point.

In one form, the computer-implemented method may further include determining that an updated version of the browser extension is available; generating, for the updated version of the browser extension, an updated risk score that is based on risk values for each of one or more permissions requested by the updated version of the browser extension; determining whether the updated version of the browser extension satisfies risk standards of the organization by comparing the updated risk score to a threshold value for the organization; and in response to determining that the browser extension does not satisfy the risk standards, removing the browser extension from the whitelist.

In another form, an apparatus is provided comprising: a communication interface configured to enable network communications; one or more computer processors; one or more computer readable storage media; program instructions stored on the one or more computer readable storage media for execution by at least one of the one or more computer processors, that when executed by the one or more computer processors, cause the one or more computer processors to: obtain, from a user device of a plurality of user devices associated with an organization, a request to install a browser extension for a browser of the user device, wherein the request comprises an extension identifier and a business justification for the browser extension; generate, for the browser extension, a risk score that is based on risk values for each of one or more permissions requested by the browser extension; determine whether the browser extension satisfies risk standards of the organization by comparing the risk score to a threshold value for the organization; and in response to determining that the browser extension satisfies the risk standards, automatically add the browser extension to a whitelist of permitted extensions for approved installation on the plurality of user devices.

In another form, one or more non-transitory computer readable storage media are provided that are encoded with instructions that, when executed by one or more processors, cause the one or more processors to: obtain, from a user device of a plurality of user devices associated with an organization, a request to install a browser extension for a browser of the user device, wherein the request comprises an extension identifier and a business justification for the browser extension; generate, for the browser extension, a risk score that is based on risk values for each of one or more permissions requested by the browser extension; determine whether the browser extension satisfies risk standards of the organization by comparing the risk score to a threshold value for the organization; and in response to determining that the browser extension satisfies the risk standards, automatically add the browser extension to a whitelist of permitted extensions for approved installation on the plurality of user devices.

In summary, the techniques presented herein solve the problem of determining whether to whitelist a browser extension in response to a request from a user. This approach automates the process of reviewing browser extensions to determine whether an extension may be included in an organization's whitelist of approved extensions. These techniques employ a special-purpose browser extension, called a gatherer extension, that is configured to gather information about browser extensions installed in a browser, a specialized process to generate a risk score associated with browser extensions, and a process to continuously scan a browser store to determine when updates are released to browser extensions.

These techniques provide security to a network without requiring manual intervention by an administrator, which can be time-consuming and costly. Moreover, these techniques provide feedback to network administrators regarding the requested extensions, enabling administrators to obtain a better understanding of the risks imposed by extensions in the event that manual whitelisting decisions are necessary.