Page History

Logging is essential for gathering debugging information, for carrying out incident response or forensics activities and for maintaining incriminating evidence. HoweverNevertheless, logging sensitive data should not be logged for many reasons. Privacy 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 through insiders are a few concerns. Sensitive information includes and , 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. In JDK v1.4 and above, the java.util.logging class provides the basic logging framework. Many countries prohibit or restrict collection of personal data; others permit retention of personal data only when held in an anonymized form. Consequently, ensure that logs contain only non-sensitive data.

While several instancesViolations of this anti-patternguideline canare becommon. found in the wild, one example is of the fix provided in the LineControl Java client. Prior For example, prior to version 0.8.1, LineControl theJava client logged sensitive information such asincluding the local user's password \[[CVE 2008|AA. Bibliography#CVE 08]\].

The java.util.logging class provides the basic logging framework in JDK v1.4 and above; the examples below use the logging framework. The basic principles apply regardless of the particular logging framework chosen.

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. Such data can be misused for nefarious purposes in various ways, such as building a profile of the a user's browsing habits. Many countries disallow the collection of non-anonymous personal data while others allow its retention in an anonymized formSuch logging may violate legal restrictions in many countries.

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());
  }
} 

...

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

If the 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 guideline EXC01-J. Use a class dedicated to reporting exceptions.)

Noncompliant Code Example

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

...

This compliant solution logs at the FINEST level so that a level below INFO — FINEST, in this case — to prevent the passenger age is not from being displayed on the console.

...

Noncompliant Code Example

It is also possible for sensitive Sensitive user data to get can be recorded without deliberate intent, for example, ; this can occur when the log message uses records user supplied input. In this noncompliant code 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 log the entered data will be logged so that intrusion detection systems can operate on it. ClearlyHowever, logging personally identifiable information is undesirable, and possibly illegal.

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

Compliant Solution

As Apply a first step, a filter can be applied to the input to prevent reduce inadvertent logging of sensitive data. In this This compliant solution , uses a simple filter — a check is enforced so that for a string of digits from the that might have been intended for SSN field that lies above say the occupation field , does not accidentally show up — to prevent sensitive data from appearing in the log files. The example filter may be too simplistic for production use; ensure that your filters are sufficient to prevent violation of applicable legal restrictions.

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 Log entries should also contain other additional parameters such as date, time, source event and so on. Some of , etc.; these parameters have been are omitted from this example for the sake of brevity.

Risk Assessment

Logging sensitive information can break the security of the system and violate system security policies and can violate user privacy when the logging level is incorrect or when the log files are not secured properlyinsecure.

Automated Detection

...

Related Vulnerabilities

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

...

\[[API 2006|AA. Bibliography#API 06]\]] Class {{java.util.logging.Logger}}
\[[SunChess 20062007|AA. Bibliography#SunBibliography#Chess 0607]\]] [Java Logging Overview|http://java.sun.com/javase/6/docs/technotes/guides/logging/overview.html] 11.1 Privacy and Regulation: Handling Private Information
\[[CVE 2008|AA. Bibliography#CVE 08]\]] [CVE-2005-2990|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2990]
\[[Chess 2007|AA. Bibliography#Chess 07]\]] 11.1 Privacy and Regulation: Handling Private Information
\[[MITRE 2009|AA. Bibliography#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"
\[[Sun 2006|AA. Bibliography#Sun 06]\]] [Java Logging Overview|http://java.sun.com/javase/6/docs/technotes/guides/logging/overview.html]

...

FIO07-J. Do not create temporary files in shared directories      09. Input Output (FIO)      FIO09-J. Exclude user input from format strings