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 2.

Figure 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:

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

Bibliography

[ Seacord 2015 ]	Leaking sensitive data LiveLesson

Attachments: