FIO08-J. Do not log sensitive information outside a trust boundary

Logging is essential for debugging, incident response, or collecting forensic evidence. Nevertheless, logging sensitive data raises many concerns, including the privacy of the stakeholders, limitations imposed by the law on the collection of personal information, and the potential for data exposure by insiders. Sensitive information includes, but is not limited to, IP addresses, user names and passwords, email addresses, credit card numbers and any personally identifiable information such as social security numbers. Many countries prohibit or restrict collection of personal data; others permit retention of personal data only when held in an anonymized form. Consequently, logs must not contain sensitive data, particularly when prohibited by law.

Unfortunately, violations of this rule are common. For example, prior to version 0.8.1, LineControl Java client logged sensitive information including the local user's password as documented by CVE-2005-2990.

The java.util.logging class provides a basic logging framework for JDK versions 1.4 and higher. Other logging frameworks exist, however, the basic principles apply regardless of the particular logging framework chosen.

Programs must typically support varying levels of protection. Some information, such as access times can be safely logged. Some information can be logged, but the log file must be restricted from everyone but particular administrators. Other information, such as credit card numbers can only be logged in encrypted form. Other information, such as passwords, should not be logged at all.

For these code samples, we will assume that the log in question lies outside the trust boundary of the information being sent to it. Also, normal log messages should include additional parameters such as date, time, source event, and so forth. This information has been omitted from our examples for the brevity.

Noncompliant Code Example

In this noncompliant code example, a server logs the IP address of the remote client in the event of a security exception. This data can be misused, for example, to build a profile of a user's browsing habits. Such logging may violate legal restrictions in many countries.

If the log cannot contain IP addresses, it should not contain any information about a SecurityException. When an exception contains sensitive information, the custom MyExceptionReporter class should extract or cleanse it, before returning control to the next statement in the catch block (see rule ERR00-J. Do not suppress or ignore checked exceptions).

public void logRemoteIPAddress(String name) {
  Logger logger = Logger.getLogger("com.organization.Log");
  InetAddress machine = null;
  try {
    machine = InetAddress.getByName(name);
  } catch (UnknownHostException e) { 
    Exception e = MyExceptionReporter.handle(e);
  } catch (SecurityException e) {
    Exception e = MyExceptionReporter.handle(e);
    logger.severe(name + "," + machine.getHostAddress() + "," + e.toString());
  }
} 

Compliant Solution

This compliant solution does not log security exceptions.

   // ...
  catch (SecurityException e) {
    Exception e = MyExceptionReporter.handle(e);
  }

Noncompliant Code Example

Logged information should be elided from the console display for security reasons (a possible example might be passenger age). The java.util.logging.Logger class supports different logging levels that can be used for classifying such information. These are FINEST, FINER, FINE, CONFIG, INFO, WARNING and SEVERE. The INFO, WARNING and SEVERE levels log the message to the end users (console) and system administrators.

logger.info("Age: " + passengerAge);

Compliant Solution

This compliant solution logs at a level below INFO — FINEST, in this case — to prevent the passenger age from being displayed on the console. It also makes sure that such messages do not appear on the console. Thus the age is not actually logged.

Handler handlers[] = logger.getHandlers();
for (int i = 0; i < handlers.length; i++) {
  handlers[i].setLevel(Level.INFO);
}
// ...
logger.finest("Age: " + passengerAge);

Risk Assessment

Logging sensitive information can violate system security policies and can violate user privacy when the logging level is incorrect or when the log files are insecure.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography

FIO07-J. Do not create temporary files in shared directories      12. Input Output (FIO)      FIO09-J. Detect and handle file-related errors