Logging is essential for gathering debugging information, for carrying out incident response or forensics activities and for maintaining incriminating , and 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 through 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. For example, leaking unencrypted credit card numbers into a log file could be a violation of PCI DSS (Payment Card Industry Data Security Standard) regulations [PCI 2010]. Consequently, ensure that logs must not contain only non- sensitive data., particularly when prohibited by law.
Unfortunately, violations of this rule are common. For example, prior to version Violations of this guideline are common. For example, prior to version 0.8.1, the LineControl Java client logged sensitive information , including the local user's password \[[CVE 2008|AA. Bibliography#CVE 08]\]password, as documented by CVE-2005-2990. Wiki Markup
The java.util.logging
class provides the a basic logging framework in for JDK v1versions 1.4 and above; the examples below use the logging framework. The higher. Other logging frameworks exist, but the basic principles apply regardless of the particular logging framework chosen.
Programs 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 be included in logs only in encrypted form. Information such as passwords should not be logged at all.
For the following code examples, the log lies outside the trust boundary of the information being recorded. Also, normal log messages should include additional parameters such as date, time, source event, and so forth. This information has been omitted from the following code examples for 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. Such This data can be misused in various ways, such as building , for example, to build a profile of a user's browsing habits. Such logging may violate legal restrictions in many countries.
When the log cannot contain IP addresses, it should not contain any information about a SecurityException
, because it might leak an IP address. 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 ERR00-J. Do not suppress or ignore checked exceptions).
Code Block | ||
---|---|---|
| ||
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 excludes the sensitive information from the log message. does not log security exceptions except for the logging implicitly performed by MyExceptionReporter
:
Code Block | ||
---|---|---|
| ||
// ... catch (SecurityException e) { Exception e = MyExceptionReporter.handle(e); logger.log(Level.FINEST, "Security Exception Occurred", e); } |
...
Noncompliant Code Example
Some information that is logged should be elided from Log messages with sensitive information should not be printed to the console display for security reasons (a possible example might be of sensitive information is 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 By default, the INFO
, WARNING
, and SEVERE
levels print the message to the console in addition to an external source.
Code Block | ||
---|---|---|
| ||
logger.info(passengerAge); // displays passenger age on the console
|
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.
Code Block | ||
---|---|---|
| ||
logger.finest(passengerAge); // does not display on the console
|
Noncompliant Code Example
, which is accessible by end users and system administrators.
If we assume that the passenger age can appear in log files on the current system but not on the console display, this code example is noncompliantSensitive user data can be recorded without deliberate intent; this can occur when the log message 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 so that intrusion detection systems can operate on it. However, logging personally identifiable information is undesirable, and possibly illegal.
Code Block | ||
---|---|---|
| ||
String str = JOptionPane.showInputDialog(null, "Enter your occupationlogger.info("Age: ", "Tax Help Form", 1+ passengerAge); |
Compliant Solution
Apply a filter to the input to reduce inadvertent logging of sensitive data. This compliant solution uses a simple filter — a check for a string of digits that might have been intended for SSN
field that lies above the occupation
field — 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 restrictionsThis compliant solution logs the passenger age at the FINEST
level to prevent this information from displaying on the console. As noted previously, we are assuming the age may appear in system log files but not on the console.
Code Block | ||
---|---|---|
| ||
public// classMake MyFiltersure implementsthat Filterall { handlers only publicprint booleanlog isLoggable(LogRecord lr) { String msgmessages rated INFO or higher Handler handlers[] = lrlogger.getMessagegetHandlers(); for 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()); |
...
(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.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|
FIO13-J |
Medium |
Probable |
High | P4 | L3 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
Bibliography
...
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Parasoft Jtest |
| CERT.FIO13.SENS CERT.FIO13.LHII CERT.FIO13.PEO CERT.FIO13.CONSEN | Prevent exposure of sensitive data Avoid logging sensitive Hibernate-related information at the 'info' level in 'log4j.properties' files Do not pass exception messages into output in order to prevent the application from leaking sensitive information Do not log confidential or sensitive information |
Related Guidelines
CWE-359, Privacy Violation |
Android Implementation Details
DRD04-J. Do not log sensitive information is an Android-specific instance of this rule.
Bibliography
...
...
[ |
...
...
...
] | Section 11.1 |
...
, "Privacy |
...
and |
...
Regulation: |
...
Handling |
...
Private |
...
Information |
...
" |
[CVE |
...
...
|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2990] \[[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 12. Input Output (FIO) IDS20-J. Exclude user input from format strings