Page History

Logging is essential for gathering debugging information, carrying out incident response or forensics activities and for maintaining incriminating evidence. However, sensitive data should not be logged for many reasons. Privacy of the stakeholders, limitations imposed by the law on collection of personal information, and data exposure through insiders are a few concerns. Sensitive information includes and 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. In JDK v1.4 and above, the java.util.logging class provides the basic logging framework.

While we expect several instances of this anti-pattern, one example is of the fix provided in the LineControl Java client. Prior to version 0.8.1, the client logged sensitive information such as the local user's password. \[[CVE 08|AA. Java References#CVE 08]\]

Noncompliant Code Example

In this example, a server logs the IP address of the remote client in the event of a security exception. Such data can be misused for nefarious purposes such as building a profile of the user's browsing habits. Many countries disallow the collection of non-anonymous personal data while others allow its retention in an anonymized form.

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

To be compliant, simply eliminate the sensitive information before logging.

catch (SecurityException e){
  Exception e = MyExceptionReporter.handle(e);
  logger.log(Level.FINEST,"Exception Occurred",e);
}

If the exception contains such information, the custom MyExceptionReporter class should extract or cleanse it, before returning control to the catch block.

Noncompliant Code Example

Sometimes, some information is fit to be logged but should not be displayed on the console for security reasons (for instance, 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. All levels after and including INFO, log the message to the console in addition to an external source.

logger.info(passengerAge);  // displays passenger age on the console 

Compliant Solution

This solution logs at the FINEST level so that the passenger age is not displayed on the console.

logger.finest(passengerAge); // does not display on the console

Noncompliant Code Example

It can also be the case that sensitive user data gets recorded without deliberate intent, for example, when the log message uses user supplied input. In this example, the user mistakenly enters personal details (such as an SSN) in the occupation field. A suspicious server might throw an exception during input validation and the entered data will be logged so that intrusion detection systems can operate on it. Clearly, logging personally identifiable information is undesirable.

String str = JOptionPane.showInputDialog(null, "Enter your occupation: ", 
"Tax Help Form", 1);

Compliant Solution

As a first step, a filter can be applied to the input to prevent inadvertent logging of sensitive data. In this compliant solution, a check is built in so that a string of digits from the SSN field that lies above the occupation field, does not accidentally show up in the log files.

public class MyFilter implements Filter {
  public boolean isLoggable(LogRecord lr) {
    String msg = lr.getMessage();
    if (msg.matches("\\d*")) {  // filters out any digits
      return false;
    }
    return true;
  }
}

// Set the filter in main code
Logger logger = Logger.getLogger("com.organization.Log");
logger.setFilter(new MyFilter());

NOTE: A log entry should also contain other parameters such as date, time, source event and so on. Some of these parameters have been omitted from this example for the sake of brevity.

Risk Assessment

Automated Detection

TODO

Related Vulnerabilities

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

References

\[[API 06|AA. Java References#API 06]\]] Class {{java.util.logging.Logger}}
\[[Sun 06|AA. Java References#Sun 06]\]] [Java Logging Overview|http://java.sun.com/javase/6/docs/technotes/guides/logging/overview.html]
\[[CVE 08|AA. Java References#CVE 08]\]] [CVE-2005-2990|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2990]
\[[Chess 07|AA. Java References#Chess 07]\]] 11.1 Privacy and Regulation: Handling Private Information
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 532|http://cwe.mitre.org/data/definitions/532.html] "Information Leak Through Log Files", [CWE ID 533|http://cwe.mitre.org/data/definitions/533.html] "Information Leak Through Server Log Files", [CWE ID 359|http://cwe.mitre.org/data/definitions/359.html] "Privacy Violation", [CWE ID 542|http://cwe.mitre.org/data/definitions/542.html] "Information Leak Through Cleanup Log Files"

08. Input Output (FIO)      08. Input Output (FIO)      FIO31-J. Defensively copy mutable inputs and mutable internal components