Kingdom: Encapsulation
Encapsulation is about drawing strong boundaries. In a web browser that might mean ensuring that your mobile code cannot be abused by other mobile code. On the server it might mean differentiation between validated data and unvalidated data, between one user's data and another's, or between data users are allowed to see and data that they are not.
Poor Logging Practice: Use of a System Output Stream
Abstract
Using
Console.Out
or Console.Error
rather than a dedicated logging facility makes it difficult to monitor the program behavior.Explanation
Example 1: The first .NET program that a developer learns to write is the following:
While most programmers go on to learn many nuances and subtleties about .NET, a surprising number hang on to this first lesson and never give up on writing messages to standard output using
The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features like logging levels, uniform formatting, a logger identifier, timestamps, and, perhaps most critically, the ability to direct the log messages to the right place. When the use of system output streams is jumbled together with the code that uses loggers properly, the result is often a well-kept log that is missing critical information.
Developers widely accept the need for structured logging, but many continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, use of
public class MyClass {
...
Console.WriteLine("hello world");
...
}
While most programmers go on to learn many nuances and subtleties about .NET, a surprising number hang on to this first lesson and never give up on writing messages to standard output using
Console.WriteLine()
.The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features like logging levels, uniform formatting, a logger identifier, timestamps, and, perhaps most critically, the ability to direct the log messages to the right place. When the use of system output streams is jumbled together with the code that uses loggers properly, the result is often a well-kept log that is missing critical information.
Developers widely accept the need for structured logging, but many continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, use of
Console.WriteLine
may indicate an oversight in the move to a structured logging system.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 398
[2] Standards Mapping - FIPS200 AU
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[5] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[6] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.1
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[18] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.dotnet.poor_logging_practice_use_of_a_system_output_stream
Abstract
Using
os.Stdout
or os.Stderr
rather than a dedicated logging facility makes it difficult to monitor the program behavior.Explanation
Example 1: Typically, the first Go program that a developer learns to write is the following:
While most developers go on to learn many nuances and subtleties about Go, some never give up on writing messages to standard output using
The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features such as logging levels, uniform formatting, a logger identifier, timestamps, and the ability to direct log messages to a proper location. When the use of system output streams is jumbled together with code that uses loggers properly, the result is often a well-kept log that is missing critical information.
Structured logging is widely accepted but many developers continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, logging to
...
func foo(){
fmt.Println("Hello World")
}
While most developers go on to learn many nuances and subtleties about Go, some never give up on writing messages to standard output using
fmt.Println()
.The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features such as logging levels, uniform formatting, a logger identifier, timestamps, and the ability to direct log messages to a proper location. When the use of system output streams is jumbled together with code that uses loggers properly, the result is often a well-kept log that is missing critical information.
Structured logging is widely accepted but many developers continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, logging to
os.Stdout
or os.Stderr
might indicate an oversight in the move to a structured logging system.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 398
[2] Standards Mapping - FIPS200 AU
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[5] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[6] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.1
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[18] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.semantic.golang.poor_logging_practice_use_of_a_system_output_stream
Abstract
Using
System.out
or System.err
rather than a dedicated logging facility makes it difficult to monitor the program behavior.Explanation
Example 1: The first Java program that a developer learns to write is the following:
While most programmers go on to learn many nuances and subtleties about Java, a surprising number hang on to this first lesson and never give up on writing messages to standard output using
The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features like logging levels, uniform formatting, a logger identifier, timestamps, and, perhaps most critically, the ability to direct the log messages to the right place. When the use of system output streams is jumbled together with the code that uses loggers properly, the result is often a well-kept log that is missing critical information.
Developers widely accept the need for structured logging, but many continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, use of
public class MyClass
...
System.out.println("hello world");
...
}
While most programmers go on to learn many nuances and subtleties about Java, a surprising number hang on to this first lesson and never give up on writing messages to standard output using
System.out.println()
.The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features like logging levels, uniform formatting, a logger identifier, timestamps, and, perhaps most critically, the ability to direct the log messages to the right place. When the use of system output streams is jumbled together with the code that uses loggers properly, the result is often a well-kept log that is missing critical information.
Developers widely accept the need for structured logging, but many continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, use of
System.out
or System.err
may indicate an oversight in the move to a structured logging system.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 398
[2] Standards Mapping - FIPS200 AU
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[5] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[6] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.1
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[18] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.java.poor_logging_practice_use_of_a_system_output_stream
Abstract
Using
process.stdout
or process.stderr
rather than a dedicated logging facility makes it difficult to monitor the behavior of the program.Explanation
Example 1: A simple program an early Node.js developer may write to read from stdin and write it back to stdout again may look like the following:
While most programmers go on to learn many nuances and subtleties about JavaScript and Node.js in particular, many will hang on to this first lesson and never give up on writing messages to standard output using
The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features like logging levels, uniform formatting, a logger identifier, timestamps, and, perhaps most critically, the ability to direct the log messages to the right place. When the use of system output streams is jumbled together with the code that uses loggers properly, the result is often a well-kept log that is missing critical information.
Developers widely accept the need for structured logging, but many continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, use of
process.stdin.on('readable', function(){
var s = process.stdin.read();
if (s != null){
process.stdout.write(s);
}
});
While most programmers go on to learn many nuances and subtleties about JavaScript and Node.js in particular, many will hang on to this first lesson and never give up on writing messages to standard output using
process.stdout.write()
.The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features like logging levels, uniform formatting, a logger identifier, timestamps, and, perhaps most critically, the ability to direct the log messages to the right place. When the use of system output streams is jumbled together with the code that uses loggers properly, the result is often a well-kept log that is missing critical information.
Developers widely accept the need for structured logging, but many continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, use of
process.stdout
or process.stderr
may indicate an oversight in the move to a structured logging system.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 398
[2] Standards Mapping - FIPS200 AU
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[5] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[6] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.1
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[18] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.javascript.poor_logging_practice_use_of_a_system_output_stream
Abstract
Using
print
or println
rather than a dedicated logging facility makes it difficult to monitor the program behavior.Explanation
Example 1: The first Kotlin program that a developer learns to write is the following:
While most programmers go on to learn many nuances and subtleties about Kotlin, a surprising number hang on to this first lesson and never give up on writing messages to standard output using
The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features like logging levels, uniform formatting, a logger identifier, timestamps, and, perhaps most critically, the ability to direct the log messages to the right place. When the use of system output streams is jumbled together with the code that uses loggers properly, the result is often a well-kept log that is missing critical information.
Developers widely accept the need for structured logging, but many continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, use of the standard ouput or error stream may indicate an oversight in the move to a structured logging system.
class MyClass {
...
println("hello world")
...
}
}
While most programmers go on to learn many nuances and subtleties about Kotlin, a surprising number hang on to this first lesson and never give up on writing messages to standard output using
print
or println
.The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features like logging levels, uniform formatting, a logger identifier, timestamps, and, perhaps most critically, the ability to direct the log messages to the right place. When the use of system output streams is jumbled together with the code that uses loggers properly, the result is often a well-kept log that is missing critical information.
Developers widely accept the need for structured logging, but many continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, use of the standard ouput or error stream may indicate an oversight in the move to a structured logging system.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 398
[2] Standards Mapping - FIPS200 AU
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[5] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[6] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.1
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[18] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.kotlin.poor_logging_practice_use_of_a_system_output_stream
Abstract
Using standard output or standard error rather than a dedicated logging facility makes it difficult to monitor the behavior of the program.
Explanation
Example 1: The first Python program that a developer learns to write usually looks like this:
While most programmers go on to learn many nuances and subtleties about Python, a surprising number hang on to this first lesson and never give up on writing messages to standard output.
The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features like logging levels, uniform formatting, a logger identifier, timestamps, and, perhaps most critically, the ability to direct the log messages to the right place. When the use of system output streams is jumbled together with the code that uses loggers properly, the result is often a well-kept log that is missing critical information.
Developers widely accept the need for structured logging, but many continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, use of
sys.stdout.write("hello world")
While most programmers go on to learn many nuances and subtleties about Python, a surprising number hang on to this first lesson and never give up on writing messages to standard output.
The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features like logging levels, uniform formatting, a logger identifier, timestamps, and, perhaps most critically, the ability to direct the log messages to the right place. When the use of system output streams is jumbled together with the code that uses loggers properly, the result is often a well-kept log that is missing critical information.
Developers widely accept the need for structured logging, but many continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, use of
sys.stdout
or sys.stderr
may indicate an oversight in the move to a structured logging system.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 398
[2] Standards Mapping - FIPS200 AU
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[5] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[6] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.1
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[18] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.python.poor_logging_practice_use_of_a_system_output_stream
Abstract
Using
Kernel.puts
,Kernel.warn
or Kernel.printf
rather than a dedicated logging facility makes it difficult to monitor the behavior of the program.Explanation
Example 1: The first Ruby program that a developer learns to write often will include functionality such as:
While most programmers go on to learn many nuances and subtleties about Ruby, a surprising number hang on to this first lesson and never give up on writing messages to standard output using
The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features like logging levels, uniform formatting, a logger identifier, timestamps, and, perhaps most critically, the ability to direct the log messages to the right place. When the use of system output streams is jumbled together with the code that uses loggers properly, the result is often a well-kept log that is missing critical information.
Developers widely accept the need for structured logging, but many continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, use of
If there is a company policy not to use these APIs, this could still be worked around via the use of a logging system to then print the information to a system output stream.
Example 2: The following code uses the
...
puts "hello world"
...
While most programmers go on to learn many nuances and subtleties about Ruby, a surprising number hang on to this first lesson and never give up on writing messages to standard output using
Kernel.puts
.The problem is that writing directly to standard output or standard error is often used as an unstructured form of logging. Structured logging facilities provide features like logging levels, uniform formatting, a logger identifier, timestamps, and, perhaps most critically, the ability to direct the log messages to the right place. When the use of system output streams is jumbled together with the code that uses loggers properly, the result is often a well-kept log that is missing critical information.
Developers widely accept the need for structured logging, but many continue to use system output streams in their "pre-production" development. If the code you are reviewing is past the initial phases of development, use of
Kernel.puts
,Kernel.warn
or Kernel.printf
may indicate an oversight in the move to a structured logging system.If there is a company policy not to use these APIs, this could still be worked around via the use of a logging system to then print the information to a system output stream.
Example 2: The following code uses the
Logger
class, but logs information to a system output stream:
require 'logger'
...
logger = Logger.new($stdout)
logger.info("hello world")
...
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 398
[2] Standards Mapping - FIPS200 AU
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[5] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[6] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.1
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[18] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.ruby.poor_logging_practice_use_of_a_system_output_stream