Take the proper steps to secure ActiveX controls

ActiveX controls are powerful and useful in Web programming, but they can have negative security implications if proper steps aren't taken. Explore the risks of ActiveX controls for Web development, how they can be mitigated, and what alternatives exist.

Since Web programming first became popular in the mid-1990s, developers have looked for ways to augment vanilla HTML to create responsive and robust user interfaces inside the browser. One technique that fits this need involves hosting ActiveX controls inside a Web page running in various versions of Internet Explorer (IE) or using a plug-in with Netscape browsers.

ActiveX controls are indeed powerful and useful in Web programming; however, as most developers are aware, they can have negative security implications if proper steps aren’t taken to design them in a secure fashion. Let's look at the potential risks of ActiveX controls for Web development, how they can be mitigated, and what alternatives exist.

What’s the problem?
Originally, ActiveX controls (as COM objects) were designed to be programmable software components that could be assembled within a Windows application to quickly and easily design a user interface. These components were compiled to native instructions and could freely call the Win32 API on the target operating system.

When Web development became important, Microsoft provided the <OBJECT> element as a way to host these same controls in a Web page within IE. ActiveX controls were soon being downloaded to users' machines via IE and their native code executed. Unfortunately, IE has no way of “sandboxing” the code executed by the control, and so it's free to call any Win32 API with the permissions associated with the currently logged-on user. This means the control is tightly integrated with the operating system and can manipulate resources such as files and the registry on the local machine under the identity of the logged-on user.

Because ActiveX controls can do anything on the machine the user can do, developers need to be particularly aware of the following issues:
  • Bad data and buffer overruns—Most ActiveX controls accept data through methods or local or remote files. If a malicious user passed in malformed data or data that exceeded the expected length, he or she could overrun the buffer allocated by the control to hold the data and, in the process, purposefully overwrite other data structures (such as function return addresses or function pointers). The bad data can allow a malicious user to essentially take over the control so that it's used in unintended and possibly harmful ways.
  • SQL or script injection attacks—Many ActiveX controls use HTML or script-based input to generate SQL statements that are sent to a remote database server. A malicious user might attempt to embed SQL inside such input to attack a database or reveal information intended to be private. In the same way, some controls use input that is later written to HTML pages through script. Malicious users could attempt to embed script in the input to run their own scripts.
  • Scripting with unintended consequences—Most ActiveX controls support a set of methods and properties used by script on the Web page to manipulate the controls. If a malicious user were able to pass in unintended file paths, Web site addresses, and other identifiers, he or she could essentially repurpose your control and cause problems on the local machine or on a server with which the control communicates.
  • Repurposing from other sites—Because an ActiveX control is downloaded and installed on the user’s machine, it can be accessed simply through its COM CLSID. This means a malicious user might attempt to load your ActiveX control on his or her own page and then use it for purposes you did not intend. Once the location of a control is known, it can also be called across sites through the <OBJECT> element.

What can you do about it?
Considering the issues I just discussed, you can see why users avail themselves of the settings in IE (see Figure A) to prevent potentially unsafe controls from being downloaded.

Figure A
IE 6.0 Security Settings for ActiveX controls

To make sure the controls you design have the greatest chance of being downloaded and are as safe as possible, you should consider the following issues:
  • Validate, validate, validate—Certainly, the most important way to mitigate the risks of ActiveX controls is to be diligent about validating all data the control works with. This includes data from files and other sources from which the control is initialized and data passed into methods and properties. You should validate not only to avoid buffer overruns (especially if you’re coding in C or C++), but also to ensure that no injected SQL or script code has been embedded.
  • Safe scripting and initialization support—Of course, users don’t take these risks lightly. In fact, IE supports settings that allow a user to control how ActiveX controls are handled in the browser (as shown in Figure A). For example, ActiveX controls can be marked as Safe For Initialization and/or Safe For Scripting. By default, IE doesn't allow controls to be initialized with data (defined as receiving input via one of the IPersist interfaces) or scripted if these attributes are not present. As a result, you should mark your control with these attributes (by using either a registry setting identifying the component category during installation or by implementing the IObjectSafety interface) only if it must be initialized or scripted from the browser.
  • Digital signing—Although marking your control as Safe For Initialization and Safe For Scripting allows it to be used in the browser, those settings don't identify the publisher of the control. By digitally signing a control, a user can identity the source of the control through a trusted third party and can be ensured that the control has not been tampered with since it was signed. By default, the settings in IE allow signed ActiveX controls to be downloaded only after prompting the user and displaying the publisher certificate.
  • Preventing cross-site repurposing—Because ActiveX controls are installed on a user’s machine and can be downloaded from sites other than the site containing the <OBJECT> element, and because the Safe For Initialization and Safe For Scripting settings are simply globally on or off, you need to protect against attempted cross-site repurposing. One technique is to download and use the SiteLock template from the MSDN Web site. This template allows you to either restrict access so that a control is deemed safe in a predetermined list of domains or to customize behavior based on domain.

What are the alternatives?
In many cases, because ActiveX controls run well only in IE and because of the restrictions that can be applied at the browser, ActiveX controls are best suited for intranet environments where the client desktop is a known quantity.

However, even if you can make your control more secure by following the recommendations listed above, you should also determine whether an ActiveX control is the right tool for the job. There are, in fact, two other IE-based alternatives that you should consider:
  • DHTML behaviors—If the functionality you’re after is related to manipulation of the user interface to make it more responsive and Windows-like, you should consider DHTML behaviors. These are supported in IE 5.5 and higher and are used to encapsulate and reuse scripts. Being scripts, they have the advantage of running in a "sandboxed" environment; they don't allow cross-site referencing and are therefore secure.
  • Managed code and CAS—A second alternative is to design your controls using managed code in Visual Studio .NET. One of the great benefits of this alternative is that the .NET Framework goes a step further than simple identity-based security as used with ActiveX controls. The code access security (CAS) mechanism enforced by the common language runtime allows code (actually assemblies, the unit of deployment and security in the .NET Framework) to be assigned different levels of trust based on attributes of the code, such as its digital certificate or originating site or URL. In this way, coherent policies can be constructed that allow only code originating from known and trusted sources to execute on a PC with the .NET Framework.

For more information
To find out more about .NET security, read Dan's two previous articles on security in the .NET Framework:

Safety in mind
ActiveX controls are a powerful tool for Web developers looking to add rich user interface and tight integration with the underlying operating system. However, with their power comes responsibility, so you should always be aware of how you can design your controls with safety in mind.

Editor's Picks