25
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.
Effectiveness = High
Phase: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are
duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side
checks by modifying values after the checks have been performed, or by changing the client
to remove the client-side checks entirely. Then, these modified values would be submitted to
the server. Even though client-side checks provide minimal benefits with respect to serverside
security, they are still useful. First, they can support intrusion detection. If the server
receives input that should have been rejected by the client, then it may be an indication of an
attack. Second, client-side error-checking can provide helpful feedback to the user about the
expectations for valid input. Third, there may be a reduction in server-side processing time for
accidental input errors, although this is typically a small savings.
Phase: Implementation
When your application combines data from multiple sources, perform the validation after the
sources have been combined. The individual data elements may pass the validation step but
violate the intended restrictions after they have been combined.
Phase: Implementation
Be especially careful to validate all input when invoking code that crosses language boundaries,
such as from an interpreted language to native code. This could create an unexpected interaction
between the language boundaries. Ensure that you are not violating any of the expectations
of the language with which you are interfacing. For example, even though Java may not be
susceptible to buffer overflows, providing a large argument in a call to native code might trigger
an overflow.
Phase: Implementation
Directly convert your input type into the expected data type, such as using a conversion function
that translates a string into a number. After converting to the expected data type, ensure that the
input's values fall within the expected range of allowable values and that multi-field consistencies
are maintained.
Phase: Implementation
Inputs should be decoded and canonicalized to the application's current internal representation
before being validated (CWE-180, CWE-181). Make sure that your application does not
inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass
allowlist schemes by introducing dangerous inputs after they have been checked. Use
libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated
canonicalization until your input does not change any more. This will avoid double-decoding and
similar scenarios, but it might inadvertently modify inputs that are allowed to contain properlyencoded
dangerous content.
Phase: Implementation
When exchanging data between components, ensure that both components are using the same
character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set
the encoding you are using whenever the protocol allows you to do so.
Demonstrative Examples
Example 1:
CWE Version 4.14
CWE-20: Improper Input Validation
CWE-20: Improper Input Validation