General discussion


DOWNLOA Improve the security of ActiveX while maintaining usability

By jasonhiner Moderator ·

After you take a look at this download, please post your feedback, ideas for improvements, or further thoughts on this topic.

TechRepublic Downloads Team

This conversation is currently closed to new comments.

14 total posts (Page 1 of 2)   01 | 02   Next
| Thread display: Collapse - | Expand +

All Comments

Collapse -

the title is misleading

by Jaqui In reply to DOWNLOAD: Improve the sec ...

as there is no way to use activex and maintain security.
activex is a security risk in itself, and requires a security risk for operating system.

the title of the download is false advertising.

Collapse -

True if you squint

by Tony Hopkinson In reply to the title is misleading

Improving the security of ActiveX in no way implies making ActiveX secure.
Another wax padlock.

Collapse -

I would disagree with that (with one disclaimer)

by jasonhiner Moderator In reply to the title is misleading

I think the traditional view in IT is that the only way to secure ActiveX is to disable (and to be honest I have always pretty much been in that camp). Still, if you have a Web-based app that you need to use as part of a partner solution or a line-of-business solution, for example, you could set up a draconian policy in which only those sites are allowed to use ActiveX and all other ActiveX controls are automatically denied. That's what this download is getting at.

Now, you obviously wouldn't want to do this in a high-security environment, but the average IT shop that wants to allow an ActiveX control a from a trusted source and block everything else should realize that they have the power to do that. And that's certainly much smarter than just enabling ActiveX all together because your company requires it for one line-of-business app.

Collapse -

ActiveX Security?

by Info-Safety, LLC In reply to DOWNLOAD: Improve the sec ...

Anyone interested in locking down Internet Explorer should check out Qwik-Fix Pro at

Craig Herberg

Collapse -


by deepsand In reply to DOWNLOAD: Improve the sec ...

Is'nt the notion of "more secure Active-X" sort of like that of a "less lethal execution"?

Collapse -

more like

by Tech Locksmith In reply to Oxymoron?

I think it is more like putting a padlock on the high explosives which you are forced to use anyway.

Collapse -

With the same result.

by deepsand In reply to more like

Either way, one false move & you end up toast.

Collapse -

ActiveX and XP SP2

by mark In reply to DOWNLOAD: Improve the sec ...


As someone who has been using the Add-On Management feature of SP2 via Group Policy (and struggling with it due to lack of information in some respects), I'd like to point out some additions to this article which might be useful.

I'd be interested in seeing more on the use of 'Add-On Management' through the use of Group Policy. In a corporate environment for example, it is unlikely that you would want end users being able to enable/disable ActiveX controls on an 'as needs' basis - IMHO this is asking for trouble - therefore, being able to use the 'only allow ActiveX controls in this list' policy setting (which acts like a whitelist) is a good move as this then allows the IT admin to control what can and can't be used.

The problem here is that no where (or at least not so far as I have found) is there a list of standard controls and their Class IDs. Microsoft themselves do not have this information (and I know as I have been through this with PSS!)

Therefore, in order to make use of Add-On Management via Group Policy properly, a lot of donkey work is required with SysInternals 'RegMon' and other tools to try and determine which controls IE is calling when it tries to use certain functionality. Also, some of this info can be found out through looking at the source code of web pages which call such controls (for example, pages which use Flash etc.) This is easiest done by searching for 'CLSID' in the web page source code.

The additional problem here is that so much of IE's core functionality (for example, being able to use VBScript, Javascript, integrated MSN search etc.) is all delivered via ActiveX controls. Thus, enabling 'Add-On Management' and the whitelist via Group Policy immediately means that the vast majority of IE functionality ceases to work!! Hence, the need then for Regmon etc. to work out what is being accessed.

I have thus far put together a list of required ClassIDs which are needed when using Add-On Management and the whitelist via Group Policy, but I firmly believe that Microsoft should have produced this info prior to making SP2 (or at least this feature) more widely available. At the moment, it is very difficult to use properly.

A further comment about the article - the article states that enabling or 'trusting' the control of one manufacturer automatically trusts all other controls from the manufacturer.

This is certainly NOT the case if using the 'Add-On Management' whitelist via Group Policy. All specific ClassIDs have to be added. For example, if I enable Macromedia Flash by adding its ClassID to the whitelist, this does NOT automatically make Shockwave also work (and thank goodness for that, I say!!)

With Add-On Management enabled, there are some additional columns which can be turned 'on' in the 'Add-On Management' window which can be useful, especially when determining what ActiveX control ClassID to add to the whitelist (of using Group Policy to control ActiveX etc.) By right-clicking on any of the column headings in the Add-On Management window, a number of other columns can also be added. These include 'Class ID' and last accessed time as well as statistics as to how often a control has been used - these can all be very useful.

Finally, a number of core Microsoft controls do not show up in Add-On Management when blocked (although the 'ActiveX blocked' icon in the IE status bar or the Information Bar does appear.) This makes troubleshooting very difficult. Such controls which do this are those that enable VBScript and Javascript functionality for example.

Nice to see a non-MS article on use of the 'Add-On Management' feature, but I'd like to see more detail (i.e. lists of ClassIDs and use of this via Group Policy) in a later article if possible.



Collapse -

Precipitation on Parade

by Tony Hopkinson In reply to ActiveX and XP SP2

Class IDs are installation specific. So they can change if they are updated, re-installed and will change if they are served from another machine (they are built from the MAC address). So you are going to be going through this exercise on a regular basis.
On a machine with a network card they are guaranteed to be unique, they are not guaranteed to be the same each time they are installed on the same machine and definitely not on another.

Collapse -

I have an umbrella.....

by mark In reply to Precipitation on Parade


You are correct for some instances - yes, ClassIDs are installation specific.

In terms of ActiveX controls (and other 'legitimate' IE plugins which use the ClassID system), this is not the case.

For example, {D27CDB6E-AE6D-11CF-96B8-444553540000} is the ClassID of the Macromedia Flash Player plugin. This ClassID is referenced on any web page which contains Flash content - so that IE knows which plugin is being used and can therefore check to see if it has the plugin and launch the content using the correct plugin. If it does not have the plugin (i.e. because the ClassID does not exist in the Registry), then it uses the CODEBASE command (also present on the web page) to determine the URL it needs to download the plugin from.

If you think about it, this has to be the case for plugins used by IE. If the ClassIDs were randomly generated, how would web developers and their ilk know how to reference the correct plugin on a web page?

Back to Security Forum
14 total posts (Page 1 of 2)   01 | 02   Next

Related Discussions

Related Forums