String data passed to complex subsystems may contain special characters that can trigger commands or actions, resulting in a software vulnerability. As a result, it is necessary to sanitize all string data passed to complex subsystems so that the resulting string is innocuous in the context in which it will be interpreted.
These are some examples of complex subsystems:
- Command processor via a call to
system()or similar function (also addressed in ENV03-C. Sanitize the environment when invoking external programs)
- External programs
- Relational databases
- Third-party commercial off-the-shelf components (for example, an enterprise resource planning subsystem)
Noncompliant Code Example
Data sanitization requires an understanding of the data being passed and the capabilities of the subsystem. John Viega and Matt Messier provide an example of an application that inputs an email address to a buffer and then uses this string as an argument in a call to
system() [Viega 2003]:
The risk, of course, is that the user enters the following string as an email address:
For more information on the
system() call, see ENV03-C. Sanitize the environment when invoking external programs and ENV33-C. Do not call system().
It is necessary to ensure that all valid data is accepted, while potentially dangerous data is rejected or sanitized. Doing so can be difficult when valid characters or sequences of characters also have special meaning to the subsystem and may involve validating the data against a grammar. In cases where there is no overlap, whitelisting can be used to eliminate dangerous characters from the data.
The whitelisting approach to data sanitization is to define a list of acceptable characters and remove any character that is not acceptable. The list of valid input values is typically a predictable, well-defined set of manageable size. This compliant solution, based on the
tcp_wrappers package written by Wietse Venema, shows the whitelisting approach:
The benefit of whitelisting is that a programmer can be certain that a string contains only characters that are considered safe by the programmer. Whitelisting is recommended over blacklisting, which traps all unacceptable characters, because the programmer needs only to ensure that acceptable characters are identified. As a result, the programmer can be less concerned about which characters an attacker may try in an attempt to bypass security checks.
Noncompliant Code Example
This noncompliant code example is taken from [VU#881872], a vulnerability in the Sun Solaris TELNET daemon (
in.telnetd) that allows a remote attacker to log on to the system with elevated privileges.
The vulnerability in
in.telnetd invokes the
login program by calling
execl(). This call passes unsanitized data from an untrusted source (the
USER environment variable) as an argument to the
An attacker, in this case, can gain unauthenticated access to a system by setting the
USER environment variable to a string, which is interpreted as an additional command-line option by the
login program. This kind of attack is called argument injection.
This compliant solution inserts the
"--" (double dash) argument before the call to
getenv("USER") in the call to
login program uses the POSIX
getopt() function to parse command-line arguments, and because the
"--" option causes
getopt() to stop interpreting options in the argument list, the
USER variable cannot be used by an attacker to inject an additional command-line option. This is a valid means of sanitizing the untrusted user data in this context because the behavior of the interpretation of the resulting string is rendered innocuous.
The call to
execl() is not susceptible to command injection because the shell command interpreter is not invoked. (See ENV33-C. Do not call system().)
Failure to sanitize data passed to a complex subsystem can lead to an injection attack, data integrity issues, and a loss of sensitive data.
|LDRA tool suite|
|108 D, 109 D||Partially implemented|
Protect against command injection
|Polyspace Bug Finder|
Command argument from an unsecure source vulnerable to operating system command injection
Path argument from an unsecure source
Using a library argument from an externally controlled path
The validity of values received from external sources shall be checked
|SEI CERT C++ Coding Standard||VOID STR02-CPP. Sanitize data passed to complex subsystems|
|CERT Oracle Secure Coding Standard for Java||IDS00-J. Prevent SQL injection|
|MITRE CWE||CWE-88, Argument injection or modification|
CWE-78, Failure to sanitize data into an OS command (aka "OS command injection")