©2008 Microsoft Corporation. All rights reserved.

Exploring Internet Explorer

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 Opt3In".
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 OptIn  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 opt3in to using the advanced features that might be exposed by more obscure ActiveX controls.
This IE7 feature is called ActiveX Opt3In. By default, ActiveX Opt3In 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 add3on "ABC Control" from "XYZ Publisher". If you trust the website and the add3on 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 Opt3In.

1. Controls that are commonly used and that were designed with security scrutiny will not be disabled. These controls
will appear on a pre3approved list.
2. Controls which were used in IE before upgrading to IE7.
 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 pre3approved list will run without the Opt3In prompt; however, if a control is pre3approved 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 OptIn apply? Where does it not apply?
ActiveX Opt3In applies to controls run in Internet Explorer and any applications which opt3in to Manage Add3ons through the
feature control key. ActiveX Opt3In can be enabled or disabled on a zone3by3zone 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 Opt3In 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 Opt3In.

Should your control be on the preapproved list?

Having your control on the pre3approved 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 pre3approved list.
Putting a control on the pre3approved 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
pre3approved list. Keeping your control off the pre3approved list will keep users secure by default and protect customers who
are not using your control.
Your control should be on the pre3approved list if:
Your control is (or uses) an ActiveX control that is preinstalled on a user's machine by Windows or by an OEM.

