VB: get compiled DLL's calling application info; COM security

Through COM, one can potentially gain absolute control over a target system. For example: using javascript's ActiveXObject object in IE, one can create certain objects which were designed to have direct access or interaction with system properties and files. One would think common sense dictates users disable ActiveX features in IE immediately after installing the browser to ensure their system is protected while surfing the net, or at least paying close attention to which websites they permit. But, I doubt many average PC users know how or why to do this, or just get tired of mirco-managing it over time. I think any PC user or admin my COM class caters to would greatly appreciate not having to deal with that. Thankfully it looks like IE versions come packaged with ActiveX disabled by default nowadays.

I've built a very versatile COM class library in VB. I didn't intend for it to be callable from any website, but that feature is just part of the COM platform. I'd like to prevent the library from being called from IE unless the website is on a white-listed domain to proactively protect the user (and ultimately their entire intranet) from harm from malicious websites. What would be the best method in VB.Net to tell which application called my DLL, to be able to tell if it was called from any command or process originating from IE? And, what domain called my dll?

Edit: I believe this might be a duplicate. See: http://stackoverflow.com/questions/470020/calling-assembly-to-get-application-name-vb-net

System.Environment.GetCommandLineArgs()(0) gets me the calling application path. With this info, I can compare it to a black/white-list of applications. Problem solved for now.

@Slaks: Not sure what you mean, "Don't mark the control as Safe for Scripting." My com class isn't really meant for calling from the internet, it's just that it can be. This is what I need to find a way to control from within the VB.Net library itself.

bob-the-destroyer 2010-10-15 01:46:08

@Slaks: briefly checked out IObjectSafety - but I actually really do not want this COM class callable over the internet, even if the user explicitly allows it. I'd make an exception likely by some registry key an administrator can set to bypass my arbitrary blocking, but for regular users, no.

bob-the-destroyer 2010-10-15 02:09:22

It means that you *have* to mark your control before any script under IE can access it. Unless you explicitly marked it, your users are safe. For now.

wqw 2010-10-15 15:44:42

@wqw: users can still allow it by lowering zone security levels.

bob-the-destroyer 2010-10-15 19:18:14

@bob: If the user lowers security levels, malicious code will just use FileSystemObject. Once you are as secure as FileSystemObject, you're done.

SLaks 2010-10-15 19:21:55

@SLaks: luckily there's almost 0 chance my code has been installed on anyone's system, and even less of a chance an attacker has ever heard of it. Still, it's not safe to have this thing accessible by IE.

bob-the-destroyer 2010-10-15 19:38:57

@bob: If it's accessible by IE, FSO is also accessible. Once FSO is accessible, the attacker doesn't need your object; he can use FSO to replace every EXE file on the system.

SLaks 2010-10-15 19:53:48

@SLaks: that shifts the guilt and blame off me knowing there's almost 0 chance my library was used as the attack vector. Still, I'd rather implement some extra precautions.

bob-the-destroyer 2010-10-15 20:19:09

@bob: Your time would be better spent making more useful improvements, such as documentation.

SLaks 2010-10-15 20:35:00

@SLaks: Security is nothing to dismiss. IMHO: make it secure or don't publish it under official releases. Being able to use the FSO class is great for a file-upload manager. But I'm sure folks who's PC's were turned into zombies or had their HD wiped by any COM class wish its authors were a little more security conscious.

bob-the-destroyer 2010-10-16 03:01:03

ansaurus

tags:

views:

answers:

VB: get compiled DLL's calling application info; COM security

related questions