Developing Secure ActiveX Controls

  • Article

A Microsoft® ActiveX® control is a COM object that supports the IUnknown interface, and is self-registering. Many ActiveX controls, particularly those used in Web pages, support the IDispatch interface, which allows scripting languages, such as Microsoft JScript® development system (JScript) and Microsoft Visual Basic® Scripting Edition (VBScript) to access the control easily.

The same mechanism by which ActiveX controls can be properly accessed by other controls and applications makes them particularly vulnerable to misuse, intentional and otherwise. For example, if an ActiveX control that is marked "safe for scripting" supports a method that allows it to print any file to an unspecified printer, and a user browses to a malicious Web page that invokes the control, files on the user's machine could be printed out to another printer on the Internet without the user's knowledge.

This topic is intended to address the special requirements of ActiveX controls that are accessed by Web pages downloaded to an Internet browser. However the security issues discussed here are of interest to any developer who uses ActiveX technology in an application. These security considerations are important for any ActiveX control that is initialized with persistent data (either local or remote), or that is scriptable.

There are two significant differences between the way ActiveX controls are managed on a Windows-based desktop platform running Microsoft Internet Explorer and the way these controls are managed in Windows CE. First, Windows CE does not have the Component Categories Manager to register and unregister controls and to provide information about the categories that are implemented or required by a control. Therefore all ActiveX controls must be registered by manually editing the system registry, or by the setup program that installs the control. Second, Internet Explorer for Windows CE does not allow users to download ActiveX controls through the browser. However, a Web page can still load and run any ActiveX controls that are built into the platform, or that were installed by some other means, such as Microsoft ActiveSync® 3.0 if the browser determines the control is safe to load.

When Internet Explorer receives a request to load an ActiveX control, it first checks the URL Security Zones settings in the browser to determine whether the control can be run, and if the user should first be notified that a control is to be loaded.

If the security zone settings allow the control to be loaded, the browser then queries the control to determine if the control implements the IObjectSafety interface. This interface allows Internet Explorer to retrieve the current initialization or scripting capabilities for an ActiveX control. A control that is marked "INTERFACESAFE_FOR_UNTRUSTED_DATA" is presumed to be is safe for any possible arguments. Similarly, a control that is marked "INTERFACESAFE_FOR_UNTRUSTED_CALLER" is presumed to be safe for any possible use of its properties, methods, and events. For example, in response to a query, the control might return that it knows about the INTERFACESAFE_FOR_UNTRUSTED_DATA and INTERFACESAFE_FOR_UNTRUSTED_CALLER capabilities, and that it is currently safe only for INTERFACESAFE_FOR_UNTRUSTED_DATA. The browser can then refuse to load the control, or it can put up a dialog box, asking the user if the operation should be permitted.

If the control does not implement IObjectSafety, Internet Explorer checks the compatibility flags in the registry to determine if the control is registered as being safe for scripting. A control is registered as safe for scripting if the key for the control includes a subkey under the "Implemented Categories" key for the control that contains the CATID_SafeForScripting GUID {7DD95801-9882-11CF-9FA9-00AA006C42C4}

Developers should identify an ActiveX control as being safe for initialization and scripting only after thoroughly reviewing the control for security vulnerabilities. Any control that is not intended to be run from a browser container should not be registered as safe for scripting. Developers should also digitally sign ActiveX controls. Digital signing tells users where the control came from and verifies that the control hasn't been tampered with since its publication.

Security Considerations for ActiveX Controls

Ultimately the safety of an ActiveX control depends on how frequently it is accessed and by whom, under what conditions. In general, a control is considered safe if there is no possible way for it to be used by any person or application to do any of the following:

  • Obtain information about the local computer or user.
  • Expose private information on the local computer or network.
  • Execute system calls or other actions that could change or destroy information on the local computer or network.
  • Launch a denial of service attack by consuming excessive resources.
  • In any way cause unpredictable results by being used for something other than its intended purpose.

The following checklist will help you determine whether your control can legitimately be marked as being safe for untrusted data and scripting.

  • Test for buffer overruns, especially with input that could create a denial of service attack.
  • Test that input to parameters is accepted only if it is within a range of values that would legitimately be expected and that arbitrary input does not permit access to private information.
  • If your control allows read, write, creation or deletion of arbitrary persisted data, then you must implement safeguards to ensure that these methods cannot be applied inappropriately.
  • If it is possible for the control to read from or write to the registry you must ensure that these methods cannot be accessed by another user or application.

It is essential that your security evaluation represents the actual behavior of the control. Ensure that your security evaluation accounts for what your control can do, not only what you expect it to do. If the control performs actions that are inherently unsafe, such as exposing or deleting private data (and many useful controls, such as tools for system configuration are inherently unsafe), then the control should be designed to run only on trusted Web pages, such as the local intranet zone or trusted sites zone.

To prevent an ActiveX control from being used on pages other than the one on which it designed for, the control can use the DHTML object model to obtain the uniform resource locator (URL) of the page that is trying to load it. If the control is intended to run from a particular site, it can, if called from another site, refuse to load, or run in a limited capacity.

For more information about security considerations for designing ActiveX controls see "Designing Safe ActiveX Controls" in the Component Development section of the MSDN® Library.

Last updated on Wednesday, April 13, 2005

© 2005 Microsoft Corporation. All rights reserved.