Exception Management

Do not reveal implementation details about your application in exception messages returned to the client. This information can help malicious users plan attacks on your application. To provide proper exception management:

• Use structured exception handling .

• Do not log sensitive data .

• Do not reveal system or sensitive application information .

• Consider exception filter issues .

• Consider an exception management framework .

Use Structured Exception Handling

Microsoft Visual C# and Microsoft Visual Basic .NET provide structured exception handling constructs. C# provides the try / catch and finally construct. Protect code by placing it inside try blocks and implement catch blocks to log and process exceptions. Also use the finally construct to ensure that critical system resources such as connections are closed irrespective of whether an exception condition occurs.

 try {    // Code that could throw an exception } catch (SomeExceptionType ex) {    // Code to handle the exception and log details to aid    // problem diagnosis } finally {    // This code is always run, regardless of whether or not    // an exception occurred. Place clean up code in finally    // blocks to ensure that resources are closed and/or released. } 

Use structured exception handling instead of returning error codes from methods because it is easy to forget to check a return code and as a result fail to an insecure mode.

Do Not Log Sensitive Data

The rich exception details included in Exception objects are valuable to developers and attackers alike. Log details on the server by writing them to the event log to aid problem diagnosis. Avoid logging sensitive or private data such as user passwords. Also make sure that exception details are not allowed to propagate beyond the application boundary to the client as described in the next topic.

Do Not Reveal Sensitive System or Application Information

Do not reveal too much information to the caller. Exception details can include operating system and .NET Framework version numbers , method names, computer names , SQL command statements, connection strings, and other details that are very useful to attackers. Log detailed error messages at the server and return generic error messages to the end user.

In the context of an ASP.NET Web application or Web service, this can be done with the appropriate configuration of the <customErrors> element. For more information, see Chapter 10, "Building Secure ASP.NET Web Pages and Controls."

Consider Exception Filter Issues

If your code uses exception filters, your code is potentially vulnerable to security issues because code in a filter higher up the call stack can run before code in a finally block. Make sure you do not rely on state changes in the finally block because the state change will not occur before the exception filter executes. For example, consider the following code:

 // Place this code into a C# class library project public class SomeClass {   public void SomeMethod()   {     try     {       // (1) Generate an exception       Console.WriteLine("1> About to encounter an exception condition");       // Simulate an exception       throw new Exception("Some Exception");     }     // (3) The finally block     finally     {       Console.WriteLine("3> Finally");     }   } }     // Place this code into a Visual Basic.NET console application project and // reference the above class library code Sub Main()     Dim c As New SomeClass     Try         c.SomeMethod()     Catch ex As Exception When Filter()         ' (4) The exception is handled         Console.WriteLine("4> Main: Catch ex as Exception")     End Try End Sub     ' (2) The exception filter Public Function Filter() As Boolean     ' Malicious code could do something here if you are relying on a state     ' change in the Finally block in SomeClass in order to provide security     Console.WriteLine("2> Filter")     Return True ' Indicate that the exception is handled End Function 

In the above example, Visual Basic .NET is used to call the C# class library code because Visual Basic .NET supports exception filters, unlike C#.

If you create two projects and then run the code, the output produced is shown below:

 1> About to encounter an exception condition 2> Filter 3> Finally 4> Main: Catch ex as Exception 

From this output, you can see that the exception filter executes before the code in the finally block. If your code sets state that affects a security decision in the finally block, malicious code that calls your code could add an exception filter to exploit this vulnerability.

Consider an Exception Management Framework

A formalized exception management system can help improve system supportability and maintainability and ensure that you detect, log, and process exceptions in a consistent manner.

For information about how to create an exception management framework and about best practice exception management for .NET applications, see "Exception Management in .NET" in the MSDN Library at http://msdn.microsoft.com/library/en-us/dnbda/html/exceptdotnet.asp .