Input Validation and Data Sanitization

By definition, security vulnerabilities are flaws in software that can be exploited by an attacker. To succeed, the attacker must provide malicious inputs to a program of influence the program's environments to trigger the vulnerability. Consequently, preventing the introduction of malicious inputs into a program can eliminate the majority of vulnerabilities; the purpose of input validation and data sanitization.

Regardless of programming language, input validation requires several steps. The following steps are paraphrased from _Secure Coding in C and C++_ \[[Seacord 2005|AA. Bibliography#Seacord 05]\]:

1. All input sources must be identified. Input sources include the console, command line arguments, files, network data, environment variables, and system properties.
2. Specify and validate data. Data from untrusted sources must be fully specified and the data validated against these specifications. The system implementation must be designed to handle any range or combination of valid data. Valid data, in this sense, is data that is anticipated by the design and implementation of the system and therefore will not result in the system entering an indeterminate state. For example, if a system accepts two integers as input and multiplies those two values, the system must either (a) validate the input to ensure that an overflow or other exceptional condition cannot occur as a result of the operation or (b) be prepared to handle the result of the operation. The specifications must address limits, minimum and maximum values, minimum and maximum lengths, valid content, initialization and reinitialization requirements, and encryption requirements for storage and transmission.
3. Ensure that all input meets specification. Input should be validated as soon as possible. Incorrect input is not always malicious—often it is accidental. Reporting the error as soon as possible often helps correct the problem. When an exception occurs deep in the code it is not always apparent that the cause was an invalid input and which input was out of bounds. A data dictionary or similar mechanism can be used for specification of all program inputs. Input is usually stored in variables, and some input is eventually stored as persistent data. To validate input, specifications for what is valid input must be developed. A good practice is to define data and variable specifications, not just for all variables that hold user input, but also for all variables that hold data from a persistent store. The need to validate user input is obvious; the need to validate data being read from a persistent store is a defense against the possibility that the persistent store has been tampered with.

The Myth of Trust

Software programs often contain multiple components that act as subsystems, where each component operates in one or more trusted domains. For example, one component may have access to the file system but lack access to the network, while another component has access to the network but lacks access to the file system. _Distrustful decomposition_ and _privilege separation_ \[[Dougherty 2009|AA. Bibliography#Dougherty 2009]\]  are examples of secure design patterns that recommend reducing the amount of code that runs with special privileges by designing the system using mutually untrusting components.

...