The Myth of Trust
Wiki Markup
While Although software components can obey policies that allow them to transmit data across trust boundaries, they cannot specify the level of trust given to any component. The deployer of the application must define the trust boundaries with the help of a systemwide security policy. A security auditor can use that definition to determine whether the software adequately supports the security objectives of the application.
...
Data received by a component from a source outside the component's trust boundary can be malicious and can result in an injection attack, as shown in the scenario in Figure1 – Figure 1.
Figure 1. Injection attack
Programs must take steps to ensure that data received across a trust boundary is appropriate and not malicious. These steps can include the following:
Validation: Validation is the process of ensuring that input data falls within the expected domain of valid program input. This requires that inputs conform to type and numeric range requirements as well as to input invariants for the class or subsystem.
Sanitization: In many cases, the data is passed directly to a component in a different trusted domain. Data sanitization is the process of ensuring that data conforms to the requirements of the subsystem to which it is passed. Sanitization also involves ensuring that data conforms to security-related requirements regarding leaking or exposure of sensitive data when output across a trust boundary. Sanitization may include the elimination of unwanted characters from the input by means of removing, replacing, encoding, or escaping the characters. Sanitization may occur following input (input sanitization) or before the data is passed across a trust boundary (output sanitization). Data sanitization and input validation may coexist and complement each other. See rule IDS01-J for more details on data sanitizationMany command interpreters and parsers provide their own sanitization and validation methods. When available, their use is preferred over custom sanitization techniques because custom-developed sanitization can often neglect special cases or hidden complexities in the parser. Another problem with custom sanitization code is that it may not be adequately maintained when new capabilities are added to the command interpreter or parser software.
Canonicalization and Normalization: Canonicalization is the process of lossless reduction of the input to its equivalent simplest known form. Normalization is the process of lossy conversion of input data to the simplest known (and anticipated) form. Canonicalization and normalization must occur before validation to prevent attackers from exploiting the validation routine to strip away invalid characters and, as a result, constructing an invalid (and potentially malicious) character sequence. See rule IDS02 FIO16-J. Canonicalize path names before validating them for more information. Normalization should be performed only on fully assembled user input. Never normalize partial input or combine normalized input with nonnormalized input.
...
- Operating system command interpreter (see rule IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method)
- A data repository with an a SQL-compliant interface (see IDS00-J. Prevent SQL Injection)
- XML parser (see IDS16-J. Prevent XML Injection and IDS17-J. XML External Entity Attacks)
- Regular expression engines (see IDS08-J. Sanitize untrusted data included in a regular expression)
- Formatted output methods (see IDS06-J. Exclude unsanitized user input from format strings)
- XPath evaluators
- Lightweight Directory Access Protocol (LDAP) directory service
- Script engines
- Regular expression (regex) compilers
...
Bibliography
| [Seacord 2015] |