Skip to main content

Technical information leak - Stacktrace

Need​

Prevention of technical information leakage from system error traces

Context​

  • Usage of Java for building robust and scalable applications
  • Usage of javax.servlet for creating Java web applications with Servlets
  • Usage of java.io for input and output operations in Java programming

Description​

Non compliant code​

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.IOException;

public class VulnerableServlet extends HttpServlet {

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        try {
            // some risky operation
            throw new Exception("This is a forced exception");
        } catch (Exception e) {
            e.printStackTrace(response.getWriter());
        }
    }
}

The above servlet represents a vulnerable piece of code that is prone to technical information leakage through stack traces.

In the doGet method, an exception is deliberately thrown to mimic a risky operation that could potentially fail. In the catch block, the stack trace of the exception is printed directly to the HTTP response writer using e.printStackTrace(response.getWriter()).

This is a serious vulnerability because the stack trace, which is meant for debugging by developers, contains detailed information about the application's internal workings, such as class names, method names, and sometimes, system properties or even sensitive user data.

If an attacker can cause this exception to be thrown, they will receive the stack trace in the HTTP response. This information can be used to gain knowledge about the system and plan further attacks. It's equivalent to giving an attacker a roadmap to the application's internals.

The correct way to handle this is to log the exception for debugging purposes, but not include it in the HTTP response. If needed, a generic error message can be sent to the client.

Steps​

  • Avoid printing stack traces directly to the response.
  • Implement proper error handling and logging mechanisms.
  • Catch the exception and handle it appropriately instead of printing the stack trace.
  • Consider using a centralized error handling mechanism to handle exceptions consistently across the application.
  • Ensure that sensitive technical information is not exposed to the user in error messages or logs.

Compliant code​

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.IOException;
import java.util.logging.Level;
import java.util.logging.Logger;

public class SecureServlet extends HttpServlet {

    private static final Logger LOGGER = Logger.getLogger(SecureServlet.class.getName());

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        try {
            // some risky operation
            throw new Exception("This is a forced exception");
        } catch (Exception e) {
            LOGGER.log(Level.SEVERE, e.getMessage(), e);
            response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, "An error occurred while processing your request. Please try again later.");
        }
    }
}

The above code fixes the vulnerability by implementing proper error handling and logging mechanisms. Here's how:

  1. Avoid printing stack traces directly to the response: The e.printStackTrace(response.getWriter()) line has been removed. This line was printing the stack trace directly to the HTTP response, which could expose sensitive technical information to an attacker.

  2. Implement proper error handling and logging mechanisms: A Logger instance has been added to log exceptions. This allows exceptions to be recorded in a secure and controlled manner, which can aid in debugging and incident response.

  3. Catch the exception and handle it appropriately: The catch block now logs the exception and sends a generic error message to the client. This prevents the client from seeing the details of the exception, while still informing them that an error occurred.

  4. Use a centralized error handling mechanism: The Logger instance can be considered a centralized error handling mechanism. All exceptions are logged using this Logger, ensuring consistent handling of exceptions across the application.

  5. Ensure that sensitive technical information is not exposed to the user in error messages or logs: The error message sent to the client is a generic message that does not contain any technical information. The detailed exception information is logged on the server side, where it is not accessible to an attacker.

References​

Last updated on