Missing Custom Error Page

Demonstrations

The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

In the snippet below, an unchecked runtime exception thrown from within the try block may cause the container to display its default error page (which may contain a full stack trace, among other things).

Public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
  try {
    ...
  } catch (ApplicationSpecificException ase) {
    logger.error("Caught: " + ase.toString());
  }
}

Example Two

The mode attribute of the <customErrors> tag in the Web.config file defines whether custom or default error pages are used.

In the following insecure ASP.NET application setting, custom error message mode is turned off. An ASP.NET error message with detailed stack trace and platform versions will be returned.

<customErrors mode="Off" />

A more secure setting is to set the custom error message mode for remote users only. No defaultRedirect error page is specified. The local user on the web server will see a detailed stack trace. For remote users, an ASP.NET error message with the server customError configuration setting and the platform version will be returned.

<customErrors mode="RemoteOnly" />

Another secure option is to set the mode attribute of the <customErrors> tag to use a custom page as follows:

<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />

See Also