Post date: Mar 18, 2011 12:24:36 PM
Secure exception handling can help prevent certain application-level denial of service attacks, and can also prevent valuable system-level information useful to attackers from being returned to the client. For example, without proper exception handling, information such as database schema details, operating system versions, stack traces, file names and path information, SQL query strings, and other information of value to an attacker can be returned to the client. Table 8 shows possible vulnerabilities and their implications that can result from poor or missing exception management.
Table 8: Exception Management Vulnerabilities and Implications
Vulnerability
Failing to use structured exception handling
Revealing too much information to the client
Implications
The application is more susceptible to denial of service attacks and logic flaws, which can expose security vulnerabilities.
An attacker can use the information to help plan and tune subsequent attacks.
The following questions can help you to identify vulnerable areas:
Does the code handle errors and exception conditions?
Does the code use a global error handler?
Does the code leak sensitive information in exceptions?
Does the application expose sensitive information in user sessions?
Does the application fail securely in the event of exceptions?
Does the code handle errors and exception conditions?
Use structured exception handling and catch exception conditions. Doing this improves robustness and avoids leaving the application in an inconsistent state that may lead to information disclosure. It also helps protect the application from denial of service attacks. The code should use finally blocks to ensure that resources are cleaned up and closed even in the event of an exception condition. Developers should determine how to propagate exceptions internally in their code and give special consideration to what occurs at the application boundary.
The application should not contain code similar to the following example.
// Write to a new file
StreamWriter sr = File.CreateText(FILE_NAME);
sr.WriteLine ("This is my file.");
sr.WriteLine ("I can write ints {0} or floats {1}, and so on.", 1, 4.2);
sr.Close();
Instead, the application should contain code similar to the following.
// Write to a new file
if (File.Exists(FILE_NAME))
{
// Error Condition
logToFile("{0} already exists.", FILE_NAME);
}
else
{
// Exception handling
try
{
StreamWriter sr = File.CreateText(FILE_NAME);
sr.WriteLine ("This is my file.");
sr.WriteLine ("I can write ints {0} or floats {1}, and so on.", 1, 4.2);
sr.Close();
}
catch
{
...
throw;
}
finally
{
// resources cleanup
}
}
Does the code use a global error handler?
Make sure that the code includes an application-level global error handler in Global.asax to catch any exceptions that are not handled in code. This can prevent accidentally returning detailed error information to the client. The code should log all exceptions in the event log to record them for tracking and later analysis.
The application should contain code similar to the following:
<%@ Application Language="C#" %>
<%@ Import Namespace="System.Diagnostics" %>
<script language="C#" runat="server">
void Application_Error(object sender, EventArgs e)
{
// Get reference to the source of the exception chain
Exception ex = Server.GetLastError().GetBaseException();
// log the details of the exception and page state to the
// event log.
EventLog.WriteEntry( "My Web Application",
"MESSAGE: " + ex.Message +
"\nSOURCE: " + ex.Source,
EventLogEntryType.Error);
// Optional e-mail or other notification here...
}
</script>
Does the code leak sensitive information in exceptions?
By default, ASP.NET provides too much detail in error messages. Make sure that your application uses custom errors that do not include details that could help an attacker exploit a vulnerability.
The application should not contain code similar to the following example.
<customErrors mode="Off" />
Instead, the application should contain code similar to the following.
<customErrors mode="On" defaultRedirect="ErrorPage.htm">
<error statusCode="404" redirect="NotFoundPage.htm"/>
<error statusCode="500" redirect="InternalErrorPage.htm"/>
</customErrors>.
Does the application expose sensitive information in user sessions?
Review the type of information that could be revealed to an attacker if he or she obtained a session ID. In ASP.NET applications, the session ID is properly randomized so that it is hard to guess session IDs. However, there are other ways an attacker can get this information. Make sure that the session ID is sent over SSL, and make sure that the session timeout is short.
Does the application fail securely in the event of exceptions?
Does the application implement proper exception handling?
The following code example fails l to implement exception handling.
// Code within a System.Web.UI.Page
override protected void OnInit(EventArgs e)
{
...
base.OnInit(e);
}
Instead, it should implement page-level or application-level error handlers, as shown in the following example.
// CODE within a ASP.Net Page
override protected void OnInit(EventArgs e)
{
...
this.Error += new System.EventHandler(this.Page_Error);
base.OnInit(e);
}