ActiveX Security: Improvements and Best Practices

Sharon Cohen
Rob Franco
Microsoft Corporation

February 1, 2006

Last Updated: 26 September 2006

Contents

• Overview
• Principles of Secure Design for ActiveX Controls
• Threat Modeling
• Secure Development Practices
• Secure Testing Practices

Overview

What's In This Document?

This document describes the changes in Internet Explorer 7 that reduce the number of ActiveX controls enabled by default through a feature called "ActiveX Opt-In".

This document also describes some of the best practices for developing ActiveX controls intended to run in Internet Explorer. These best practices have been compiled from the Security Development Lifecycle and from software developers who develop and test ActiveX controls intended for safe use on the Internet.

ActiveX Opt-In - What's New in IE7 for ActiveX

ActiveX controls are very important to the Internet because they allow developers to enhance Web pages with additional software application features that won't work in standard HTML Web pages. Web developers use ActiveX controls to add animation, multimedia and other features to their Web sites.

Because ActiveX controls, or any browser extension, add features for Web sites, they also increase the possibility of a security vulnerability. Internet Explorer 7 (IE7) will reduce the number of ActiveX controls available to Web sites on the Internet and thereby reduce the chances of a security vulnerability. IE7 makes it easy to use common sites with important controls but lets users opt-in to using the advanced features that might be exposed by more obscure ActiveX controls.

This IE7 feature is called ActiveX Opt-In. By default, ActiveX Opt-In disables the controls on a user's machine. When the user encounters a Web page with a disabled ActiveX control, they will see an Information bar with the following text: "This website wants to run the following add-on "ABC Control" from "XYZ Publisher". If you trust the website and the add-on and want to allow it to run, click here …" The user can choose to enable the ActiveX control from this Information bar, as shown in the following figure.

After the user selects "Run ActiveX Control" they are presented with the following Authenticode dialog from which they can allow the control to run.

Some ActiveX controls will not be disabled by ActiveX Opt-In.

1. Controls that are commonly used and that were designed with security scrutiny will not be disabled. These controls will appear on a pre-approved list.

2. Controls which were used in IE before upgrading to IE7.

3. Controls which the user downloads through IE7 will be automatically enabled during the download and install process.

Controls which are on the pre-approved list will run without the Opt-In prompt; however, if a control is pre-approved but is not installed on the machine, the user will have to go through the existing XPSP2 download behavior to get the control.

Where does ActiveX Opt-In apply? Where does it not apply?

ActiveX Opt-In applies to controls run in Internet Explorer and any applications which opt-in to Manage Add-ons through the feature control key. ActiveX Opt-In can be enabled or disabled on a zone-by-zone basis through the IE Security Settings panel. The setting, "Allow previously unused ActiveX controls to run without prompt" enables and disables the feature. By default, ActiveX Opt-In applies to controls used on the Internet and restricted sites zones while controls used on an intranet and trusted sites zones will not be affected by ActiveX Opt-In.

Should your control be on the pre-approved list?

Having your control on the pre-approved list can be valuable in some, but not all, situations. The situations below will help you determine if you need your control to be on the pre-approved list.

Putting a control on the pre-approved list will attract the attention and scrutiny of the security research community. Any vulnerabilities found in your control would expose a significantly larger number of users than if your control were not on the pre-approved list. Keeping your control off the pre-approved list will keep users secure by default and protect customers who are not using your control.

Your control should be on the pre-approved list if:

-

*Your control is (or uses) an ActiveX control that is pre-installed on a user's machine by Windows or by an OEM.*

Controls installed by Windows or by an OEM will be disabled by ActiveX Opt-In unless you take steps to pre-approve them. Pre-approving your controls will insure that users have the best possible experience on your Web site because it will work the way that you and the user expect.

• Your control is intended to run from Internet Zone Web pages.

  If, in the process of installing your application, ActiveX controls are installed which are intended to run on the Internet, you might want to add these controls to the pre-approved list. Because the controls were installed by software, and not by the user, the controls will be disabled by ActiveX Opt-In.

Your control should not be on the pre-approved list if:

