Geoff Chappell - Software Analyst
BOOL
CoInternetExtensionAllowed (
REFCLSID rclsid,
DWORD flags);
The rclsid argument is a reference to the CLSID of the extension.
The flags argument is ignored.
The function returns a boolean indicator of whether the given extension is allowed.
Among the Internet security features introduced with the URLMON version 6.00 from Windows XP SP2 is one for controlling which extensions are allowed. The name of this feature, both as a symbolic constant and a registry key, is FEATURE_ADDON_MANAGEMENT. If this feature is disabled, meaning that there is no management of add-ons, all extensions are allowed. Otherwise, extensions are subject to several forms of control.
One way to control extensions, given URLMON version 7.00 or higher, is to turn them off en masse. When extensions are off, only a relatively few so-called system extensions are allowed.
Note that this is a run-time defence. Extensions are turned off by calling the CoInternetSetExtensionsOff function while FEATURE_ADDON_MANAGEMENT is not disabled. A corresponding function, CoInternetIsExtensionsOff, reports whether extensions actually are off.
Extensions can be managed as administrative policy, both collectively and selectively. Whether a particular extension is allowed can be set as a registry value using the extension’s CLSID in either of two keys listed below in order of decreasing precedence:
| Key | HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Ext\CLSID
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Ext\CLSID |
| Value | {clsid} |
| Data | 0 if extension is disallowed; 1 if extension is allowed; else extension is not managed by policy |
Although URLMON interprets the data as a string, it does not enforce any particular type (such as REG_SZ). These settings for particular extensions have user-interface support through the Group Policy Object Editor, as the Add-on List in the folder Add-on Management among the Security Features in the Internet Explorer administrative template (displayed under Windows Components).
Another setting covers extensions that do not have a registry value for their own CLSID:
| Key | HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Ext
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Ext |
| Value | RestrictToList |
| Type | boolean |
| Default | false |
Evaluation as true means that the extension is disallowed by policy. Otherwise, is not managed by policy. This setting also has user-interface support, as “Deny all add-ons unless specifically allowed in the Add-on List” in the same folder of the Group Policy Object Editor.
If a system extension isn’t managed by policy, it is allowed. Other extensions that aren’t managed by policy can be disallowed selectively as preferences, i.e., in a user’s own registry settings or as machine-wide administrative guidance which users can override:
| Key | HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{clsid}
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{clsid} |
| Value | Flags |
| Type | REG_DWORD |
| Default | 0 |
To disallow the extension whose CLSID is clsid, the dword of data for Flags must have either the 0x01 or 0x10 bit set, and the following value
| Key | HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{clsid}
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{clsid} |
| Value | Version |
| Type | REG_SZ |
must have * as its string data. Without both these settings, the extension is allowed.
These user settings have user-interface support through the “Manage add-ons” button in the Programs tab of the Internet Options. The same dialog is also reachable through the “Enable or disable Add-ons...” on the Manage Add-ons submenu of Internet Explorer’s Tools menu. The Settings subkey does not seem to be formally documented, but it is acknowledged in a Knowledge Base article How to manage Internet Explorer add-ons in Windows XP Service Pack 2.
A slightly difficult problem occurs when users have disabled an add-on, which they subsequently uninstall and then reinstall. Should it still be disabled? It may be that the user really does mean to banish that particular extension forever, but it may also be that the user is now uninstalling and reinstalling in the hope of restoring the software to its pristine configuration. Though an uninstall program for an add-on may reasonably be expected to delete the registry key that listed the add-on as a browser extension, not all will know to delete the Settings subkey. After all, many add-ons pre-date it and Microsoft seems not to document it except as an afterthought (see the Knowledge Base article How to manage Internet Explorer add-ons in Windows XP Service Pack 2).
If an extension is disabled by preference but seems not to be installed, then this function treats the preference as stale. It deletes the extension’s Settings subkey and declares that the extension is allowed after all.
For this purpose, an extension is considered to installed if it is registered in HKEY_CLASSES_ROOT or as a browser extension. The former means that HKEY_CLASSES_ROOT\CLSID\{clsid}, where clsid is the extension’s own CLSID or its redirection through a TreatAs subkey, must have an InprocServer32 or LocalServer32 subkey whose default value has no more than MAX_PATH characters of data. To be registered as a browser extension means that a key named Software\Microsoft\Internet Explorer\Extensions\{clsid} exists in either HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER.
The CoInternetExtensionAllowed function is exported as ordinal 103 from URLMON.DLL version 7.00 and higher.