Developing Secure ActiveX Controls (Windows CE 5.0)
This topic addresses the special requirements of ActiveX controls that are accessed by Web pages downloaded to an Internet browser.
However, the security issues discussed are also helpful for 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.
A Microsoft® ActiveX® control is a COM object that supports the IUnknown interface, and is self-registering.
Many ActiveX controls, especially 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 marked "safe for scripting" supports a method that allows it to print a file to an unspecified printer, and if a user browses to a Web page that invokes the control, files on the user's machine could be printed to another printer on the Internet without the user's knowledge.
There are two significant differences between the way ActiveX controls are managed on a Windows-based desktop OS 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 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 ActiveX controls that are built into the run-time image or that were installed by some other means, such as Microsoft ActiveSync, if the browser determines the control is safe to load.
When Internet Explorer receives a request to load an ActiveX control, it checks the URL security zones settings in the browser to determine whether the control can be run, and if the user should be notified that a control is to be loaded. For more information, see URL Security Zones.
If the security zone settings allow the control to be loaded, the browser 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 marked "INTERFACESAFE_FOR_UNTRUSTED_DATA" is presumed to be safe for any possible arguments. Similarly, a control 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 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 has not 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, by whom, and under what conditions.
When a Control Is Considered Safe
In general, a control is considered safe if there is no 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
Tips for Evaluating How Safe Your Control Is
Use the following list to help evaluate how safe your control is regarding 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 the input 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 reads, writes, creates, or deletes arbitrary persisted data, 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, be sure these methods cannot be accessed by another user or application.
Be sure your security evaluation accounts for what your control can do, not only what you expect it to do. Your security evaluation must represent the actual behavior of the control.
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), be sure to design the control 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 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 to run from a specific 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 Secure ActiveX Controls" in the Component Development section of the MSDN® Library.
See Also
Send Feedback on this topic to the authors