• Your control is not intended to be run in Web pages served from the Internet.

  If your control is not intended to run in pages served from the Internet, then it should not be on the pre-approved list. There are two steps we highly recommend in order to prevent the control from running in IE.

  1. Killbitting the control will ensure that it can never load in IE. Killbitting the control only requires setting a registry bit and is easily accomplished.

  2. Do not mark the control safe for initialization or scripting. You should ensure this is true in both the component categories as well as through IObjectSafety Mechanisms.

• Your control is downloaded to the user's machine.

  If your control is not locally installed on the user's machine then there is no need to be on the pre-approved list. When the user downloads the control and chooses to install it, then the control will be approved. The user will not be prompted again after choosing to install from the authenticode dialog. Note: only the control whose CLSID was included in the object tag will be approved. If you have a single cab file which installs multiple controls, only the control initialized in the object tag will be approved. You might need to pre-approve any other controls which the .CAB file installs.

• Your control is only intended to run on your corporate intranet or your control is for a line of business application.

  You should not add these controls to the pre-approved list. ActiveX Opt-In is turned off by default in the intranet zone so your corporate ActiveX controls will not be affected. It would be a good idea to zone-lock these controls or restrict their capabilities when not running on an intranet.

  If you have controls created for business applications which are not applicable to the general public, these controls should not be pre-approved. You should work with the network administrators where your applications run to ensure that the right controls get approved on your users’ machines. This can be done either through Manage Add-Ons group policy or by adding the controls to the pre-approved list in the registry.

How does my control get onto the pre-approved list?

Because pre-approved controls add to the attack surface of a user’s system, you should make sure that your controls have been designed with security in mind. As the vendor for your ActiveX control, you are responsible for designing and testing it to ensure that the control meets the best practices criteria described in this document. By adding your control to the pre-approved list, you are warranting that you have reviewed the best practices for secure development outlined in this document and certify that implementation of your control followed these or equivalent principles for secure development of ActiveX controls. You are certifying that your control has no vulnerabilities to the best of your knowledge.

To put your control on the pre-approved list, you need to write the CLSID of the control to the following registry location.

HKEY_LOCAL_MACHINE

SOFTWARE

Microsoft

Windows

CurrentVersion

Ext

PreApproved

If Microsoft determines that a control has a vulnerability and presents a danger to end users, Microsoft reserves the right to remove that control at any time from the pre-approved list.

How to build secure ActiveX controls

Building a secure ActiveX control requires that designers, developers, and testers focus on security throughout the product lifecycle. Designers must restrict the capabilities of the control so that it can accomplish only the work it needs to do without any additional capabilities that might lead to exploits. Developers must code the control to act appropriately and safely when handling data. Testers must include test cases based on potential threats to the control. At each stage in the development lifecycle, security must be considered. The next sections go into more details on specific steps and considerations at each stage in the lifecycle of a control.

Principles of Secure Design for ActiveX Controls

Designing for security is important because ActiveX controls are exposed to content from malicious Web sites. Any Web site can try to use the control; all it needs is the control's class identifier (CLSID).  When you designed your control, you may have thought primarily about the control being used by some well intentioned pages, maybe even on your own website. To be safe for running in the internet zone, you must design your control to be safe when loaded from any page on the internet, particularly malicious pages. You need to ensure that malicious Web sites can't exploit your control to harm the user's system. As you design, think about how the functionality of your control could be exploited and what measures you can take to protect users from these exploits.

Restrict the capabilities of your control

Because an ActiveX control is a Microsoft Win32 component, there is no sandboxing--it can run without restrictions. You should think about how you can restrict the functionality of your control to prevent others from repurposing it to malicious ends. One of the first things you should think about when you consider writing an ActiveX control is if you really need an ActiveX control to accomplish the functionality you need. If you do not need access to system resources, you can write the control as a Dynamic HTML (DHTML) behavior.

In order for your control to be safe, the interface exposed to IDispatch (and therefore the Web) should be scoped as narrowly as possible while still meeting your functional requirements. If your function does not absolutely require input parameters, then remove them. If you can narrow the scope of the input parameters to a handful of known inputs, then do so. If your control writes data to the local computer, or in any way changes the state or behavior of the system, take time to consider how your control might be abused by a malicious third party.

