Difference between revisions of "Missing Error Handling"

From OWASP
Jump to: navigation, search
(Added contents from Fortify.)
Line 1: Line 1:
 
{{Template:Vulnerability}}
 
{{Template:Vulnerability}}
 +
{{Template:Fortify}}
 +
 +
==Abstract==
 +
 +
A web application must define a default error page for 404 errors, 500 errors and to catch java.lang.Throwable exceptions to prevent attackers from mining information from the application container's built-in error response.
  
 
==Description==
 
==Description==
  
The application doesn't configure a defult generic error page for standard HTTP error codes, such as 404, 500 and java.lang.Throwable exceptions. The containers built-in error response will be returned. These error pages can provide clues to attackers, such as the requested file doesn't exist, or contain detailed information about the application, such as technologies used and their versions.  
+
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. If the application shows the attacker a stack trace, it relinquishes information that makes the attacker's job significantly easier. For example, 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.
 +
 
 +
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.
  
 
==Examples ==
 
==Examples ==
Line 19: Line 26:
  
 
==Categories==
 
==Categories==
 
{{Template:Stub}}
 
  
 
[[Category:Java]]
 
[[Category:Java]]
 
 
[[Category:Deployment]]
 
[[Category:Deployment]]
 
 
[[Category:Environmental Vulnerability]]
 
[[Category:Environmental Vulnerability]]
 
 
[[Category:Error Handling Vulnerability]]
 
[[Category:Error Handling Vulnerability]]

Revision as of 13:16, 21 July 2006

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


This article includes content generously donated to OWASP by Fortify.JPG.

Abstract

A web application must define a default error page for 404 errors, 500 errors and to catch java.lang.Throwable exceptions to prevent attackers from mining information from the application container's built-in error response.

Description

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. If the application shows the attacker a stack trace, it relinquishes information that makes the attacker's job significantly easier. For example, 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.

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.

Examples

  • A "HTTP 404 - File not found" error tells an attacker that the requested file doesn't exist rather than that he doesn't have access to the file. This can help attacker to decide his next step.

Related Threats

Related Attacks

Related Vulnerabilities

Related Countermeasures

Category:Error Handling

Categories