This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "System Information Leak: Missing Catch Block"
Weilin Zhong (talk | contribs) m (→Examples: formatting change) |
|||
| Line 2: | Line 2: | ||
{{Template:Fortify}} | {{Template:Fortify}} | ||
| − | + | [[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]] | |
| + | |||
| + | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | ||
| + | |||
| + | [[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]] | ||
| + | |||
| + | [[ASDR Table of Contents]] | ||
| + | __TOC__ | ||
| − | |||
==Description== | ==Description== | ||
| + | |||
| + | If a Servlet fails to catch all exceptions, it may reveal debugging information that will help an adversary form a plan of attack. | ||
When a Servlet throws an exception, the default error response the Servlet container sends back to the user typically includes debugging information. This information is of great value to an attacker. 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. | When a Servlet throws an exception, the default error response the Servlet container sends back to the user typically includes debugging information. This information is of great value to an attacker. 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. | ||
| − | |||
| − | + | ||
| + | ==Risk Factors== | ||
| + | |||
| + | TBD | ||
| + | |||
| + | |||
| + | ==Examples== | ||
| + | |||
| + | ===Example 1=== | ||
In the following method a DNS lookup failure will cause the Servlet to throw an exception. | In the following method a DNS lookup failure will cause the Servlet to throw an exception. | ||
| Line 27: | Line 42: | ||
</pre> | </pre> | ||
| − | + | ===Example 2=== | |
The following method will throw a NullPointerException if the parameter "name" is not part of the request. | The following method will throw a NullPointerException if the parameter "name" is not part of the request. | ||
| Line 41: | Line 56: | ||
</pre> | </pre> | ||
| − | |||
| − | ==Related Attacks== | + | ==Related [[Attacks]]== |
| − | + | * [[Attack 1]] | |
| + | * [[Attack 2]] | ||
| − | ==Related | + | |
| + | ==Related [[Vulnerabilities]]== | ||
| + | |||
| + | * [[Vulnerability 1]] | ||
| + | * [[Vulnerabiltiy 2]] | ||
| + | |||
| + | ==Related [[Controls]]== | ||
| + | |||
| + | * [[Control 1]] | ||
| + | * [[Control 2]] | ||
A good error handling mechanism always tries to capture all exceptions and returns a generic error message that does not reveal any details about the error and the application. Depending on the platform and container the application is running on, there can be different options. | A good error handling mechanism always tries to capture all exceptions and returns a generic error message that does not reveal any details about the error and the application. Depending on the platform and container the application is running on, there can be different options. | ||
| Line 57: | Line 81: | ||
** In ASP.NET, it is the Page_Error sub on the aspx page or associated codebehind page | ** In ASP.NET, it is the Page_Error sub on the aspx page or associated codebehind page | ||
| − | |||
| + | ==Related [[Technical Impacts]]== | ||
| + | |||
| + | * [[Technical Impact 1]] | ||
| + | * [[Technical Impact 2]] | ||
| + | |||
| + | |||
| + | ==References== | ||
| + | |||
| + | TBD | ||
| + | [[Category:FIXME|add links | ||
| + | |||
| + | In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki> | ||
| + | |||
| + | Availability Vulnerability | ||
| + | |||
| + | Authorization Vulnerability | ||
| + | |||
| + | Authentication Vulnerability | ||
| + | |||
| + | Concurrency Vulnerability | ||
| + | |||
| + | Configuration Vulnerability | ||
| + | |||
| + | Cryptographic Vulnerability | ||
| + | |||
| + | Encoding Vulnerability | ||
| + | |||
| + | Error Handling Vulnerability | ||
| + | |||
| + | Input Validation Vulnerability | ||
| + | |||
| + | Logging and Auditing Vulnerability | ||
| + | |||
| + | Session Management Vulnerability]] | ||
| + | |||
| + | __NOTOC__ | ||
| + | |||
| + | |||
| + | [[Category:OWASP ASDR Project]] | ||
[[Category:Error Handling Vulnerability]] | [[Category:Error Handling Vulnerability]] | ||
| − | |||
[[Category:Java]] | [[Category:Java]] | ||
| − | |||
[[Category:Implementation]] | [[Category:Implementation]] | ||
| − | |||
[[Category:Code Snippet]] | [[Category:Code Snippet]] | ||
| − | |||
[[Category:Servlet]] | [[Category:Servlet]] | ||
Revision as of 01:05, 1 October 2008
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
- This article includes content generously donated to OWASP by
Last revision (mm/dd/yy): 10/1/2008
Vulnerabilities Table of Contents
Description
If a Servlet fails to catch all exceptions, it may reveal debugging information that will help an adversary form a plan of attack.
When a Servlet throws an exception, the default error response the Servlet container sends back to the user typically includes debugging information. This information is of great value to an attacker. 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.
Risk Factors
TBD
Examples
Example 1
In the following method a DNS lookup failure will cause the Servlet to throw an exception.
protected void doPost (HttpServletRequest req,
HttpServletResponse res)
throws IOException {
String ip = req.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
...
out.println("hello " + addr.getHostName());
}
Example 2
The following method will throw a NullPointerException if the parameter "name" is not part of the request.
protected void doPost (HttpServletRequest req,
HttpServletResponse res)
throws IOException {
String name = getParameter("name");
...
out.println("hello " + name.trim());
}
Related Attacks
Related Vulnerabilities
Related Controls
A good error handling mechanism always tries to capture all exceptions and returns a generic error message that does not reveal any details about the error and the application. Depending on the platform and container the application is running on, there can be different options.
- Set a generic custom error page for all unhandled exceptions at the container level. (Normally, this is set in the configuration file.) The generic custom error page should have a simple error message that does not reveal any details about the exception happened.
- In ASP.NET, it is the customError tag in the web.config file
- Use an global error handler to capture all unhandled exceptions.
- In ASP.NET, it is the Application_Error sub in the global.asax file.
- Handle the error in the page level
- In ASP.NET, it is the Page_Error sub on the aspx page or associated codebehind page
Related Technical Impacts
References
TBD
