...

The remainder of this chapter describes misuse cases under which Java programs might be exploited, and examples of guidelines which mitigate against these attacks. Not all of the rules apply to all Java language programs; frequently their applicability depend upon how the software is deployed and your assumptions concerning trust.

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.

...

Third-party code should operate in its own trusted domain; any code potentially exported to a third-party — such as libraries — should be deployable in well-defined 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.

Injection Attacks

Data received by a component from a source outside the component's trust boundary may be malicious. Consequently, the program must take steps to ensure that the data are both genuine and appropriate.

...

When data must be sent to a component in a different trusted domain, the sender must ensure that the data is suitable for the receiver's trust boundary by properly encoding and escaping any data flowing across the trust boundary. For example, if a system is infiltrated by malicious code or data, many attacks are rendered ineffective if the system's output is appropriately escaped and encoded.

Capabilities

A capability (known in some systems as a key) is a communicable, unforgeable token of authority. It refers to a value that references an object along with an associated set of access rights. A user program on a capability-based operating system must use a capability to access an object \[Wikipedia 2011\]. 

The term capability was introduced by Dennis and Van Horn \[Dennis 1966\]. The basic idea is that for a program to access an object it must have a special token. This token designates an object and gives the program the authority to perform a specific set of actions (such as reading or writing) on that object. Such a token is known as a capability.

Some rules that involve capabilities include:

Leaking Sensitive Data

A system's security policy determines which information is sensitive. Sensitive data may include user information such as social security or credit card numbers, passwords, or private keys.

...

Java software components 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.

Resource Exhaustion

Denial of service can occur when resource usage is disproportionately large in comparison to the input data that causes the resource usage.

...

An example of a rule for preventing denial of service attacks resulting from resource exhaustion include IDS22-J. Limit the size of files passed to ZipInputStream.

References

\[Dennis 1966\] Jack B. Dennis and Earl C. Van Horn. 1966. Programming semantics for multiprogrammed computations. Commun. ACM 9, 3 (March 1966), 143-155. DOI=10.1145/365230.365252 [http://doi.acm.org/10.1145/365230.365252]

\[Heffley 2004\] Heffley, J. & Meunier, P. “Can Source Code Auditing Software Identify Common Vulnerabilities and Be Used to Evaluate Software Security?” Proceedings of the 37th Annual Hawaii International Conference on System Sciences (HICSS’04) - Track 9 - Volume 9. Island of Hawaii, January 2004. IEEE Computer Society, 2004.