Skip to main content

Technical information leak - Print Functions

Need​

Protection of sensitive information by removing or disabling print functions in production environment

Context​

  • Usage of Java for building robust and scalable applications
  • Usage of javax.servlet for building Java web applications
  • Usage of javax.servlet.http for handling HTTP requests and responses in Java web applications

Description​

Non compliant code​

import javax.servlet.*;
import javax.servlet.http.*;

public class VulnerableServlet extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        try {
            // Some code that might throw an exception
        } catch (Exception e) {
            e.printStackTrace();  // This is the vulnerability!
        }
    }
}

In the provided code snippet, we have a VulnerableServlet class that extends HttpServlet. Inside the doGet method, we have a try-catch block. This is a common structure used to handle exceptions in Java. If an exception is thrown within the try block, the program control gets transferred to the matching catch block, where the exception is handled.

The vulnerability lies in the catch block, where we are using e.printStackTrace(). This method prints the stack trace of the exception to the standard error output (stderr), which is typically the console. It includes the name of the exception, the description (if provided), and the full stack trace, including line numbers.

In a development environment, using e.printStackTrace() is acceptable because it helps to debug and fix errors. However, in a production environment, this is a security vulnerability. Attackers can trigger exceptions to reveal sensitive information about the application, such as the application's internal structure, the software components in use, their versions, and other technical details. This information can help attackers plan and execute more precise and damaging attacks.

To fix this vulnerability, it is recommended to use a proper logging mechanism that writes to a log file, not to the console. The log file should be properly secured and monitored to detect any unusual activity. Additionally, the logs should not contain sensitive information.

Steps​

  • Remove or comment out the print functions (e.g., print, println, printStackTrace) from the code.
  • Instead of printing the technical information, handle the exception appropriately by logging the error message or sending a custom error response.
  • Ensure that the error messages or responses do not contain sensitive information that could be exploited by attackers.
  • Consider using a logging framework to handle exceptions and log error messages in a more controlled and secure manner.
  • Test the application thoroughly to ensure that the changes made do not introduce any new vulnerabilities or impact the functionality of the application.

Compliant code​

import javax.servlet.*;
import javax.servlet.http.*;
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 code that might throw an exception
        } catch (Exception e) {
            LOGGER.log(Level.SEVERE, "An error occurred", e);
        }
    }
}

The original code was vulnerable due to the use of e.printStackTrace(), which could potentially leak sensitive information about the application's internal workings. This is especially dangerous in a production environment.

The revised code removes this vulnerability by replacing the printStackTrace() method with a logging statement. This is done using the java.util.logging framework, which is a part of Java's standard library.

In the revised code, a Logger instance is created, which is used to log any exceptions that occur. The Logger instance is created with the name of the class, which helps in identifying the source of any logged messages.

In the doGet method, the try-catch block is retained to handle any exceptions that might occur. However, instead of printing the stack trace of the exception, the exception is logged using the Logger.log method. The Level.SEVERE argument indicates that this is a serious error. The second argument is a custom error message, and the third argument is the exception itself.

This way, if an exception occurs, the details of the exception will be logged in a controlled manner, without exposing sensitive information. The logs can then be reviewed by the developers or system administrators to diagnose and fix the issue.

Remember to ensure that your logging configuration is set up to not log sensitive information and to restrict access to the logs to prevent any potential information leaks.

References​

Last updated on