Designing Secure ActiveX Controls
Any Microsoft ActiveX control should be conceived and designed with security in mind.
An ActiveX control can be an extremely insecure way to provide a feature. Because it is a Component Object Model (COM) object, it can do anything the user can do from that computer. It can read from and write to the registry, and it has access to the local file system. From the moment a user downloads an ActiveX control, the control may be vulnerable to attack because any Web application on the Internet can repurpose it, that is, use the control for its own ends whether sincere or malicious. But, you can take precautions when you write a control to help avert an attack.
You have a responsibility to users to provide the most secure controls. Do not assume that your control is secure until it has gone through a rigorous security review. This article contains some guidelines you can incorporate into your security review process.
This article contains information about the following topics:
- Security Considerations
- How to Judge Control Security
- Preventing Repurposing
- Related topics
Security Considerations
Designing for security is important because an ActiveX control is particularly vulnerable to attack. An application running on any Web site can use the control; all that it needs is the control's class identifier (CLSID). The control may be repurposed, that is, used in ways that you did not intend. The repurposing might be friendly or a malicious attack on the computer running the control. As you design a control, think about what specific measures you should take to protect it.
Before you implement a feature as an ActiveX control, consider whether you can achieve the same functionality through other means. If you do not need access to system resources, you can write the control as a Dynamic HTML (DHTML) behavior.
Because an ActiveX control is a Microsoft Win32 component, there is no sandboxing, that is, it can run without restrictions. You should think about how you can restrict functionality to prevent others from repurposing your control to possibly malicious ends.
- 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 (they support 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. If your control is not designed for use in a browser, don't mark it as safe for scripting.
You should digitally sign every ActiveX control. Digital signing tells users where the control came from and verifies that the control has not been tampered with since its publication.
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.
It is important for a secure ActiveX control to check all inputs and guard against buffer overrun. 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.
How to Judge Control Security
The following questions are designed to help you build a more secure ActiveX control. You can use them as part of your larger security review. Think about how to answer each question and how you might design your control more securely. The security of a control is ultimately a subjective judgment. As a general rule, if you answer yes to any of these questions you should probably not mark the control as safe for scripting or safe for data initialization, or you should implement some type of lock down security, that is, restrict the use of the control to within a specific set of domains.
- Can you limit domain usage or zone usage? See Preventing Repurposing 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 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
Preventing Repurposing
If you don't take precautions when you develop the control, an ActiveX control has virtually unlimited access to the computer it resides on. It can change registry settings, can manipulate the local file system, and can provide security rights not normally available to an external Web site. An attacker can repurpose an ActiveX control and use it to gain access to the computer.
Marking an ActiveX control as safe for scripting can leave you open to attack. Do not mark a control as safe for scripting unless you absolutely have to. You can use the list of questions in How to Judge Control Security while designing your control to help you decide.
If you decide that your control must be marked as safe for scripting, then you can protect the control by restricting the domains in which the control can be scripted. This is referred to as "site locking" (or, locking down your control) and makes it harder for a control to be maliciously repurposed. A site-locked control returns different results from IObjectSafety depending on the domain name of the host site.
The SiteLock template for ActiveX controls can be used in an Active Template Library (ATL) or C++ project to help you write a secure control that restricts the domains in which it can be scripted.
Related topics
Reference
Conceptual
Introduction to ActiveX Controls
Safe Initialization and Scripting for ActiveX Controls
Signing Code with Microsoft Authenticode Technology
Other Resources