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. When components with differing degrees of trust share data, the data are said to flow across a trust boundary. Because Java allows components under different trusted domains to communicate with each other in the same program, data can be transmitted across a trust boundary. Systems must ensure that data is not transmitted to a component in a different trusted domain if authorized users in that domain are not permitted access to the data. Preventing unauthorized access may be as simple as not transmitting the data, or it may involve filtering sensitive data from data that can flow across a trust boundary, as illustrated by Figure 1--2.

Figure 1--2. Filtering data

Java software components provide many opportunities to output sensitive information. Rules that address the mitigation of sensitive information disclosure include the following:

• Page:
  ERR01-J. Do not allow exceptions to expose sensitive information
• Page:
  FIO13-J. Do not log sensitive information outside a trust boundary
• Page:
  FIO52-J. Do not store unencrypted sensitive information on the client side
• Page:
  IDS03-J. Do not log unsanitized user input
• Page:
  MSC03-J. Never hard code sensitive information
• Page:
  MSC61-J. Do not use insecure or weak cryptographic algorithms
• Page:
  MSC62-J. Store passwords using a hash function
• Page:
  SER03-J. Do not serialize unencrypted sensitive data
• Page:
  SER04-J. Do not allow serialization and deserialization to bypass the security manager
• Page:
  SER06-J. Make defensive copies of private mutable components during deserialization

Type Safety

Java is widely considered to be a type-safe language [[LSOD 02]]. For that reason, it should not be possible to compromise a Java program by misusing the type system. To see why type safety is so important, consider the following types:

public class TowerOfLondon {
  private Treasure theCrownJewels;
  ...
}

public class GarageSale {
  public Treasure myCostumeJewelry;
  ...
}

If these two types could be confused, it would be possible to access the private field theCrownJewels as if it were the public field myCostumeJewelry. More generally, a type confusion attack could allow Java security to be compromised by making the internals of the security manager open to abuse. A team of researchers at Princeton University showed that any type confusion in Java could be used to completely overcome Java’s security mechanisms (see Securing Java, Ch. 5, Sec. 7 [[McGraw 1999]]).

Java’s type safety means that fields that are declared private or protected or that have default (package) protection should not be globally accessible. However, a number of vulnerabilities are built in to Java that enable this protection to be overcome. These should come as no surprise to the Java expert, as they are well documented, but they may trap the unwary.

A field that is declared public may be directly accessed by any part of a Java program and may be modified from anywhere in a Java program (unless the field is declared final). Clearly, sensitive information must not be stored in a public field because it could be compromised by anyone who can access the JVM running the program.