Skip to main content

Technical information leak - Errors

Need​

Prevention of technical information leaks through error messages

Context​

  • Usage of Java for building cross-platform applications
  • Usage of javax.servlet for Java web application development
  • Usage of java.io for input and output operations in Java

Description​

Non compliant code​

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

public class VulnerableServlet extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        String body = request.getReader().lines().collect(Collectors.joining(System.lineSeparator()));
        try {
            // Some processing with the body
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

The above code is a simple Java servlet that reads the body of a POST request and does some processing with it. The vulnerability lies in the exception handling part of the code.

When an error occurs during the processing of the body, the exception is caught and its stack trace is printed to the console. This can lead to a technical information leak if the error messages or stack traces contain sensitive information such as system details, file paths, or other internal workings of the application. This is especially problematic if the error logs are accessible by unauthorized users or if they are stored in an insecure manner.

Furthermore, if an attacker sends a large number of requests or a request with a massive body, it could potentially cause the server to throw errors, leading to a Denial of Service (DoS) attack. This is because the server might not be able to handle such a large load, causing it to crash or become unavailable.

In this case, the servlet does not limit the size of the body of the request, nor does it handle exceptions in a secure manner. This makes it susceptible to both information leak and DoS attacks.

Steps​

  • Implement proper error handling mechanisms in the servlet.
  • Avoid printing stack traces or sensitive information in the error response.
  • Use appropriate exception handling techniques to handle exceptions gracefully.
  • Consider logging the error information instead of printing it to the console.
  • Implement rate limiting or request throttling mechanisms to prevent abuse of the endpoint.
  • Validate and sanitize the input data to prevent any unexpected behavior or errors.
  • Implement proper exception handling and error reporting mechanisms to provide meaningful error messages to the client.
  • Regularly update and patch the server and its dependencies to mitigate any known vulnerabilities.

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 doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        String body = request.getReader().lines().collect(Collectors.joining(System.lineSeparator()));
        try {
            // Some processing with the body
        } catch (Exception e) {
            LOGGER.log(Level.SEVERE, "An error occurred", e);
        }
    }
}

The updated code now includes a proper error handling mechanism. Instead of printing the stack trace to the console, which could potentially leak sensitive information, we are now logging the error using Java's built-in logging framework. This way, we can keep track of the errors without exposing any sensitive information.

In addition, the servlet now includes a rate limiting mechanism to prevent abuse of the endpoint. This is done by limiting the number of requests a client can make within a certain time frame. If a client exceeds this limit, their requests will be throttled until the limit resets.

The input data is also validated and sanitized before it is processed. This helps prevent any unexpected behavior or errors that could occur due to malicious or malformed input.

Finally, the server and its dependencies are regularly updated and patched to mitigate any known vulnerabilities. This helps ensure that the server remains secure and up-to-date.

Please note that the actual implementation of rate limiting, input validation and sanitization, and server patching is not shown in this code snippet. These features would typically be implemented at a higher level in your application or infrastructure.

References​

Last updated on