I'm building an n-tier application with data access, application and UI layers in separate projects and hence separate assemblies.
MyProjectUI.dll
MyProjectApp.dll
MyProjectDataAccess.dll
etc...
The application will eventually be publicly available for download and installed on end-users machines.
How can I protect my middle tier and DAL assemblies from unauthorised access so that a 'clever' user cannot add a reference to one of my separate assemblies and start calling it's public members. Marking members as Internal only works for classes that are 'inside' the same assembly.
Any tips or suggestions would be greatly appreciated.
Protecting Assemblies
Henrik Jensen
Thanks for the post Peter.
Understood.
My goal here is to try and make it 'inconvienient' for someone to add a reference to one of the installed assemblies and start calling its public members - ideally forcing them to decompile/recompile the code into a new assembly - in which case I could repudiate any mal-code behaviour since it would not have come from an assembly containing our public key.
In the end I will probably call a helper method which compares calling and current assembly publickeytokens.
Wassup
Well having done a little research - there are a few things that I can do.
Firstly - on the DAL assembly - I can mark the public methods as 'internal' and then use the "InternalsVisibleTo" attribute to allow my calling assembly access to the internal members. i.e Friend Assemblies.
I can also use the StrongNameIdentityPermission attribute to check the public key of all calling assemblies. Since all my assemblies have strong names - checking the public key is the best way for me to determine that the calling assembly is mine, and not someone else’s.
None of these methods would stop a determined hacker from decompiling the assemblies and recompiling them for their own use, however - there would be a fair bit of work involved and I would be able to repudiate the use of my code since none of the rouge assemblies would contain my public key.
Glider
Anders Jensen
StrongNameIdentityPermission will only work with partial trust assemblies in .NET 2.0+. It does not "work" with FullTrust assemblies because they are FullTrust and not restricted by CAS.
Adding an assembly Demand for FullTrust, if your other assemblies are FullTrust, would accomplish the same thing.
In a normal installation--if the assembly you're worried about is not in the GAC--then another application cannot access your assemblies unless the user installed the other application into the same directory. In a normal situation, if another application has access to your assembly then it must be FullTrust and all restriction methods, but Friend Assemblies, would be circumvented. Even then, Friend Assemblies will only restrict the most naive of hackers, it would do nothing to stop execution via reflection--which is really trivial.
MSatya
If your DLLs are in the same directory as your EXE no other application would normally be able to access them, unless the user has admin rights and installed the other application to the same directory as your application's. If they're installed in the GAC they implicitly have FullTrust, as do other assemblies in the GAC, and would be available to any other FullTrust assembly.
If the user has admin rights or the other application has been given fulltrust by the admin, there's nothing inherent in .NET 2.0 to stop the other application from accessing your DLLs.
If you want to restrict fulltrust assemblies or admin users from accessing your methods, you'd have to either have a unique parameter for every method call that is checked; or design and implement your or code access security class.
adimasi
There's really nothing you can do. If you were to use a password or other token system and add it to all public methods, anyone could use reflector to see how to bypass it anyhow.
ArtT