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 "Missing Error Handling"
Weilin Zhong (talk | contribs) (Added contents from Fortify.) |
|||
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== | ||
+ | |||
+ | 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. | ||
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. | 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. | ||
Line 12: | Line 20: | ||
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. | 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. | ||
− | |||
− | |||
− | |||
− | ==Related Attacks== | + | ==Risk Factors== |
+ | |||
+ | TBD | ||
+ | |||
+ | ==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 [[Attacks]]== | ||
+ | |||
+ | * [[Attack 1]] | ||
+ | * [[Attack 2]] | ||
+ | |||
+ | |||
+ | ==Related [[Vulnerabilities]]== | ||
+ | |||
+ | * [[Vulnerability 1]] | ||
+ | * [[Vulnerabiltiy 2]] | ||
+ | |||
+ | |||
+ | ==Related [[Controls]]== | ||
+ | |||
+ | * [[:Category:Error Handling]] | ||
+ | |||
+ | ==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:Java]] | [[Category:Java]] | ||
[[Category:Deployment]] | [[Category:Deployment]] | ||
[[Category:Environmental Vulnerability]] | [[Category:Environmental Vulnerability]] | ||
[[Category:Error Handling Vulnerability]] | [[Category:Error Handling Vulnerability]] |
Revision as of 17:29, 26 September 2008
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
Last revision (mm/dd/yy): 09/26/2008
Vulnerabilities Table of Contents
Description
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.
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.
Risk Factors
TBD
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 Attacks
Related Vulnerabilities
Related Controls
Related Technical Impacts
References
TBD