To resolve these zone issues, the ActiveX control needs to comply with several security measures that are in place. One such method of resolving the issue is code signing the ActiveX control. This is done with a certificate that is specifically created for code signing. Before signing, the ActiveX control should be packaged into a .CAB file that contains not only the binary file of the control but also the .INF file used to install the control. For more information on code signing, please see the Introduction to Code Signing Article on MSDN and also Richard Lewis' blog post on Application Security .
| Internet Zone | All internet websites, except those in the Trusted or Restricted Zones. The default zone for all internet websites |
| Local Intranet Zone | The zone reserved for all websites on your intranet |
| Trusted Sites Zone | As the name implies, this zone is reserved for sites that you trust not to damage your computer or files |
| Restricted Sites Zone | As the name implies, this zone is used to classify sites that are inappropriate or that may cause damage to your computer or files |
The fifth security zone is the Local Machine zone. This zone is an implicit zone that exists on the local computer. You cannot configure the security settings for this zone via the Internet Explorer options or the Security Zones property sheet. If you have administrator privileges, you can modify the security settings for the Local Machine zone by modifying the registry.
Each of these security zones uses a default template which can be viewed by highlighting the zone icon in the list as shown above. The templates are designed to provide the best security possible when connecting to web sites. The security settings for these zones can be customized by selecting a zone and then clicking on the "Custom Level ..." button. Although the templates are in place, there are no sites added by default to any of the zones shown above. Within each of the templates there are individual security settings that pertain to ActiveX controls. The table below shows the details for the ActiveX controls and plug-ins security settings. Please note that some of these settings are specific to Windows XP Service Pack 2 and later operating systems.
As you can see, the more restrictive the nature of the zone the more restrictive the settings for the ActiveX controls. This is to protect the user. However if the ActiveX control is unsigned and the page is loaded in the Internet zone, by default the control will not run (per the table above). ActiveX controls are very powerful and versatile. However, they may also be extremely insecure. Because an ActiveX control is a COM object it can do anything that the user can do from that computer. Once a user downloads an ActiveX control, that control may be vulnerable to attack because any web application on the Internet can repurpose it and use the control for its own ends. However, there are measures that can be taken when writing ActiveX controls to guard against this. The following should be considered when creating an ActiveX control:
- 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 the control does not read persisted data, it should not be marked as safe for initialization. If the control is not designed for use in a browser, it should not be marked as safe for scripting.
And that brings us to the end of this post on ActiveX and Security. In our three-part series we have gone over the basics of ActiveX, covered the management of ActiveX controls within Internet Explorer and covered the Security aspects of ActiveX within the Internet Explorer environment. I hope you have found this information useful.
- Brent Goodpaster