Some scenarios you should consider when designing your control include the following.

• How many and what kind of parameters does your control take? Can you reduce the number of parameters or more closely restrict the kind of data they accept?

• Does the control rely on the URL of the hosting page to make security decisions? What happens if the control is unable to obtain the hosting URL from Internet Explorer? Does it fail securely in this case?

• Can the control be made to call other objects on the page, including Java applets? The Microsoft virtual machine (Microsoft VM) called from native code in the control might attribute greater permissions to the control than script on the page has. If the script can manipulate the control to call the Microsoft VM for it, an indirect security attack might be 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. You might prevent this by restricting the control to run only within a particular domain.

Many ActiveX controls are initialized with data from local or remote sites, and most ActiveX controls are scriptable, supporting a set of methods, events, and properties. Both initialization of persisted data and use of the controls through scripting require safeguards to ensure that security is not violated. If your control does not read persisted data, don't mark it as safe for initialization.

Site-Lock Your Control

One powerful way to restrict the capabilities of your control is to lock it to a specific domain. If your ActiveX control is designed only for a specific Web site, then locking it to the domain of that Web site will make it harder for other sites to repurpose the control in a malicious manner. However, you should be aware that site-locking does not guarantee another site cannot use your control. Cross-site scripting flaws and man-in-the-middle attacks could expose your control to other Web sites. Site-locking should only be used as defense in depth; it cannot be your primary line of defense.

See How To Tie ActiveX Controls to a Specific Domain for more information on how to lock your control to a domain. A site-lock template is also available.

Zone Lock your Control

If site-locking your control is too restrictive, you might still be able to zone- lock your control. You could zone-lock your control so it will only work when IE is in a specific zone, Internet, intranet, trusted sites, or restricted sites. As with site-locking, however, zone-locking should be used as defense-in-depth and not a primary line of defense.

Ensure that ActiveX runs under least-privilege environments

By default, Windows XP user accounts were administrator accounts because many features and programs did not run correctly under non-admin privileges. In Windows Vista, this will no longer be true. Users, by default, will not be administrators on their machines. ActiveX controls must be able to operate fully in a non-admin environment. Furthermore, when Protected Mode is enabled in IE the entire process will be running at a low integrity level, level 1. Controls need to be tested under normal user account privileges and if possible even developed in these accounts.

More information on user account privileges can be found in Security in Longhorn: Focus on Least Privilege and Understanding and Working in Protected Mode Internet Explorer.

Threat Modeling

Threat modeling is a process you can use to evaluate, plan for, and mitigate the potential threats your control might face. In order to fully protect controls from hackers, you must understand the threats to your applications. Threat modeling is composed of three high-level steps: understanding the adversary's view, characterizing the security of the system, and determining threats.

Please note that while this section presents a high-level overview of threat modeling, there are many more details and much to learn about threat modeling--more than can be included here. We highly recommend that you take advantage of additional resources to learn about threat modeling. Some recommended sources can be found at the end of this section.

The Threat Modeling Process

The threat modeling process consists of the following steps.

1. Identify Security Objectives: Clear objectives help you focus the threat modeling activity and determine how much effort to spend on subsequent steps.

2. Create a Control Overview: Itemizing your application's important characteristics and actors helps you identify relevant threats during Step 4.

3. Decompose your control: A detailed understanding of the mechanics of your control makes it easier for you to uncover more relevant and more detailed threats.

4. Identify Threats: Use details from Steps 2 and 3 to identify threats relevant to your control scenario and context.

5. Identify Vulnerabilities: Review the layers of your control to identify weaknesses related to your threats. Use vulnerability categories to help you focus on those areas where mistakes are most often made.

The following figure illustrates how the steps of the threat modeling process interact.

As you move through the development life cycle and discover more details about your control design, you should add progressively more detail to your threat model. Because key resources identified in threat modeling are also likely to be key resources from a performance and functionality perspective, you can expect to revisit and adjust your model as you balance all your needs. This is normal and is a valuable outcome of the process.

Data Flow Diagrams

