Page History

Introduction

A software component often contains several subcomponents 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 not the network, while another component can access the network but not the file system. Both _distrustful decomposition_ and  _privilege separation_ \[[Dougherty 2009|AA. Bibliography#Dougherty 2009]\]]  are examples of secure design patterns that recommend designing a system using  mutually untrusting subcomponents to reduce the amount of code that runs with special privileges.

When any two subcomponents having different degrees of trust share data, the data is said to flow across a trust boundary. Because Java allows components under different protection 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 is transmitted to or accepted from third-party code also flows across a trust boundary.

While 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 system-wide security policy. A security auditor can use that definition to determine whether the software adequately supports the security objectives of the application.

Any third-party code should operate in its own security domain and any code exported to a third-party should be deployable in well-defined security domains. The public API can be considered as a trust boundary. Data flowing across a trust boundary should be validated if the publisher does not provide any validation. A subscriber or client need not provide any validation if the data flowing into its trust boundary is appropriate for use as is. In all other cases, inbound data must be validated.

??? Data filtering ensures that sensitive information is captured before it crosses a trust boundary. ???

Data Output

If data must be sent to a component in a different protection domain, the sender must ensure that the data is suitable to 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 futile if the system's output is appropriately escaped and encoded. Refer to the guideline IDS04-J. Properly encode or escape output for more details.

Image Added

Like trust boundaries, the question of what information is sensitive is resolved by the system's security policy. A component cannot define which information is sensitive; it can only provide support for handling information that may potentially be declared sensitive by the system administrator.

Java software components might provide many opportunities to output sensitive information. Several rules address the mitigation of sensitive information disclosure, including EXC06-J. Do not allow exceptions to expose sensitive information and FIO08-J. Do not log sensitive information.

Data Input

Data that is received by a component from a source outside the component's trust boundary may, in fact, be malicious. The program must therefore take steps to ensure that the data is genuine.

Image Added

These steps can include the following:

Validation, in the broadest sense, is the process of ensuring that input data falls within the expected range of valid program input. For example, method arguments must conform not only to the type and numeric range requirements of a method or subsystem, but also contain data that conforms to the required input invariants for that method.

Sanitization: In many cases, the data may be fed directly to some subsystem. Data sanitization is the process of ensuring that data conforms to the requirements of the subsystem to which it are passed. Sanitization also involves ensuring that data also conforms to any security-related requirements regarding leaking or exposure of sensitive data when it is output across a trust boundary. Refer to the related guideline IDS01-J. Sanitize before processing or storing user input 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 the data to its 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 construct a forbidden character sequence. Refer to the guideline IDS02-J. Validate strings after performing normalization 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.

For example, POSIX file systems provide a syntax for expressing file names on the system using paths. A path is a string which indicates how to find any file by starting at a particular directory (usually the current working directory), and traversing down directories until the file is found. A path is canonical if it contains no symbolic links, and no special entries, such as '.' or '..'; as these are handled specially on POSIX systems. Every file accessible from a directory has exactly one canonical path, along with many non-canonical paths.

Many rules address proper filtering of untrusted input, especially when such input is passed to a complex subsystem. For example, see IDS08-J. Prevent XML Injection.

Guidelines

...