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
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.