1571
If errors must be captured in some detail, record them in log messages, but consider what
could occur if the log messages can be viewed by attackers. Highly sensitive information such
as passwords should never be saved to log files. Avoid inconsistent messaging that might
accidentally tip off an attacker about internal state, such as whether a user account exists or not.
Exposing additional information to a potential attacker in the context of an exceptional condition
can help the attacker determine what attack vectors are most likely to succeed beyond DoS.
Phase: Implementation
Strategy = Input Validation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use
a list of acceptable inputs that strictly conform to specifications. Reject any input that does not
strictly conform to specifications, or transform it into something that does. When performing
input validation, consider all potentially relevant properties, including length, type of input, the
full range of acceptable values, missing or extra inputs, syntax, consistency across related
fields, and conformance to business rules. As an example of business rule logic, "boat" may be
syntactically valid because it only contains alphanumeric characters, but it is not valid if the input
is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for
malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if
the code's environment changes. This can give attackers enough room to bypass the intended
validation. However, denylists can be useful for detecting potential attacks or determining which
inputs are so malformed that they should be rejected outright.
Phase: Architecture and Design
Phase: Implementation
If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to
simply let the program fail poorly in cases such as low memory conditions, but an attacker may
be able to assert control before the software has fully exited. Alternately, an uncontrolled failure
could cause cascading problems with other downstream components; for example, the program
could send a signal to a downstream process so the process immediately knows that a problem
has occurred and has a better chance of recovery.
Phase: Architecture and Design
Use system limits, which should help to prevent resource exhaustion. However, the product
should still handle low resource conditions since they may still occur.
Demonstrative Examples
Example 1:
Consider the following code segment:
Example Language: C (Bad)
char buf[10], cp_buf[10];
fgets(buf, 10, stdin);
strcpy(cp_buf, buf);
The programmer expects that when fgets() returns, buf will contain a null-terminated string of length
9 or less. But if an I/O error occurs, fgets() will not null-terminate buf. Furthermore, if the end of the
file is reached before any characters are read, fgets() returns without writing anything to buf. In both
of these situations, fgets() signals that something unusual has happened by returning NULL, but in
this code, the warning will not be noticed. The lack of a null terminator in buf can result in a buffer
overflow in the subsequent call to strcpy().
Example 2:
The following code does not check to see if memory allocation succeeded before attempting to use
the pointer returned by malloc().
CWE Version 4.14
CWE-754: Improper Check for Unusual or Exceptional Conditions
CWE-754: Improper Check for Unusual or Exceptional Conditions