Data flow diagrams (DFD's) are useful tools for understanding your ActiveX control. Building a DFD will help you gain understanding of how the control works, and analyzing the DFD will help you understand the threats that your control faces. DFD's should be a road map to your control. They should indicate all the input and output parameters that your control handles, data flow within the control, and trust levels associated with each component that handles the data. It is a good idea to use different shapes and line types to represent different characteristics of the components. For example, you can use:

• Rectangles to represent external entities.
• Circles to represent data processing components of your control.
• Lines to represent data flows within and between your component and the external entities.
• Dotted lines to represent trust boundaries, machine boundaries, process boundaries, or other "interesting" transitions.

It is also standard practice to use colors to represent the trust level of specific items.

• Red items are untrusted.
• Orange items are partially trusted.
• Green items are trusted.

Using these conventions places some logical constraints on your diagram. For example you should never have a trusted data flow coming from an untrusted data source. It is possible, however, to have an untrusted data flow between two trusted components. This kind of situation might indicate that the method of data flow is unreliable and would require that the receiving component treat the data as potentially dangerous.

Once you have created your DFD, you can examine it for threats. The more red components in your DFD and the farther the red components reach into your control, the more threats your control will face. When you examine the DFD, you want to consider places where green data is sent to red items. These could be places where information is improperly disclosed. Places where red data is sent to green items is another point that needs to be carefully examined. Untrusted data needs to be taken and processed in a safe manner. You need to check the validity and safety of the data before performing any unsafe operations. Be particularly sensitive to data that flow into your control from external sources, including: script from Web pages, files read from the local computer, user input, and data read from the registry. For example, you may have a configuration file that you write to the local computer, and you may think "I wrote that file in the first place, so I can trust the data in it." However, a malicious third party might have access to your configuration file but not the entire system. They may attempt to modify your file, and thereby induce your control to do something on their behalf that they couldn't have done otherwise (such as write to another file on the system, modify the registry, exploit a buffer overrun bug in some other code, and so on).

One good strategy to use when examining your DFD is to consider every kind of threat possible at each data entry point. The STRIDE model, described below, can help you evaluate the threats.

For more information, please see Guerrilla Threat Modelling.

Threats to consider: STRIDE

STRIDE is a method of classifying the effect of a threat being realized. It is an acronym that stands for

• Spoofing allows an adversary to pose as another user, component, or other system that has an identity in the system being modeled.

• Tampering is the modification of data within the system to achieve a malicious goal.

• Repudiation is the ability of an adversary to deny performing some malicious activity because the system does not have sufficient evidence to prove otherwise.

• Information Disclosurerefers to the exposure of protected data to a user that is not otherwise allowed access to that data.

• Denial of Service occurs when an adversary can prevent legitimate users from using the normal functionality of the system.

• Elevation of Privilege is when an adversary uses illegitimate means to assume a trust level higher than currently authorized.

You can use STRIDE to guide your investigation when considering what threats your control might be vulnerable to.

Other Resources on Threat Modeling

Many great resources exist on the Web detailing threat modeling and different ways to secure your controls. Here are a few.

• Threat Modeling resources on MSDN
• Threat Modeling, by Frank Swiderski and Window Snyder
• Writing Secure Code, by Michael Howard and David LeBlanc
• Threat Modeling Tool

Secure Development Practices

Once you have designed and threat-modeled your control it is time to start implementing.

Prevent Denial of Service Attacks

Be sure the control doesn't loop infinitely or stop responding when given bad data or arguments. An attacker might tie up a user's computer using your ActiveX control.

Safely Handle Memory

It is important for a secure ActiveX control to check all inputs and guard against buffer overruns. For example, if a control receives an input string into a fixed-length buffer without checking its length first, it is possible for a malicious caller to provide a string that is longer than the allocated buffer, overwriting other information in an unintended way. In some cases these bugs can be exploited to make the control perform unsafe operations it was not designed to do. As the author of an ActiveX control, you need to be vigilant. Never assume that a certain input conforms to certain requirements. Always check the data to avoid these attacks. All inputs should have maximum sizes, and controls should be tested to perform safely, even with inputs that are beyond specifications. See Fix Those Buffer Overruns for more information.

Limit Drag-and-Drop Capabilities

Drag-and-drop capabilities can be used to create many engaging and interactive experiences for users, however, ActiveX controls need to enable and react to these capabilities in a responsible manner. If your control acts as a drop target then you should not perform any unsafe action without prompting the user. If your control is a drag source, then you should be sure to set the CFSTR_UNTRUSTEDDRAGDROP Clipboard format. This will insure that any program reading the dropped data will know that it should not be fully trusted. You should also be aware that drag-and-drop capabilities in IE are now limited by a security setting which may restrict the drag-and-drop capabilities of your control (URLACTION_SHELL_ENHANCED_DRAGDROP_SECURITY).

For more information on tagging clipboard data, please see Shell Clipboard Formats.

For more information on the IE security setting regarding drag-and-drop, please see URL Action Flags.

Safe for Scripting and Safe for Initialization

There are a few different mechanisms that IE uses to determine that controls are safe to initialize and script. The IObjectSafety interface and Component categories manager are two tools that IE uses.

One of the first things to note about marking a control safe for scripting or initialization is that this should only be done for controls which you actually intend to be initialized or scripted. If your control does not need scripting functionality then do not mark it as such.

IObjectSafety is an interface that IE can use after a control is loaded to query the control and determine if the control believes that it is safe to be initialized and scripted. The component categories manager is a method for controls to register themselves as safe for use in IE. These are registry settings which IE can check prior to loading a control.

The IObjectSafety interface supports two methods, IObjectSafety::GetInterfaceSafetyOptions and IObjectSafety::SetInterfaceSafetyOptions. The GetInterfaceSafetyOptions method should return the control's security capabilities, safe for initialization and/or safe for scripting. The SetInterfaceSafetyOptions method is a request from the container, IE, to the control and indicates that the control should configure itself to be safe for initialization or scripting.

The component category manager is a way that IE uses the registry to determine when controls are safe for initialization and scripting. You should be sure to register your control with the component category manager when it is installing. Details on how to set these registry keys can be found at How to mark MFC ActiveX controls as Safe for Scripting and Initialization.

For more information on marking ActiveX controls safe for initialization and scripting via IObjectSafety and Component Categories, please see Safe Initialization and Scripting for ActiveX Controls.

Controls that Operate in the Local Machine Zone

ActiveX controls operating within the Local Machine Zone should not allow arbitrary content from the Internet to be written to files in predictable locations without user interaction. Furthermore, controls operating in the Local Machine Zone should not allow execution of arbitrary code directly or indirectly.

Design your control to be compatible with the Data Execution Prevention Feature

Data Execution Prevention (DEP) is a set of hardware and software technologies that perform additional checks on memory to help prevent malicious code from running on a system. DEP is available on Microsoft Windows 2003 Server SP1, Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and on Windows Vista.

DEP works by preventing code execution from data memory that is not marked EXECUTABLE, such as the stack and heaps. Hardware-enforced DEP detects code that is running from these locations and raises an exception when execution occurs. Software-enforced DEP is a subset of hardware-enforced DEP, for machines that do not have supporting processors, and can help prevent malicious code from taking advantage of exception-handling mechanisms in Windows.

Controls which are DEP compatible cannot execute code from any page which is marked non-executable. Note, ATL 7.1 and earlier is not DEP compatible so if you use ATL, you will need to compile your control with ATL 8.0 or later.

IE provides a setting you can enable to test your control with the DEP feature. Go to the Tools | Internet Options | Advanced tab and check the setting "Enable memory protection to help mitigate online attacks". (Note if you are running on Windows Vista, this setting can only be changed if Protected Mode is disabled. Once the feature is enabled, you can run in Protected mode.) You should use this IE setting to test your control and make sure it is compatible with DEP. Once your code is compatible with DEP, you should link your code with /NXCOMPAT.

For more information, please see Changes to Functionality in Microsoft Windows XP Service Pack 2, Part 3: Memory Protection Techniques and A Detailed Description of the Data Execution Prevention (DEP) Feature.

Use Automated Tools to Evaluate Your Code

Code reviews and quality assurance testing are highly valuable processes which are able to find and correct many bugs and threats; however, more recently, new automated tools have become available which can review your code and flag potential problem areas. One tool which Microsoft releases is called PreFast. It is available as part of Visual Studio Team System 2005 and also in the Windows DDK. PreFast will step through all the execution paths in your source code and look for errors in the following areas.

• Memory: Potential memory leaks, de-referenced NULL pointers, access to uninitialized memory, excessive use of the kernel-mode stack, and improper use of pool tags.

• Resources: Failure to release resources such as locks, resources that should be held when calling some functions, and resources that should not be held when calling other functions.

• Function usage: Potentially incorrect usage of certain functions, function arguments that appear incorrect, possible argument type mismatches for functions that do not strictly check types, possible use of certain obsolete functions, and function calls at a potentially incorrect IRQL.

• Floating point state: Failure to protect floating point hardware state in a driver and attempting to restore floating point state after saving it at a different IRQL.

• Precedence rules: Code that might not behave as the programmer intended because of the precedence rules of C.

• Kernel-mode coding practices: Coding practices that can cause errors, such as modifying an opaque memory descriptor list (MDL) structure, failing to examine the value of a variable set by a called function, and using C/C++ string manipulation functions rather than the safe string functions defined in Ntstrsafe.h.

• Driver-specific coding practices: Specific operations that are often a source of errors in kernel-mode drivers, such as copying a whole I/O request packet (IRP) without modifying members and saving a pointer to a string or structure argument instead of copying an argument in a DriverEntry routine.

This kind of automated code checking can greatly increase the security of your code and also reduce the number of bugs found later during testing.

For more information on PreFast, please see PREfast Step-by-Step.

Digitally Sign your Control

A digital signature on your control enables users to verify the control's publisher and ensures that it has not been tampered with since being published. Digital signatures help users make better trust decisions when determining if they should install a control and help identify your control in the Internet Explorer's Add-on Manager.

Digitally signing controls is a vital step if you want users to be able to easily install your control. Users are strongly discouraged from installing unsigned controls, and unsigned controls are blocked from installation by default.

Internet Explorer's Manage Add-Ons dialog displays information about all of the controls on a user's system. (To open the dialog, choose Manage Add- Ons from the Tools menu.) Signing your control will ensure that the Publisher field displays correctly in this list. As you can see in the image below, some of the publishers appear as "(Not Verified)"—these are controls which have not been signed.

If your control is installed by a CAB file or another executable, you must be sure to sign both the installation file (to enable installation) and the .dll or ocx file containing the ActiveX control (to ensure your publisher name shows up without the "Not verified" notice).

The name displayed in the Name Field of the Manage Add-Ons dialog is taken from the following registry setting.

HKEY_CLASSES_ROOT

CLSID

{Control CLSID}

AppName="contose.exe"
(Default)=(REG_SZ)"Control Name"
LocalizedStringPolicy=(REG_SZ) Localized Control Name

If you have a name that localized for other languages, set LocalizedString to point to the resource ID in your control's binary file that contains the translated name. Manage Add-ons checks this value first, and uses it if it exists. If the localized string does not exist, we fall back to the default value, which is (usually) the English name that does not get localized.

For more information, please see the following resources.

• Signing and Checking Code with Authenticode
• Introduction to Code Signing

How to Judge control Security

The security of a control is ultimately a subjective judgment. The following questions are designed to help you think about the security of your control. You can use them as part of your larger security review.

• Can you limit domain usage or zone usage? See the section on site-locking your control for more information.

• Are you exposing the user's private information over the network or to other users?

• Can you read, write, create, detect or delete arbitrary persisted data either on the file system, the registry, a buddy list, or a camera or other USB devices?

• Does this control enable data to passing from one Internet site to another? From the intranet to the Internet? From the local computer to the Internet?

• Can this control host mobile code or script? If so, where does the code or script come from?

• Does the control cause arbitrary operations or programs to execute on behalf of the user without notice?

• Does this control circumvent/defeat a specific security feature in the browser, operating system, or another application?

• Can a Web page use this control to cause the system to become unstable or stop responding?

• Can this control be used to spy on the user without their knowledge?

• Is there a possibility for cross-site scripting attacks using this control?

• Does this control load its own data format? Does this data type have its own security implementation? Does this data type allow macros?

• Is history, statistical, or debugging information persisted on the local computer? Can a privacy conscious user clear this information? Is the information ever sent over the network? Are globally unique identifiers (GUIDs) used to track users?

These are some other general questions that you should consider as you design your control.

• Are strings from the network validated, parsed, or filtered? What happens with the strings? What would happen if they contain script? What happens to the strings after they are passed on to another component?

• Where might there be buffer overruns? Have you done full testing for buffer overruns on all methods, properties, and events?

• What are you doing to stop an extraneous Web site from invoking the control?

• If you don't mark the control "safe for scripting" or "safe for initialization", does that disable the purpose of the control? Controls are marked as not safe for scripting or data initialization by default. Don't implement them unless the functionality of the control is hampered without them.

• Does the control present information to the user such that they can always identify its authenticity? Do you digitally sign the control?

In addition, it is a good idea to document the following information about your control for reference.

• Methods
• Properties
• CLSID
• Events
• Owner
• DLL/OCX name and version

Secure Testing Practices

Validate the control for security using the following four practices.

Create Test Cases based on Threats Identified in the Threat Model

For each threat identified in your threat models, you should create a test case. The test cases should confirm that the identified threat has been mitigated by the design or implementation of your control. While design and developer documentation can describe how a control should behave, only testing can confirm how a control actually does behave.

Penetration Testing

Penetration testing is security testing in which testers aim to circumvent the security features of an application, or in this case, an ActiveX control. Penetration testing includes, but is not limited to, denial of service, stress testing of all network interfaces and fuzz testing of all file formats used by the control. Penetration testing should verify any explicit access controls, such as ACLS and also verify correctness in all code which processes untrusted data. You should also test any security mitigation you may have included in the control. For example, if you site-locked your control, you should do testing of the control on other Web sites to insure that site-locking was properly implemented.

Fuzz Testing

Fuzz testing should be performed on any ActiveX control that handles data. The idea behind fuzz testing is to provide structured but invalid inputs to your control. This kind of testing requires a high volume of test cases, with many variations and mutations in the data that you test the control with. Most often, fuzz testing is done using automated tools. The objective of fuzz testing is not to ensure that your control acts in an expected manner on the invalid data but to ensure that your control acts in a safe manner when given invalid data. Your control should not crash or cause a buffer overrun when handling invalid data.

Fuzz Testing should be done on the following areas of your control.

• Any methods within the control
• All parameters used by the control
• Any data from a remote source, for example if you have a property that takes a URL you should fuzz test the URL itself but you should also fuzz test the file that is downloaded from the URL.

There are two different parameters to consider when choosing the fuzz data you test your control on. The first consideration you might make is whether to use a smart or dumb form of data generation. The differences in these two forms are similar to the difference between black box and white box testing. Dumb data generation, similar to black box testing, generates input without knowledge of the intended data format or processing functions. Smart data generation, similar to white box testing, generates input based on knowledge of the correct data structure and how it is processed in the control. A second consideration when generating data is whether to generate new data or to mutate valid data. Generating new invalid data may be more appropriate when you are doing dumb fuzz testing. Mutating valid data so that it becomes invalid may be more appropriate when you are doing smart fuzz testing. For most controls you will want to use a combination of dumb and smart fuzz testing and generate some of the test data while also mutating other data.

Regression Testing

Regression testing ensures that new changes in the code have not broken any functionality which was previously working. Regression testing needs to be done at every major milestone in the development cycle. It is important to regression test not only on the functionality of your controls but your security test cases as well.

Acknowledgements

We would like to thank the following for their help in preparing and reviewing this article: David Ross, Philip Nachreiner, Eric Lawrence, Mike Friedman, Patrick Mann, Levent Besik, Cullen Sauls, Josh Cain, and Madhuvan Gupta.

Sharon Cohen and Rob Franco are program managers on the Internet Explorer team.