Limit Who Uses Your Code

Limit Who Uses Your Code

It might be unsuitable for arbitrary untrusted code to call some of your methods. For example, the method might provide some restricted information, or for various reasons it might perform minimal error checking. Managed code affords several ways to restrict method access; the simplest way is to limit the scope of the class, assembly, or derived classes. Note that derived classes can be less trustworthy than the class they derive from; after all, you do not know who is deriving from your code. Do not infer trust from the keyword protected, which confers no security context. A protected class member is accessible from within the class in which it is declared and from within any class derived from the class that declared this member, in the same way that protected is used in C++ classes.

You should consider sealing classes. A sealed class Visual Basic uses NotInheritable cannot be inherited. It's an error to use a sealed class as a base class. If you do this, you limit the code that can inherit your class. Remember that you cannot trust any code that inherits from your classes. This is simply good object-oriented hygiene.

You can also limit the method access to callers having permissions you select. Similarly, declarative security allows you to control inheritance of classes. You can use InheritanceDemand to require that derived classes have a specified identity or permission or to require that derived classes that override specific methods have a specified identity or permission. For example, you might have a class that can be called only by code that has the EnvironmentPermission:

[EnvironmentPermission (SecurityAction.InheritanceDemand, Unrestricted=true)] public class Carol {  } class Brian : Carol {  }

In this example, the Brian class, which inherits from Carol, must have EnvironmentPermission.

Inheritance demands go one step further: they can be used to restrict what code can override virtual methods. For example, a custom permission, PrivateKeyPermission, could be demanded of any method that attempts to override the SetKey virtual method:

[PrivateKeyPermission (SecurityAction.InheritanceDemand, Unrestricted=true)] public virtual void SetKey(byte [] key) { m_key = key; DestroyKey(key); }

You can also limit the assembly that can call your code, by using the assembly's strong name:

[StrongNameIdentityPermission(SecurityAction.LinkDemand, PublicKey="00240fd981762bd0000...172252f490edf20012b6")]

And you can tie code back to the server where the code originated. This is similar to the ActiveX SiteLock functionality discussed in Chapter 16, Securing RPC, ActiveX Controls, and DCOM. The following code shows how to achieve this, but remember: this is no replacement for code access security. Don't create insecure code with the misguided hope that the code can be instantiated only from a specific Web site and thus malicious users cannot use your code. If you can't see why, think about cross-site scripting issues!

private void function(string[] args) { try { new SiteIdentityPermission( @"*.explorationair.com").Demand(); } catch (SecurityException e){ //not from the Exploration Air site } }