Skip to main content

Technical information leak - Stacktrace

Need​

Prevention of technical information leakage from system error traces

Context​

  • Usage of Ruby for building dynamic and object-oriented applications

Description​

Non compliant code​

begin
  # Some operation that can raise an exception
  1 / 0
rescue => e
  puts e.backtrace
end

In the above code snippet, we have a division operation that can potentially raise a ZeroDivisionError exception. When this exception occurs, it is caught in the rescue block where we print the complete stack trace of the error using e.backtrace.

This is a vulnerability because it exposes sensitive information about the application, such as file paths, function names, and other internal workings of the application. This information can be exploited by a malicious user to gain further understanding of the system and plan more targeted attacks.

In a production environment, it's a best practice to not expose such internal details of the application. Instead, log the error details to a file or a logging system that can be reviewed by the developers, and show a generic error message to the user.

Steps​

  • Avoid printing or logging the full stack trace in production environments.
  • Implement proper error handling and exception management.
  • Use a centralized error logging system to capture and store error information.
  • Provide meaningful error messages to users without exposing sensitive technical details.
  • Regularly review and update error handling mechanisms to ensure they are effective and secure.

Compliant code​

begin
  # Some operation that can raise an exception
  1 / 0
rescue => e
  if Rails.env.development?
    puts e.backtrace
  else
    Rails.logger.error e.message
  end
end

The updated code now checks the environment before deciding how to handle the error. If the application is running in a development environment, it will print the full stack trace to the console. This is useful for debugging purposes as it provides detailed information about the error.

However, if the application is running in a production environment, it will only log the error message to a centralized logging system (in this case, the Rails logger). This prevents sensitive technical information from being exposed to potential attackers.

This approach provides a balance between the need for detailed error information during development and the need for security in production. It also ensures that all errors are logged in a centralized location, making it easier to monitor and respond to issues.

Remember to regularly review and update your error handling mechanisms to ensure they remain effective and secure. Always provide meaningful error messages to users without exposing sensitive technical details.

References​

Last updated on