Print

Error Handling

Introduction

  • The performance of a site should be measured not only by how well it works but also by how gracefully it fails. While developers need error messages in debugging, viewers of site should be shielded from these technical errata which would create confusion. 
  • If an error page has to be displayed (e.g., 404), the retuned error page should maintain the look and feel of the site and provide the developer with accurate information about the error.
  • Error messages are probably one of the most useful places to find information when attacking a Web application.  At the same time, error tracking provides an important way to examine attack paths and vectors.

Error Exceptions

  • When errors happen, an exception is raised or thrown.  ASP.NET throws error messages around the source line that caused the error, a stack trace of the application, the version of ASP.NET, and the location of the files.
  • The Exception class handles information about the error. 
  • There are two different ways to handle errors:
    • Redirecting the user to an error page when errors go unhandled: page level and application level
    • Handling exceptions when they get thrown: try-catch-finally block, page level, and application level.

Error Page Redirect

  • Page level: use the errorPage attribute in the webform. This attribute defines the page the user should be redirected to when an unhandled exception occurs in that specific page. 
    <%@ Page language="vb" Codebehind="Default.aspx.vb" AutoEventWireup="false"  Inherits="Website.Default" errorPage="/Website/ErrorPages/PageError.html"%>
  • Application level: Use the customErrors section in web.config. The mode attribute specifies whether to show pre-defined custom error pages or the default ASP.NET error pages. Three values are supported for this attribute:
    • RemoteOnly - Custom error pages are shown for all remote users. ASP.NET error pages with rich error information are displayed only for local users/developers.
    • On - Custom error pages are always shown, unless one is not specified. When a custom error page is not defined, an ASP.NET error page will be displayed.
    • Off - Custom error pages are not shown. Instead, the default ASP.NET error pages will be displayed.
      <system.web>
          <customErrors mode="On" defaultRedirect="~/error.aspx">
              <error statusCode="404" redirect="~/notfound.aspx" />
              <error statusCode="500" redirect="/error.aspx"/>
          </customErrors>
      </system.web>
    • The major drawback of the redirect is that the conditions leading to the error have no record of what caused the application error.
    • Showing "403" error would have a security concern with informing the user that the resource they dont have access to, does indeed exists.

Handling Errors

  • There are three layers at which you may trap and deal with an exception: 
    • The try-catch-finally block
    • Page level: The page class has an error event that is fired when an un-handled exception occurs within a page.
      Sub Page_Load(ByVal src As Object, ByVal args As EventArgs)
          Throw New ApplicationException("This is an unhandled exception.")
      End Sub

      Sub Page_Error(ByVal src As Object, ByVal args As EventArgs) Handles MyBase.Error    
          Dim e As System.Exception = Server.GetLastError()
          Trace.Write("Message", e.Message)
          Trace.Write("Source", e.Source)
          Trace.Write("Stack Trace", e.StackTrace)
          Response.Write("Sorry, an error was encountered.")
          Context.ClearError()
      End Sub
    • Application level:
      • When events are fired at the application level, the error can be handled and stored into a shared class property for later use. This is done by using the Application_error handler in the Global.asax file.
      • Never set customErrors to off in the web.config file if there is no Application_Error handler in your Global.asax file.
        • Errors can be displayed and stored in a log file.  Alert email can be sent.
          Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
              Dim objErr As Exception = Server.GetLastError().GetBaseException()
              Dim err As String = "Error in: " & Request.Url.ToString() & ". Error Message:" &
                  objErr.Message.ToString()
          End Sub

          Dim mail As New System.Net.Mail.MailMessage()
          Dim ErrorMessage As String = "The error description is as follows : "
          mail.[To].Add(New MailAddress("myemail@email.com"))
          mail.Subject = "Error in the Site"
          mail.Priority = MailPriority.High
          mail.Body = objErr.Message.ToString()
          Dim client As New SmtpClient()
          client.Send(mail)

3rd Party Error Handling

Exceptions for Potential Threats

  • HttpRequestValidationException: Potential threatening characters are sent with a request when the request validation is set to true.
  • ArgumentException: Attempt to fire an event that is not threatening a page. 
  • ViewStateException: Invalid ViewState has been sent.

Disabling Browser Caching

  • A browser may cache a page on the client side. This cached copy of a page can be read by spyware or other software running on the users machine. If this is a concern, the caching can be turned off by using the OutputCache directive on a page:
    < %@ OutputCache Location="None" VaryByParam="None" %>
    Or, in the Page_Load event:
    Response.Cache.SetCacheability(HttpCacheability.NoCache)

Tracing

  • ASP.NET tracing enables the web developer to view detailed diagnostic information about a single request for an ASP.NET page and a page's execution path at run time for the purpose of debugging. Sensitive information items presented in the trace include data stored in session, application states, and server variables.
  • Tace information can be viewed at the bottom of individual pages by adding the trace element in the web.config file.
  • Tace information can be viewed by running the trace viewer Trace.axd.
  • Inside the trace element, there are the following parameters:
    • enabled="true" - allowing the trace information to be produced and displayed
    • pageOutput="true" - adding the trace information at the bottom of the .aspx page
    • requestLimit="20" - specifying the number of requests to be saved on the server
    • localOnly="false" - making the tracing information be available to any web page
    • mostRecent="true" - determining whether or not to display the recent trace information if the request reached the limit
  • Tutorials:
  • Defense: remove the trace element in the web.config file or set enabled to "false".