8

I want to restrict other application from using dll functions that I have written.

Eg. If i hav database.dll containg two functions.

public void InsertInToDatabse();
public void ClearDatabase();

Now If my application has called InsertInToDatabse() and is doing some other work,till this time if some other application calls ClearDatabase() by referencing database.dll , The databse would be cler out.So how can I restrict calls to these functions form third party application ?

NIlesh Lanke
  • 1,213
  • 9
  • 26
  • 35
  • 1
    Possible duplicate of [Secure C# Assemblies from unauthorized Callers](http://stackoverflow.com/questions/2806842/secure-c-sharp-assemblies-from-unauthorized-callers). [This answer](http://stackoverflow.com/a/2807142/69809) has some nice insights. – vgru Jan 25 '12 at 08:49
  • 1
    The problem is not how to secure your code, the problem is how to secure your database. – Huusom Jan 25 '12 at 08:53
  • Marcus Hansson[ internal void ClearDatabase() ], GazTheDestroyer, Davide Piras ... all of them gaves best suggestions to you. And additional; I can suggest to you, use a good .net obfuscator... – Lost_In_Library Jan 25 '12 at 08:53
  • If they cannot be used from another App. they still can be Decompiled ,so protect you're Connection String or use a Web Service or WCF. – Rosmarine Popcorn Jan 25 '12 at 09:24

6 Answers6

2

if your dll is a class library the actual configuration file will be the one of the client application (web.config or app.exe.config) and in there only authorized applications will have proper connection string with username, password, db server and db name.

Now, even if unauthorized apps would be prevented to call you dll's methods in the way you are looking for, in case those bad apps have direct access to the database by knowing the connection string, they can still mess around.

this would to say that in fact as long as the configuration is outside your dll you shouldn't worry because only authorized apps will be accessing the proper database.

if this approach still does not satisfy you, then you should be using security check like CAS which allows you to specify which class or assembly can be calling a certain method so even if your dll is referenced by another application it won't work. Beware that in .NET 4 (you tagged it in the question) the whole security layer has been changed and works differently from older .NET Framework versions, check this article for more details: http://msdn.microsoft.com/en-us/library/dd233103.aspx

Davide Piras
  • 43,984
  • 10
  • 98
  • 147
1

You cannot stop people from calling your functions, but you are free to implement your functions to protect against such circumstances.

For instance, you could put a lock around database accesses so that the call blocks until the previous call has finished, or you could have a flag that causes the Clear() call to return immediately with an error code or exception.

EDIT: I may have misunderstood the question. If you NEVER want third party code to call your functions then use internal (and/or InternalsVisibleTo) as Marcus suggests.

GazTheDestroyer
  • 20,722
  • 9
  • 70
  • 103
1

If I remember correctly, the internal keyword is for exactly these types of situations.

Edit: As said in comments, if class A is in assembly B, then class C in assembly D won't have access to A.

Also, as pointed out in other answers, you can (and probably should) have some form of authentication in the ClearDatabase().

Edit 2: It just dawned on me that these sort of permissions should be on a database-level, which means that if the following user (with those privileges):

A: Insert, Update, Create

tried to Drop Table, then the application would throw an exception (or however you handle errors), which, obviously, would prevent them from just doing that.

This is not to say that you shouldn't set ClearDatabase() as internal, but if the user (the third-party is using) has permissions to Drop Table then s/he would be able to regardless.

Edit 3:

The problem is not how to secure your code, the problem is how to secure your database.

– Huusom
Marcus Hansson
  • 816
  • 2
  • 8
  • 17
  • no, internal prevent the method to be called from other assemblies and if he has a two assembly application like the dll he mentioned and an exe, the exe cannot call internal methods of the class library. – Davide Piras Jan 25 '12 at 08:51
  • 1
    Well, there's ILMerge. But you're right, I should probably edit my answer! – Marcus Hansson Jan 25 '12 at 09:21
1

You could use internal access on the methods you want to protect (instead of public), then mark your projects as Friend Assemblies. This is the same way you allow unit test projects to access internal methods.

Here's a description from MSDN's Friend Assemblies article...

Only assemblies that you explicitly specify as friends can access Friend (Visual Basic) or internal (C#) types and members. For example, if assembly B is a friend of assembly A and assembly C references assembly B, C does not have access to Friend (Visual Basic) or internal (C#) types in A.

David J
  • 659
  • 1
  • 9
  • 25
1

As Marcus mentioned you could use the internal keyword. And then apply the InternalsVisibleToAttribute to your class library with the assemblyname of your application assembly and your public key if you are using strong assemblynames.

MSDN link

Kolja
  • 2,307
  • 15
  • 23
1

If you're asking about security: Another technique would be to make the client pass in a parameter, such as a password or an encrypted connection string for example.

If you're asking about restriction by caching (eg. only allow this method to be called once every minute) - then look at either [AspNetCacheProfile] for services or Cache.Insert for application code.

Paul
  • 1,483
  • 14
  • 32
  • From your title and tags, its a security question, but i added the extra info because your question seems to infer two applications are using the dll. – Paul Jan 25 '12 at 09:20