Skip to main content

Insecure exceptions - Empty or no catch

Need

Proper exception handling and error management

Context

  • Usage of Java 8 for developing applications with enhanced features and performance
  • Usage of javax.servlet-api for Java Servlet development

Description

Non compliant code

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class VulnerableServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response) {
try {
// Some code that could throw an exception
String param = request.getParameter("param");
int parsedParam = Integer.parseInt(param);
} catch (Exception e) {
// Empty catch block
}
}
}

The above code snippet contains a doGet method in a VulnerableServlet class which extends HttpServlet. This method attempts to retrieve a parameter from a request and parse it to an integer. This operation can potentially throw a NumberFormatException if the parameter is not a valid integer.

The problem lies in the catch block. It is designed to catch any Exception that might be thrown within the try block. However, the catch block is empty, meaning that if an exception is thrown, the application will not perform any actions to handle the error.

This lack of error handling can lead to several issues:

  1. Unavailability of the Application: If an exception is thrown, the application might become temporarily or permanently unavailable, depending on the severity of the exception.

  2. Loss of Diagnostic Information: When an exception is caught and not handled or logged, valuable information about what went wrong in the application is lost.

  3. Unexpected Behavior: The application might behave unexpectedly if an exception is thrown and not properly handled. This could lead to further errors down the line.

To fix this vulnerability, the catch block should be updated to properly handle the exception. This could include logging the error, sending a response to the user indicating an error occurred, or even re-throwing the exception to be handled at a higher level.

Steps

  • Add proper exception handling code within the catch block
  • Handle the exception appropriately, such as logging the error or providing a user-friendly error message
  • Consider using specific exception types instead of catching generic Exception
  • Ensure that the application remains functional even when exceptions occur

Compliant code

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
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) {
try {
// Some code that could throw an exception
String param = request.getParameter("param");
int parsedParam = Integer.parseInt(param);
} catch (NumberFormatException e) {
// Log the error
LOGGER.log(Level.SEVERE, "Error parsing parameter", e);
// Provide a user-friendly error message
response.sendError(HttpServletResponse.SC_BAD_REQUEST, "Invalid parameter");
} catch (Exception e) {
// Log the error
LOGGER.log(Level.SEVERE, "Unexpected error", e);
// Provide a user-friendly error message
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, "An unexpected error occurred");
}
}
}

The above code fixes the vulnerability by adding proper exception handling within the catch block.

Firstly, a Logger instance is created to log any exceptions that occur. This is useful for debugging and identifying issues in the application.

In the doGet method, the code that could potentially throw an exception is wrapped in a try block. If an exception occurs, it is caught and handled appropriately.

Two types of exceptions are caught: NumberFormatException and a generic Exception. The NumberFormatException is thrown by the Integer.parseInt method if the provided string cannot be parsed to an integer. If this occurs, the error is logged and a user-friendly error message is sent as a response with a 400 (Bad Request) status code.

The generic Exception is a catch-all for any other exceptions that might occur. If such an exception is thrown, the error is logged and a user-friendly error message is sent as a response with a 500 (Internal Server Error) status code.

By handling exceptions in this way, the application remains functional even when exceptions occur, and provides useful feedback to the user and developers.

References