Technical information leak - Print Functions - PHP

Technical information leak - Print Functions - PHP

Need

Prevention of sensitive information exposure through print functions

Context

  • Usage of PHP for server-side scripting and web development
  • Usage of Exception for handling errors and exceptional situations

Description

Non compliant code

        getMessage(), "\\n";
    }
?>
        
        

The above code snippet is an example of a technical information leak vulnerability due to the use of print functions. This is a PHP code using Laravel framework.

In this code, when an exception occurs in the try block, it is caught and the message of the exception is printed directly to the standard output using the echo function. This can potentially leak sensitive information about the internal workings of the application, such as database schema, file paths, or configuration settings, which are often included in exception messages.

This is especially dangerous in a production environment where this information can be seen by anyone who has access to the output of the application, including potential attackers. This information can be used to gain further understanding of the system and to plan more targeted attacks.

The best practice is to log the exception details to a file or a logging system that is only accessible by the developers or the system administrators, and show a generic error message to the user.

Steps

  • Remove the echo statement that prints the exception message to the standard output.
  • Instead of printing the exception message, log it to a file or a logging service. This way, the information is not exposed to the user but is still available for debugging purposes.
  • Ensure that the logging service or file is secure and only accessible to authorized personnel.
  • In the production environment, consider using a global exception handler to catch all unhandled exceptions and log them securely.

Compliant code

        getMessage());
    }
?>
        
        

The updated code removes the echo statement that was previously printing the exception message to the standard output. This was a vulnerability as it could potentially expose sensitive technical information to the user.

Instead of printing the exception message, it is now being logged using Laravel's Log facade with the error method. This method creates an error log message, which will be stored in the storage/logs directory by default.

The log file is not exposed to the user, but it is still available for debugging purposes. It is important to ensure that this log file is secure and only accessible to authorized personnel.

In a production environment, it is recommended to use a global exception handler to catch all unhandled exceptions and log them securely. Laravel provides a convenient way to do this through its App\\Exceptions\\Handler class. This class contains a report method where you can log exceptions or send them to an external service like Sentry or Bugsnag.

References