Controls installed by Windows or by an OEM will be disabled by ActiveX Opt3In unless you take steps to pre3
approve them. Pre3approving 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 pre3approved list. Because the controls were installed by
software, and not by the user, the controls will be disabled by ActiveX Opt3In.
Your control should not be on the pre3approved 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 pre3approved
list. There are two steps we highly recommend in order to prevent the control from running in IE.
1. Killbitting the control [ http://support.microsoft.com/kb/240797 ] will ensure that it can never load in
IE. Killbitting the control only requires setting a registry bit and is easily accomplished.
 1. Killbitting the control [ http://support.microsoft.com/kb/240797 ] 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 pre3approved 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 pre3approve 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 pre3approved list. ActiveX Opt3In 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 zone3lock 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 pre3approved. 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 Add3Ons group policy [ http://support.microsoft.com/kb/883256 ] or by adding the controls to the pre3
approved list in the registry.
How does my control get onto the preapproved list?
Because pre3approved 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 pre3
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 pre3approved 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 pre3approved 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 sandboxing33it 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 [ http://msdn.microsoft.com/library/default.asp?url=/workshop/author/
behaviors/overview.asp ] .
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.
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.
SiteLock 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 site3locking does not guarantee another site
cannot use your control. Cross3site scripting flaws and man3in3the3middle attacks could expose your control to other Web
sites. Site3locking should only be used as defense in depth; it cannot be your primary line of defense.
A site3locking template that uses Microsoft Active Template Library (ATL) is available: SiteLock 1.14 Template for ActiveX
Controls [ http://www.microsoft.com/downloads/details.aspx?FamilyID=43cd7e1e35719345c0388d93
ec9ea7fefbcb&displaylang=en ] .
Zone Lock your Control
If site3locking your control is too restrictive, you might still be able to zone3 lock your control. You could zone3lock your control
so it will only work when IE is in a specific zone, Internet, intranet, trusted sites, or restricted sites. As with site3locking,
however, zone3locking should be used as defense3in3depth and not a primary line of defense.
The SiteLock 1.14 Template also provides zone3locking functionality.
Ensure that ActiveX runs under leastprivilege environments
By default, Windows XP user accounts were administrator accounts because many features and programs did not run
correctly under non3admin 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 non3admin 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 [ http://
msdn.microsoft.com/library/default.asp?url=/library/en3us/dnlong/html/leastprivlh.asp ] and Understanding and Working in
Protected Mode Internet Explorer [ http://msdn.microsoft.com/library/?url=/library/en3us/IETechCol/dnwebgen/
ProtectedMode.asp?frame=true ] .
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 high3level steps: understanding the adversary's view, characterizing the security of the system, and
determining threats.
Please note that while this section presents a high3level overview of threat modeling, there are many more details and much
to learn about threat modeling33more 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.
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 [ http://blogs.msdn.com/ptorr/archive/2005/02/22/
GuerillaThreatModelling.aspx ] .
Threats to consider: STRIDE
STRIDE is a method of classifying the effect of a threat being realized. It is an acronym that stands for
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 [ http://msdn.microsoft.com/security/securecode/threatmodeling/
default.aspx ]
Threat Modeling [ http://www.microsoft.com/mspress/books/6892.asp ] , by Frank Swiderski and Window Snyder
Writing Secure Code [ http://www.microsoft.com/mspress/books/5957.asp ] , by Michael Howard and David
LeBlanc
Threat Modeling Tool [ http://www.microsoft.com/downloads/details.aspx?familyid=62830F9530E6134F87388A63
E7C663444AC1 ]
Secure Development Practices
Once you have designed and threat3modeled 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 fixed3length 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 [ http://www.msdn.microsoft.com/library/en3us/
dncode/html/secure05202002.asp ] for more information.
Limit DragandDrop Capabilities
Drag3and3drop 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 drag3and3drop capabilities in IE are now limited by a security
setting which may restrict the drag3and3drop capabilities of your control (URLACTION_SHELL_ENHANCED_DRAGDROP_
SECURITY).
For more information on tagging clipboard data, please see Shell Clipboard Formats [ http://msdn.microsoft.com/library/
default.asp?url=/library/en3us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_programming/transferring/
clipboard.asp ] .
For more information on the IE security setting regarding drag3and3drop, please see URL Action Flags [ http://
msdn.microsoft.com/library/default.asp?url=/workshop/security/szone/reference/constants/urlaction.asp ] .
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 [ http://msdn.microsoft.com/library/default.asp?url=/workshop/components/com/reference/ifaces/iobjectsafety/
iobjectsafety.asp ] 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.
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
[ http://support.microsoft.com/kb/161873/ ] .
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 [ http://msdn.microsoft.com/library/default.asp?
url=/workshop/components/activex/safety.asp ] .
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.
Hardware3enforced DEP detects code that is running from these locations and raises an exception when execution occurs.
Software3enforced DEP is a subset of hardware3enforced DEP, for machines that do not have supporting processors, and can
help prevent malicious code from taking advantage of exception3handling mechanisms in Windows.
Controls which are DEP compatible cannot execute code from any page which is marked non3executable. 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 [ http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2mempr.mspx ] and A Detailed Description
of the Data Execution Prevention (DEP) Feature [ http://support.microsoft.com/kb/875352 ] .
Use Automated Tools to Evaluate Your Code
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, de3referenced NULL pointers, access to uninitialized memory, excessive use of
the kernel3mode 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.

Kernelmode 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.
Driverspecific coding practices: Specific operations that are often a source of errors in kernel3mode 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 Step3by3Step [ http://www.microsoft.com/whdc/DevTools/tools/PREfast_
steps.mspx ] .
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 Add3on 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 Add3Ons dialog displays information about all of the controls on a user's system. (To open the
dialog, choose Manage Add3 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 Add3Ons dialog is taken from the following registry setting.
HKEY_CLASSES_ROOT
CLSID
{Control CLSID}
AppName="contoso.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 Add3ons 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 [ http://msdn.microsoft.com/library/default.asp?url=/workshop/
security/authcode/signing.asp ]
Introduction to Code Signing [ http://msdn.microsoft.com/library/default.asp?url=/workshop/security/authcode/
intro_authenticode.asp ]
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 site3locking 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?
 Can this control be used to spy on the user without their knowledge?
Is there a possibility for cross3site 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 site3locked your control, you should do testing of the
control on other Web sites to insure that site3locking 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
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.