
Every primitive data type and object reference in Java has an access specifier. The general access control rules are summarized below. An 'x' conveys that the particular access is permitted from within that domain.
Access Specifier |
class |
sub-class |
package |
world |
---|---|---|---|---|
private |
x |
|
|
|
private protected |
x |
x |
|
|
protected |
x |
x* |
x |
|
public |
x |
x |
x |
x |
friendly |
x |
|
x |
|
default |
x |
x |
x |
|
*For referencing protected members, the accessing class has to be a sub-class and should also be in the same package.
Non-Compliant Code Example
In this non-compliant example, the class publicClass
has been declared public. Moreover, the member function getPoint
as well as the (x.y)
coordinates are public. This gives world-access to the class members. A real world scenario can arise when an evil applet attempts to access the credit card field of another object that is not protected.
public class publicClass { public int x; public int y; public void getPoint() { System.out.println("(" + x + "," + y + ")"); } }
Compliant Solution
Limiting the scope of classes, interfaces, methods and fields as far as possible reduces the chance of malicious manipulation. Restrictive access should be granted to limit the visibility depending on the desired implementation scope. This also helps eliminate the threat of a malicious method overriding some legitimate method. The most restrictive condition is demonstrated in this compliant solution.
private final class privateClass { private int x; private int y; private void getPoint() { System.out.println("(" + x + "," + y + ")"); } }
"In addition, refrain from increasing the accessibility of an inherited method, as doing so may break assumptions made by the superclass. A class that overrides the protected java.lang.Object.finalize method and declares that method public, for example, enables hostile callers to finalize an instance of that class, and to call methods on that instance after it has been finalized. A superclass implementation unprepared to handle such a call sequence could throw runtime exceptions that leak private information, or that leave the object in an invalid state that compromises security. One noteworthy exception to this guideline pertains to classes that implement the java.lang.Cloneable interface. In these cases, the accessibility of the Object.clone method should be increased from protected to public." Sun Java Secure Coding Guidelines, guideline 1-1
References
JLS Chapter 6 http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.6.6
Sun Secure Coding Guidelines
The Java Tutorial by Mary Campione and Kathy Walrath http://www.telecom.ntua.gr/HTML.Tutorials/java/javaOO/accesscontrol.html#protectedcaveat
Securing Java, Chapter 3, Java Language Security Constructs