Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

Secure your Java apps from end to end, Part 2

Don't let flaws compromise application security

By Todd Sundsted, JavaWorld.com, 07/13/01

  • Print
  • Feedback
.

Page 2 of 4

Read the whole series on security contexts:



It is impossible to specifically list all the ways that bad design and poor programming can compromise an application's security. The example in the introduction is only one route. Instead, I will define and describe a handful of categories from which most Java application security vulnerabilities arise. These categories fall into two larger camps: implementation-related and design-related flaws.

Implementation-related flaws

Implementation-related flaws are introduced into an application during implementation. Caused by careless coding, insufficient understanding of requirements, or general lack of skill, implementation-related errors remain hidden because of inadequate testing and review. However, if the design is sound, you can usually fix the flaw without changing the design.

Timing problems

The most pernicious timing problem is the race condition. A race condition occurs when two threads accessing the same resource aren't properly synchronized. Flaws arise when two interacting threads either leave an object in an inconsistent or invalid state, or when malicious code takes advantage of improperly protected resources being used by another thread. Often the solution is as simple as adding proper synchronization.

Insufficient input validation

Input supplied to a process must be validated before it is used. Although some input comes from trusted sources, for safety's sake, all input should be considered to have come from an untrusted, possibly compromised source. Failure to thoroughly validate input can lead to a number of serious security vulnerabilities.

Inadequate randomness

Good cryptography requires a high-quality source of randomness. Many early Netscape Navigator vulnerabilities directly resulted from an insufficiently random source. Keys generated from this source had an effective key length much shorter than their advertised key length and were therefore easier to crack.

On a more mundane note, the predictability (lack of randomness) of many user-supplied passwords makes them easy to guess. Sometimes sound security consists of weeding out weak passwords.

Design flaws

Security vulnerabilities that arise from implementation flaws are bad enough, but even worse are vulnerabilities that surface from poor design decisions, lack of foresight, or insufficient understanding of the language or library features. These flaws often become so intertwined with the application logic that removing them without killing the patient is difficult. The InterBase flaw mentioned above provides an excellent design-flaw example.

Initialization issues

The Java savvy know that the new operator isn't the only way to create new instances. Both deserialization and cloning create fully functional instances. You can use both mechanisms to subvert a class's carefully constructed security by introducing instances that don't play by the rules. It's wise to defeat both cloning and deserialization.

  • Print
  • Feedback

Resources