Introduction
| Wiki Markup |
|---|
Software componentsprograms often contain multiple subcomponentscomponents 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 subcomponentscomponents. |
When subcomponents components with differing degrees of trust share data, the data are said to flow across a trust boundary. Because Java allows components under different protection trusted domains to communicate with each other, data can be transmitted across a trust boundary. Furthermore, a Java program can contain both internally developed and third-party code. Data that are transmitted to or accepted from third-party code also flow across a trust boundary.
...
Third-party code should operate in its own security trusted domain; any code potentially exported to a third-party — such as libraries — should be deployable in well-defined security trusted domains. The public API of the potentially-exported code can be considered to be a trust boundary. Data flowing across a trust boundary should be validated when the publisher lacks guarantees of validation. A subscriber or client may omit validation when the data flowing into its trust boundary is appropriate for use as is. In all other cases, inbound data must be validated.
...
These steps can include the following:
Validation, in the broadest sense, Validation: Validation is the process of ensuring that input data fall within the expected domain of valid program input. For example, not only must method arguments conform to the type and numeric range requirements of a method or subsystem, but also they must contain data that conform to the required input invariants for that method.
Sanitization: In many cases, the data may be passed directly to some subsystema component in a different trusted domain. Data sanitization is the process of ensuring that data conform conforms to the requirements of the subsystem to which they are passed. Sanitization also involves ensuring that data also conform 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 removal, replacement, encoding or escaping the characters. Sanitization may occur following input (input sanitize) or before the data is passed to across a trust boundary (output sanitization). Data sanitization and input validation may coexist and complement each other. Refer to the related guideline IDS01-J. Sanitize untrusted input before processing or storing it for more details on data sanitization. Data sanitization and input validation may coexist and complement each other.
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 illegal characters and thus constructing a forbidden (and potentially malicious) character sequence. Refer to the guideline IDS02-J. Normalize strings before validating them for more details. In addition, ensure that normalization is performed only on fully assembled user input. Never normalize partial input or combine normalized input with non-normalized input.
...
When data must be sent to a component in a different trust trusted domain, the sender must ensure that the data is suitable for the receiver's trust boundary by filtering out any sensitive information. For instance, if malicious code manages to infiltrate a system, many attacks will be rendered ineffective if the system's output is appropriately escaped and encoded. Refer to the guideline IDS04-J. Properly encode or escape output for more details.
...