SV.TAINTED.INJECTION

Unvalidated input in downstream injection

Whenever input is accepted from the user or the outside environment, it should be validated for type, length, format, and range before it is used. Until properly validated, the data is said to be tainted. The SV.TAINTED family of checkers looks for the use of tainted data in code.

Injection problems include a variety of issues marked by the injection of control plane data into the user-controlled data plane. SQL injection is a typical example of an injection situation. The SV.TAINTED.INJECTION checker flags situations in which unvalidated data is passed as a parameter to functions that execute commands, such as SQL statements, process creation commands, and file manipulation functions.

Vulnerability and risk

When input to code isn't validated properly, an attacker can craft the input in a form that isn't expected by the application. The receipt of unintended input can result in altered control flow, arbitrary resource control, and arbitrary code execution. With this sort of opportunity, an attacker could

  • provide unexpected values and cause a program crash
  • cause excessive resource consumption
  • read confidential data
  • use malicious input to modify data or alter control flow
  • execute arbitrary commands

Injection attacks typically involve the disclosure of sensitive data and data that enables further exploitation. This type of attack often changes process flow, and frequently includes arbitrary code execution.

Mitigation and prevention

To avoid tainted input errors:

  • understand all the potential areas in which untrusted inputs could enter your software: parameters or arguments, cookies, input read from the network, environment variables, reverse DNS lookups, query results, filenames, databases, and any external systems
  • use a whitelist or 'known good' policy for inputs, rather than relying only on a blacklist or 'known bad' strategy
  • make sure all relevant properties of the input are validated, including length, type of input, ranges, missing or extra inputs, syntax, and consistency
  • if there are security checks on the client side of an applications, make sure they're duplicated on the server side
  • if the application combines inputs from multiple sources, perform the validation after the sources have been combined

Vulnerable code example

Copy 
  #include <stdlib.h>
  #include <stdio.h>
  #include <string.h>
  
  int main() {
    char buf[1024];
    char *s;
    char command[2048];
  
   printf("Enter Name to look:\n");
   fgets(buf, 1023, stdin);
   buf[1023] = '\0';
   s = strchr(buf,'\n');
   if (s != NULL) {
     *s = '\0';
   }
   strcpy(command, "grep \"");
   strcat(command, buf);
   strcat(command, "\" phone_book");
   system(command);
   return 0;
 }

Klocwork produces an issue report at line 20 indicating that unvalidated string 'command' received through a call to 'fgets' can be run as a command line through a call to 'system'. In this case, the SV.TAINTED.INJECTION checker flags potentially tainted data passed to a function that executes a command that could be exploited by a malicious user. The Klocwork warning enables you to make sure that no tainted data is passed to system functions.

Related checkers

External guidance

Security training

Application security training materials provided by Secure Code Warrior.