|
Rule 1: Avoid Using Inner Classes
Take the first step in a set of guidelines that can help you begin a strategy to ensure your Java code is secure
by Adam Kolawa, Ph.D., Gina Assaf, and Roberto Scaramuzzi, Ph.D.
Posted March 10, 2004
Editor's Note: Beginning with this article, Java Pro Online will be posting a weekly rule for ensuring the security of Java systems. This discussion provides the first rule you can follow to begin your strategy for ensuring your Java applications are secure. Look for more rules in upcoming postings. See the entire index of Java code security rules here.
Java-based systems are typically n-tier systems with many parts and complex interactions; if a hacker can find a vulnerability in just one of those parts or interactions, the entire system's security could be compromised. If you want to ensure that your Java system is secure, you need to anticipate every possible way your system can be attacked and ensure that the system is protected against every potential attack.
Beginning with this posting, we'll present a weekly series of rules that will help you prevent some of the most common attacks. Of course, ensuring that every part of your system is hacker-proof is a monumental task, and beyond the scope of this discussion. However, the rules we present should be the beginning of your security strategy—not your entire security strategy. We have also included an extensive list of resources you can use to learn more about security and determine what additional security measures might be required to safeguard your system. By ensuring that your code complies with these coding rules, you can make your code less vulnerable to security attacks.
This first rule prohibits the use of inner classes. Java bytecode has no concept of inner classes, so the compiler translates inner classes into ordinary classes that are accessible to any code in the same package. An inner class gets access to the fields of the enclosing outer class—even if these fields are declared private—and the inner class is translated into a separate class. To let this separate class access the fields of the outer class, the compiler silently changes these fields' scope from private to package. As a result, when you use inner classes, you not only have the inner class exposed, but you also have the compiler silently overruling your decision to make some fields private.
Note that if you really need to use inner classes, then be sure to follow rule 2 (make all inner classes private).
Here is sample code that violates the first rule:
package examples.rules.security;
public class AUIC {
private class AUIC2 {
// VIOLATION
}
}
To correct this code, make the class AUIC2 a top-level class:
public class AUICF {
}
class AUIC2 { // FIXED
}
Rule source: "Twelve Rules for Developing More Secure Java Code" Gary McGraw and Edward Felten. JavaWorld (December, 1998)
About the Author
Adam Kolawa, Ph.D, is the chairman and CEO of Parasoft. He is a writer and speaker on industry issues and in 2001 was awarded the Los Angeles Ernst & Young Entrepreneur of the Year Award in the software category. Gina Assaf has been developing, designing, testing, and implementing applications in Java for over six years, and has researched and developed coding standards for Parasoft, many of which provide security for Java applications. Roberto Scaramuzzi, Ph.D., is a Java and Perl Developer for Parasoft in San Diego, California. Born in Italy, he later moved to the United States to obtain his doctorate in Mathematics from Yale University. Contact the authors at .
Back to top
|