If a Servlet fails to catch all exceptions, it might 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.
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());
}
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());
}
[1] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A6 Information Leakage and Improper Error Handling
[2] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3120 CAT II
[3] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 209, CWE ID 431
[4] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) Information Leakage
[5] Standards Mapping - SANS Top 25 2009 - (SANS 2009) Insecure Interaction - CWE ID 209
[6] Standards Mapping - SANS Top 25 2010 - (SANS 2010) Insecure Interaction - CWE ID 209
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.5
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.5.6