.NET Framework 1.1 Security Guidelines - Exception Management

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan


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.

  // Code that could throw an exception
catch (SomeExceptionType ex)
  // Code to handle the exception and log details to aid
  // problem diagnosis
  // 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 Pages and Controls." at http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh10.asp

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()
     // (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
     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
   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.

A solution to this issue is to use a catch block in your SomeMethod method to handle exceptions and to prevent exceptions from propagating. Preventing the exception from propagating from the catch block ensures that exception filter code higher in the call stack does not execute.

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.

Personal tools