
Classes and class members (classes, interfaces, fields and methods) are subject to access control. The access is indicated by an access modifier: public
, protected
, private
, or the absence of an access modifier (the default access). A simplified view of the access control rules is summarized in the following table. An 'x' conveys that the particular access is permitted from within that domain.
Access Specifier |
class |
package |
sub-class |
world |
---|---|---|---|---|
private |
x |
|
|
|
none |
x |
x |
|
|
protected |
x |
x |
x* |
|
public |
x |
x |
x |
x |
*For referencing protected members, the accessing class can be a sub-class in either the same or a different package.
Classes and class members should be given the minimum access possible so that malicious code has the least chance to manipulate the system. As far as possible, sensitive classes should avoid implementing interfaces. This is because only public
methods are allowed to be declared within interfaces.
Noncompliant Code Example
In this noncompliant example, the class PublicClass
has been declared public. This may well be necessary. However, the member function getPoint
as well as the (x, y)
coordinates are public. This gives world-access to the class members. A real world exploit for example, can arise, when a malicious 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 accessibility 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.
final class PrivateClass { private int x; private int y; private void getPoint() { //private constructor 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]]
Risk Assessment
Granting unnecessary access weakens the security of Java applications.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
SEC07-J |
medium |
likely |
medium |
P12 |
L1 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[JLS 05]] Section 6.6, Access Control
[[SCG 07]] Guideline 1-1 Limit the accessibility of classes, interfaces, methods, and fields
[[Campione 96]] Access Control
[[McGraw 00]] Chapter 3, Java Language Security Constructs
[[Bloch 08]] Item 13: Minimize the accessibility of classes and members
SEC06-J. Assume that all Java clients can be reverse engineered, monitored, and modified 00. Security (SEC) SEC30-J. Always use a Security Manager