views:

49

answers:

1

We are developing a .NET plug in (class library) for an existing application within our enterprise. Its a desktop application which has preexisting support for plug ins.

1) Is there a mechanism to secure the plug in to ensure that it is only invoked by the existing desktop application? (We have no control over the desktop applications codebase)

2) Is there a method to stop malicious users disassembling the codebase (aside from obfuscation) and / or invoking methods regardless of their visibility? I understand we could use authentication / authorisation in the appropriate places but was wondering if there was an alternative.

3) Whats the standard mechanism for encrypting sensitive data within a plug ins configuration files?

+1  A: 
  1. You could look into some type of digital signing or public/private key exchange between the plugin and the application. However protecting the private key would be almost impossible unless you use some sort of online authentication, where the private key never leaves your servers.

    For a less secure approach you could use the Assembly.GetEntryAssembly() method in your plugin to get the details of the .NET executable that is calling your plugin. Then, for instance, if the entry assembly name is not what you expect, stop.

  2. Not really, in fact .NET actually provides mechanisms such as Reflection that make disassembly simple. Obfuscation is the "best" approach in .NET although it will not stop more determined / skilled hackers. You could look to ngen your assemblies to native code, however this really defeats the purspose of using .NET in the first place as your code becomes tied to a specific platform. Native code can also be disassembled of course.

  3. Look into the ConfigurationManager classes and the SectionInformation.ProtectSection() method and DataProtectionConfigurationProvider provider.

Ash