Implement a method / parameterized property on GeckoActivex that allows JS to determine whether a control is supported in Mozilla. For example, if (GeckoActiveXObject.supports("814ba433-a816-4785-9f95-ad3ba0a43dab") document.write("<object> etc."); else alert("Boo hoo no support for my object!"); Note that making this take a useful form while respecting privacy / security issues might be problematic. For example, supports(clsid) should certainly not say whether the control is installed (otherwise someone could probe every clsid on the system), but just whether the current policy allows that control to be instantiated assuming it were installed. Also, the method should not supports progids, since the impl would have to look up the progid in the registry to determine the clsid. A clever attacker could probe for progids and still perhaps figure out what is installed and what is not based the answers returned. For example, if "Foo.SomeObject.1" maps to "814ba433-a816-4785-9f95-ad3ba0a43dab", an attacker could call GeckoActiveX.supports("Foo.SomeObject.1") and GeckoActiveX.supports("814ba433-a816-4785-9f95-ad3ba0a43dab"). If the first call failed but the second succeeded I would know that "Foo.SomeObject.1" is not installed because the progId lookup failed, but the clsid lookup succeeded, meaning the current policy allows it so its not because of that.
Good points Adam, I hadn't thought about the prog id and class id testing trick. I wonder if that's going to be a problem for anyone? We support instantiating via a prog id. Only allowing this check via class ID seems a little odd, but maybe that's the price of security.
Thought I had already targetted this, ->1.5a
I've been waffling on whether supports should ask the object whether it is safe for scripting. Initially I really didn't want supports to instantiate the object, but that would mean that the results for supports and GeckActiveXObject("xxx") would be different and that didn't seem good either. So I'm looking for some feed back on what others think is the appropriate approach.
If you instantiate the object, and it is hostile, it could cause havoc at that point. Of course, if the object was hostile the installation probably would have caused harm as well.
Here is some info about the methods that the clientCaps behaviour exposes on any element given that style http://msdn.microsoft.com/workshop/author/behaviors/reference/methods/getcomponentversion.asp http://msdn.microsoft.com/workshop/author/behaviors/reference/methods/iscomponentinstalled.asp Importantly, the documentation says that only certain clsids are detectable using these methods. http://msdn.microsoft.com/workshop/author/behaviors/reference/methods/detectable.asp This suggests that other clsids are prevented deliberately to prevent 'sniffing' a big long list to see what might be on the machine. Perhaps we need to restrict ourselves in the same way, using the whitelist perhaps, or a hardcoded list in blacklist mode. IE might even store these 'detectable' clsids somewhere in the registry where they can be read.
Created attachment 125352 [details] Sample clientCaps I grabbed this from the web. Load it in IE. I'm fairly sure that clientCaps will only report back on CLSIDs that it finds in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components and possibly under HKEY_CURRENT_USER too.
Heikki, yes that was my concern as well. And I was trying to weigh that against parity between GeckoActiveXObject("xxx") and GeckoActiveXObject.supports("xxx"); But the instantiation is only the last part, and only occurs if all the other checks succeed. It also makes supports a heavier function to call as well. Adam, I wonder, will IE instantiate a component if it's not in Installed Components? By default ActiveX/COM objects create an entry here (at least the ones I built). But maybe that's a reasonable requirement for controls being used on the web. So, should an item on the white list that isn't in this list be disallowed? I found the following link: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gp/774.asp but I'm unable to figure out how it works on XP.
In DevStudio 6 at least, controls do not create an entry in this list yet they work fine in IE without warnings when they implement IObjectSafety. So I don't believe there is a requirement that they appear here. Not being here might mean they cannot be detected but they can still be instantiated. Other controls, for example the Shutterfly control also do not appear here but work fine in IE. The dumb thing about this list is that it contains stuff which should not be detectable (you would think), such as CLSIDs for various service pack fixes. If restricting the list of CLSIDs is meant to be a security thing, it would seem counterproductive to let a page see what service packs I have applied. I verified that I can see them by modifiying the sample page. But ask it about Shutterfly and it returns nothing. I also tried to figure out what the second sIDType parameter on isComponentInstalled / getComponentVersion is meant to represent. If you pass 'componentId' the docs hint that my assumption of where it is checking is correct (Active Setup). If I just pass in 'clsid' instead, it returns version information but only for the WMP and not the other examples in the test page. I do not know if 'clsid' is a valid arg since the docs are vague, but perhaps it falls back on a hardcoded list when the type is a clsid.
Well, I searched around a bit, unfortunately accidentally shutdown the browser and lost my original comment here along with the various links. So I'll summarize. Some nsIDTypes: http://www.allfreetech.com/ShowMain.asp?MainID=81 Looks like isComponentInstalled takes clsid, ComponentID, progID, mime(not sure of the exact spelling). Also, apparently there's a VBScript isComponentInstalled that returns 0, 1, 2, or 3. denoting if it's installed, a newer version, or the user said don't check. As opposed to true/false of the DHMTL version. Given there is little documentation on this, I think it would probably be best to avoid it for now. It's really probably only useful in black list mode anyway. Given that some embedders might want to use such vendor specific checks or something completely different. I wonder if it would be better to provide an interface to allow vendors to replace our current default vendor specific checks with their own?
Created attachment 125596 [details] [diff] [review] Addes GeckoActiveXObject.supports Ok, this doesn't support the DHTML behaviors. I just don't think that's documented well enough for us to get it close to right. So I'd rather avoid it till it's more well known. We could always add a isComponentInstalled to GeckoActiveXObject if and when that happens. I also chose not to ask the object if it's safe when using GeckoActiveXObject.supports. This sacrifices parity between GeckoActiveXObject() and GeckoActiveXObject.supports(), but makes it a much lighter weight function that if it had to instantiate, ask, and then throw away the object. If anyone can make a strong argument for either of these two issue, I'm open.
Comment on attachment 125596 [details] [diff] [review] Addes GeckoActiveXObject.supports Looking for reviews
I'll review in a moment, but first we definitely don't want to create an object ever just to determine if its safe or not. Creating an Adobe Acrobat, MS Word document, or even an IE browser object is obviously wasteful. This functionality has to compare the clsid to *some* list and possibly additionally say whether its installed or not. The list could be a combination of: 1. Whitelist / blacklist 2. Hardcoded list of clsids 3. Some part of the registry And then finally if it passes whatever of these we test, possibly test if the clsid is even installed. This last step is not acceptable from a security/privacy standpoint if we only test the whitelist/blacklist and its in blacklist mode. And saying we support it is provisional on its object safety and further checks when its actually created. Perhaps the answer for the moment, is supports() does not say whether the control is actually installed or not, just whether Moz would support it if it were (and we're not going to say if it is) and if passes the safe for scripting checks if they're enabled. If later we want to add an isComponentInstalled / getComponentVersion, it can supplement the existing supports behaviour. Personally I think that this would be sufficient for now. And if we add an isComponentInstalled, it can use the hardcoded list that MS documents as an additional filter.
Comment on attachment 125596 [details] [diff] [review] Addes GeckoActiveXObject.supports r=adamlock This implementation seems to make the most sense for now.
Comment on attachment 125596 [details] [diff] [review] Addes GeckoActiveXObject.supports sr=alecf
Patch checked into trunk. Leaving open for possible consideration of the 1.4 branch later.
FYI: I've added GeckoActiveX detection to BrowserSpy http://gemal.dk/browserspy/activex.html
Closing to get off 1.5a radar, though these should still be checked into 1.4 branch.