Geeks With Blogs
Blog Moved to http://podwysocki.codebetter.com/ Blog Moved to http://podwysocki.codebetter.com/
In previous days, I talked about many other ways to write a secure application.  Today I will cover exception management and handling as it pertains to application security.
 
When dealing with Exceptions, it's a best practice to hide the implementation details of your applications from the user.  This includes hiding information regarding implementation, any secure data, and system configuration.  
 
To provide a secure application with regards to exception handling:
*  Use a structured exception handling routine
*  Do not log potentially sensitive information
*  Do not reveal implementation details or secure information to the user
*  Consider an exception management framework
 
Use a structured exception handling routine
The .NET framework gives you the ability to do structured exception handling by using the try, catch and finally keywords.  Place code that can fail inside try blocks and use the catch blocks to handle the exceptions.  Inside the catch blocks, you may do additional logic such as logging.  Use the finally block to clean up any resources such as SQL connections or IO readers even if the catch block was reached.  Use exceptions instead of returning an integer much as you would with COM and C++ functions. 
 
Below is an example of a good try-catch-finally block:
SqlConnection conn = null;
try
{
     conn = new SqlConnection(myConnString);
     conn.Open();
}
catch(SqlException se)
{
     // Log Exception and do other handling
}
finally
{
     if(conn != null) conn.Dispose();
}
 
Do not log potentially sensitive information
Exception messages and other exception details could reveal potentially sensitive information such as user passwords.  When creating a logging policy for your organization, be conscious of what data will be logged and act accordingly.  It can be a very fine line between not providing enough information to diagnose a problem and revealing too much information in the logs.
 
This could be an example of not logging sensitive information:
try
{
     LoginUser(userName, password);
}
catch(SecurityException se)
{
     // Log user name that failed, but not password
     logger.LogEvent(string.Format(CultureInfo.CurrentCulture, "Access denied for user {0} at {1}", userName, DateTime.Now));
}
 
Do not reveal implementation details or secure information to the user
Another rule of thumb is to not show too much information to the user.  It is a best practice to log the details of the exception and return a more friendly exception message back to the user.  When using ASP.NET applications, it is best to use the <customErrors> element within the Web.config to show generic failures to the user.
 
The information that should not be displayed to the user include any of the following:
*  Method names
*  Machine names
*  .NET framework version numbers
*  SQL Statements
*  Connection strings
*  Other configuration items
 
Consider an exception management framework
In the enterprise architecture world, it is best to use an exception management framework.  The Microsoft Patterns & Practices group released a best practices guide for exception handling here:  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/exceptdotnet.asp
 
The Microsoft Enterprise Library contains the Exception Handling Application Block which allows the implementer to create a strategy for exception handling throughout the enterprise.
 
The Exception Handling Application block allows the implementer to create a strategy in the following ways:
*  Support exception handling in all layers instead of the service interface entry points
*  Exception handling policies can be created and maintained at an administrative level
*  It allows for easy wrapping of certain exceptions to hide the details while logging the exception
*  It invokes exception handlers in a consistent fashion
 
More information about this block can be found at the link above and all of its functionality.  As this blog continues, I will add more strategies for securing the enterprise application.
 
 
 
Posted on Monday, May 22, 2006 11:10 AM Microsoft , .NET , Windows , C# , ASP.NET | Back to top


Comments on this post: .NET Security - Exception Management

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


Copyright © Matthew Podwysocki | Powered by: GeeksWithBlogs.net