Designing Safe ActiveX Controls

Any ActiveX® control to be deployed and used with Microsoft® Internet Explorer should be conceived and designed with object safety in mind from the start.

Safe design is important because many ActiveX controls are initialized with persistent data (either local or remote), and most ActiveX controls are scriptable (they support a set of methods, events, and properties). Both initialization with persistent data and scripting require safeguards to ensure that security is not violated. Developers should mark their ActiveX controls safe for initialization and scripting.

Developers should also digitally sign their ActiveX controls. Digital signing tells users where the control came from and verifies that the control hasn't been tampered with since its publication.

This article contains information about the following topics:

Types of Object Safety

There are two variations of object safety that usually, but don't always, go together:

"Safe for untrusted data" asserts that the control is safe for any possible arguments (PARAM tags of an OBJECT object).
"Safe for scripting" asserts that the control is safe for any possible use of its properties, methods, and events.

ActiveX Control Safety Checklist

Safety of the control is ultimately a subjective judgment, but as a general rule "safe" means that none of the following undesirable effects will result from any conceivable use of the control:

Exposure of private information on the local computer or network.
Modification or destruction of information on the local computer or network.
Faulting of the control and the potential crashing of the browser.
Consumption of excessive time or resources such as memory.
Execution of potentially damaging system calls, including execution of files.
Use of the control in a deceptive manner and causing unexpected results.

To help fulfill these abstract requirements, here are some questions to consider carefully before marking a control as safe. The same questions apply to both untrusted data and scripting.

What files can the control potentially access?
- The ability to create files can be used to put content into the trusted local computer file system, possibly overwriting valuable data.
- Any arguments that allow arbitrary file paths to be specified are particularly suspect as potentially allowing access to private information.
- Writing excessive amounts of data even to restricted sets of files can use up disk space.
Is registry access possible?
- Access to even limited parts of the registry could reveal information that should be kept private.
- Writing large amounts of data to the registry could waste resources or possibly corrupt the system.
What system calls can the control be made to do?
- Executing code or arbitrary shell commands (such as FORMAT) is particularly dangerous.
- Think about how any system calls might be used by a malicious page, especially those calls with arguments that can be influenced by an untrusted data PARAM tag or script invocation.
Other issues:
- Since any control can be used by any page that happens to know its CLSID, think about how the control might be reused maliciously in a completely unrelated page. Would the user possibly be tricked by seeing the familiar control out of context?
- Be sure the control won't loop infinitely or crash when given bad data or arguments.
- Can the control be made to call other objects on the page, including Java applets? The Java virtual machine (VM) called from native code in the control could attribute greater permissions to the control than script on the page has. If the script can manipulate the control to call the Java VM for it, an indirect security attack is possible.
- Can the control tunnel out of the frame in which it is hosted and access content in another frame? The data accessed could potentially violate the privacy of the user.

Using ActiveX Controls Safely in an Enterprise Intranet Environment

Using Internet Explorer 4.0 Security Zones, it is possible to configure the browser to only download or run ActiveX Controls located within the enterprise—in other words, the intranet. When a control is downloaded and installed on the local system, however, the location of the original download is no longer available, and the control is available for use on any page that might reference its CLSID. Thus, be aware of the possibility that an Internet page might reference a control intended only for the intranet. There are several approaches to handling this issue.

If the ActiveX Controls are safe for untrusted data and for scripting, supporting IObjectSafety and requiring only safe controls is the simplest solution. Controls that are truly safe should not be usable to break security, even by an untrusted Internet page.

To prevent an ActiveX control from being used on pages other than the one on which it is intended to be used, the control can check the context in which it is instantiated. That is, a control can get access to the DHTML Object Model as described previously to get the URL of the page instantiating it. The location properties of the document object return the URL of the page in which the control is embedded. For instance, an ActiveX control could be designed to run only in the "http://admin" intranet area. When the URL of the containing document begins with a different protocol and host name, it could run with reduced functionality or otherwise completely disable itself.

Be aware that some important controls might be inherently unsafe for scripting. They include tools to aid system configuration or installation. To safely use these ActiveX Controls in the intranet environment, it is important to guarantee:

That these controls be used only by intranet pages and cannot be reused by other untrusted security zones.
That any intranet pages that use these controls do so in the intended manner and with appropriate safeguards.

The first restriction can be enforced because, by default, ActiveX Controls are not safe for scripting. A system administrator can configure a custom security policy to override object safety for a specific intranet zone. Controls that are not marked as safe will run only in pages from this zone. In fact, it is possible to restrict a control to run only in a designated secure zone by explicitly not marking the control as safe. Of course the Internet zone should never be set to override object safety.