CWE-600 is a Java web server weakness. A servlet does not catch all exceptions, and the default error response may reveal sensitive debugging information.
How it happens
When a servlet throws, the container sends back a default error response. That response typically includes debugging information. MITRE gives a vivid example: a stack trace might show a malformed SQL query string, the type of database in use, and the version of the application container.
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
String id = req.getParameter("id");
Row r = dao.find(id); // throws on bad input, nothing catches it
resp.getWriter().println(r.name());
}
What an attacker gains
That information is of great value to an attacker. It lets them target known vulnerabilities in the specific database and container versions. The record lists confidentiality (read application data) and availability (the request can crash or restart a component) as the consequences.
How to find it
Trigger errors on purpose. Send malformed parameters, missing fields, and oversized values to each endpoint and read the response body. Any stack trace or class name in a browser response is a finding. In code review, look for servlet methods with no try and catch around the work.
How to fix it
MITRE's mitigation: implement exception blocks to handle all types of exceptions.
try {
Row r = dao.find(id);
resp.getWriter().println(r.name());
} catch (Exception e) {
log.error("lookup failed for request", e); // detail goes to the log
resp.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
"Something went wrong"); // generic text to the user
}
You can also configure an error page in web.xml for the exception types so any miss falls back to a generic page. Keep the real detail in server logs.
Quick check
Where should the stack trace go?
Into your server logs. The user should see only a generic error message.
