Featured White Papers

• What Developers Want: The End of Application Redeploys

Sponsored Links

• Career opportunities at Harman- Careers That’ll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

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

Twelve rules for developing more secure Java code

Writing security-conscious Java code can help you avoid security surprises

By Gary Mcgraw and Edward Felten, JavaWorld.com, 12/01/98

Page 2 of 5

• Make all static variables private. If you want to allow outside code to access static variables in the class, this should be done via static get and set methods. This keeps outside code from accessing noninitialized static variables. If you're following Rule 3, you'll make the get and set methods final.
  
  
• Add a new private static boolean variable, classInitialized, to the class.
  
  
• Have the static constructor set the initialized variable as its last action before returning.
  
  
• Before doing anything, have each static method and each constructor verify that classInitialized is true. (Note: constructors are required to call a constructor of the superclass, or another constructor of the same class, as their first action. So you will have to do that before you check classInitialized.)

Rule 2: Limit access to your classes, methods, and variables

Every class, method, and variable that is not private provides a potential entry point for an attacker. By default, everything should be private. Make something nonprivate only with good reason, and document that reason.

Rule 3: Make everything final (unless there's a good reason not to)

If a class or method isn't final, an attacker could try to extend it in a dangerous and unforeseen way. By default, everything should be final. Make something nonfinal only if there is a good reason, and document that reason.

You might think you can prevent an attacker from extending your class or its methods by declaring the class nonpublic. But if a class isn't public, it must be accessible from within the same package, and as Rule 4 (below) says, you shouldn't to rely on package scope access restrictions for security.

This advice may seem harsh. After all, the rule is asking you to give up extensibility, which is one of the main benefits of using an object-oriented language like Java. But when you're trying to provide security, extensibility is your enemy: it just provides an attacker with more ways to cause trouble.

Rule 4: Don't depend on package scope

Classes, methods, and variables that aren't explicitly labeled as public, private, or protected are accessible within the same package. Don't rely on this for security. Java classes aren't closed, so an attacker could introduce a new class into your package and use this new class to access the things you thought you were hiding. (A few packages, such as java.lang, are closed by default, and a few Java virtual machines (JVMs) let you close your own packages. But you're better off assuming packages aren't closed.)

Package scope makes a lot of sense from a software-engineering standpoint, since it prevents innocent, accidental access to things you want to hide. But don't depend on it for security.

Maybe we'll get sealed classes in the future.

Rule 5: Don't use inner classes

Some Java language books say inner classes can be accessed only by the outer classes that enclose them. But this isn't true. Java bytecode has no concept of inner classes, so inner classes are translated by the compiler into ordinary classes that happen to be accessible to any code in the same package. And Rule 4 says not to depend on package scope for protection.