Geeks With Blogs
Blog Moved to http://podwysocki.codebetter.com/ Blog Moved to http://podwysocki.codebetter.com/
As secure developers, we must take into account our class designs.  We need to reduce the attack surface available to potential to attackers.  We can do this by limiting inheritance, and limit users or groups or even code that can call the secure code. 
 
Today we will concentrate on five major topics:
*  Limit class or member visibility
*  Seal non-base classes
*  Restrict callers of your code
*  Restrict inheritance with keys
*  Limit the set modifier on properties
 
Limit class or member visitbility
When it comes to limiting the class or member visibility, use public only when it conforms to your public contract.  For example, there should be no need to expose a class that holds resource messages publicly.  Use the internal modifier when your class when it does not need exposure outside of the current assembly.  An example of this would be:
internal class ResourceMessageManager { ... }
 
Also, keep in mind the same applies to methods and properties as well.  Only expose methods and properties that conform to the public contract.  An example of this would be the following:
protected ArrayList InnerList { get { return innerList; } }
 
Seal non-base classes
The best practices for .NET state that by default, your classes should not be sealed.  Seal the class if it contains security key information that you do not wish the outside to inherit.  An example of this could be:
public sealed class SecureDataAccess
{
     internal string SecurityKey { get { return securityKey; } }
}
 
Restrict callers of your code
In order to restrict the callers of your code, you can enforce this by using the PrincipalPermission attribute.  This allows the implementer to demand that the caller must be either a certain user or a certain role in order to call the class.  An example of this could be the following:
[PrincipalPermission(SecurityAction.Demand, Role=@"BUILTIN\Administrators")]
public class AdminDataAccess { ... }
 
Another way to restrict which callers can access your code with partial-trust is to demand that the caller is signed with an expected strong name key.  An example of this follows:
[StrongNameIdentityPermission(SecurityAction.LinkDemand, PublicKey="0084...1e22")]
public class KeyedDataAccess { ... }
 
Restrict inheritance with keys
When dealing with partially trusted assemblies, you can also restrict the inheritance of your base class with the StrongNameIdentityPermissionAttribute.  By using this attribute, you can specify the strong name key that the inheriting class must have.  An example of this is the following:
[StrongNameIdentityPermission(SecurityAction.InerhitanceDemand, PublicKey="0084...1e22")]
public class RestrictedDataAccess { ... }
 
Limit the set modifier on properties
As a design pattern, you should not have fields as public members unless they are readonly or constants.  If they are not, they should be properties.  Also, in certain instances, you may also want to restrict the set modifier as well.  This feature is new to .NET 2.0 as you can modify the access modifier to restrict how the property can be set.  In previous releases of .NET, you had to create a separate method with the different access modifier.  Here is what you had to do in previous releases:
public string AccessKey { get { return accessKey; } }
internal void SetAccessKey(string value) { .. }
 
This has been imrpoved so that you can do it this way:
public string AccessKey
{
     get { return accessKey; }
     internal set { accessKey = value; }
}
 
You may also want to restrict the property set modifier by using the PrincipalPermissionAttribute to restrict the roles that can set the property.  Here is how you would accomplish that:
public string AccessKey
{
     get { return accessKey; }
     [PrincipalPermission(SecurityAction.Demand, Role=@"BUILTIN\Administrators")]
     set { accessKey = value; }
}
 
Next time I will cover more security design features to keep in mind for building secure applications.
Posted on Saturday, May 20, 2006 8:17 PM .NET , Windows , C# | Back to top


Comments on this post: .NET Code Access Security - Class Design Considerations

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Matthew Podwysocki | Powered by: GeeksWithBlogs.net