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
.
While most software developers are aware of the threat posed by intentionally malicious or simply curious hackers, few developers understand the extent to which the flaws they introduce into their applications aid and abet those same hackers.

In January of this year, a German software developer identified a design flaw with serious security implications in the recently open sourced Borland InterBase product. This flaw existed in versions of InterBase that stretched back to 1994!

No one had maliciously added the flaw -- a back door in the form of a hardcoded name and password. Instead, the error resulted from an InterBase developer's poor design decision. The application used the hardcoded name and password to access a special InterBase access control database during authentication.

While this mistake represents an extreme case, the lesson it teaches is important: as developers, the way we design our software and implement those designs has a huge impact on the overall security of the applications we build. And, as the example above illustrates, the security flaws we introduce can affect our customers for years.

Looking back

Last month I argued that we must examine security> in the light of three different contexts. These contexts, though distinct, often require solutions that cut across all three. Java application developers must understand the implications their work will have on their solution's security from the perspective of each context.

Both Java and non-Java developers are familiar with the most well-known security context: virtual machine security. This is due to the vast amount of attention the JVM and runtime environment received throughout these technologies' formative years. Virtual machine security encompasses the JVM and the supporting runtime environment. Over the last several years, virtual machine security has solidified and is well respected.

The recent lack of visible flaws in the JVM combined with the fact that the average programmer has little control over JVM security has gradually shifted the focus of Java security from the virtual machine to the application running on top of the virtual machine. The average Java programmer can significantly affect security at this level. This context, the application security context, deals with the design decisions and the deliberate and accidental programming missteps that happen during software development. Of course, not all such flaws compromise application security. We are only interested in those that do.

The final context, the network security context, illuminates the security facets relevant between applications and application components interacting in a distributed environment over a network. Once again, not all flaws introduced here compromise security. We will focus on those that do.

Last month, I looked at the virtual machine security context and demonstrated how flaws in VM security manifest themselves as exploits. This month I will focus on application security. I will describe the most common classes of flaws with an eye toward helping you avoid them. I will conclude with a recent example found in Sun's own code.

  • Print
  • Feedback

Resources