Hello community members,
let's assume that my .NET application is composed of three assembiles, one executable and two libraries. All assembiles communicate through public methods, instantiate public classes and so on.
I want to prevent anybody from simply linking the DLL and using the public functions in his own application, else, anyone could write own frontends for example, and use our backend functions.
What is a common and reliable way to prevent it
For example, i could imagine that my classes might check signatures/strong names of the calling assemblies, but this is just a thought.
I would need more practical sources, examples, instructions....
Thanks for your help!
Thomas
Security: protect public classes and functions in common DLLs?
Hot Topic
- dataset filling from SQL - too cryptic!
- How to get workgroup of the computer?
- date problem
- List<struct>.Contains(struct) - death by GC
- Need some huuuuge help, please!
- How can I move the SQL Server database from local to public web server?
- Sending and Retrieving Data using TCPClient only..
- Copying a XML file from 1 domain to another
- Variables in a sql command
- Application Server Failover
.NET Development
- Formatting Numbers
- Web service request fails with HTTP status 400: Bad Request
- ADO.NET/Access DB Insertion Exception
- How to find all SQL Server Instances over a network from .NET
- ADO/SQLExpress Connection String Question
- XSL,XMl, DHTML Tree (TOC) as per MSDN CodeCorner article April 99
- Accessing data in a DataSet
- DataSet Class Missing
- Adding a shortcut to open a program
- Filtering Illegal Characters from Dynamic Query for MS Access
Security: protect public classes and functions in common DLLs?
Aravindakshan
Wow, I must admit that I seem to lack of knowledge regarding your explaination. I will try to learn. Learn a lot :) My knowledge covers some strong naming basics, but this goes to far for me.
Thicks18
If you want to protect classes in your assemblies from being called by other partially trusted assemblies, then you can use a LinkDemand / InheritenceDemand for StrongNameIdentityPermission on the key that valid callers have. You also might consider making the classes internal and using the InternalsVisibleTo attribute if you're running on v2.0 of the CLR.
Note that in either case, you cannot prevent fully trusted assemblies from calling into your code. In v2.0 of the CLR, FullTrust means FullTrust, and that means that any fully trusted assembly will satisfy your demands for StrongNameIdentityPermission, even if they don't technically have that identity. Although the demands were enforced in v1.x, they were trivial to bypass for a fully trusted caller. If you go the InternalsVisibleTo route, then fully trusted code can use reflection to access your classes.
-Shawn
bbastiaensen
If you read the post that I linked to above about FullTrust means FullTrust Eugene explains some of the reasoning. Basically, although the policy system did enforce all identity demands the way you would expect in v1.x, that could lure you into a false sense of security since fully trusted code could have easily bypassed that in a number of ways.
For instance -- as a FullTrust assembly I can create a new AppDomain, load myself into that domain and supply Evidence that matches your identity demand. Now within that domain, I can easily call your code since I've esentially granted myself that identity.
-Shawn
Hartog
But I dont understand, why "fully trusted assembly will satisfy your demands for StrongNameIdentityPermission, even if they don't technically have that identity" (Quote). I mean, I dont unterstand why this behavior is wanted by the CLR. Looks like Strong Names become more negligible.
mrwillyfog
How do you protect your DLLs from accessing