logo

J2EE Misconfiguration: Missing Custom Error Page

Incomplete Variant
Structure: Simple
Description

The default error page of a web application should not display sensitive information about the product.

Extended Description

A Web application must define a default error page for 4xx errors (e.g. 404), 5xx (e.g. 500) errors and catch java.lang.Throwable exceptions to prevent attackers from mining information from the application container's built-in error response. When an attacker explores a web site looking for vulnerabilities, the amount of information that the site provides is crucial to the eventual success or failure of any attempted attacks.

Common Consequences 1
Scope: Confidentiality

Impact: Read Application Data

A stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.
Potential Mitigations 4
Phase: Implementation
Handle exceptions appropriately in source code.
Phase: ImplementationSystem Configuration
Always define appropriate error pages. The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is useful and user-friendly in addition to being a good security practice, and a good configuration will also define a last-chance error handler that catches any exception that could possibly be thrown by the application.
Phase: Implementation
Do not attempt to process an error or attempt to mask it.
Phase: Implementation
Verify return values are correct and do not supply sensitive information about the system.
Demonstrative Examples 1

ID : DX-76

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

Code Example:

Bad
Java
java
References 2
Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors
Katrina Tsipenyuk, Brian Chess, and Gary McGraw
NIST Workshop on Software Security Assurance Tools Techniques and Metrics • NIST
07-11-2005
https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf
ID: REF-6
19 Deadly Sins of Software Security
M. Howard, D. LeBlanc, and J. Viega
McGraw-Hill/Osborne
26-07-2005
ID: REF-65
Applicable Platforms
Languages:
Java : Undetermined
Modes of Introduction
Implementation
Related Weaknesses
ChildOf: Missing Custom Error Page (CWE-756)
Taxonomy Mapping
  • 7 Pernicious Kingdoms