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:
-
Unavailability of the Application: If an exception is thrown, the application might become temporarily or permanently unavailable, depending on the severity of the exception.
-
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.
-
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.