Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Classes and class members should be given the minimum access possible so that malicious code has the least chance to manipulate the system.

Noncompliant Code Example

In this noncompliant example, the class publicClass 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 scenario can arise when an evil applet attempts to access the credit card field of another object that is not protected.

Code Block
bgColor#FFcccc
public class publicClassPublicClass {
  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.

Code Block
bgColor#ccccff
private final class privateClassPrivateClass {
  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

Risk Assessment

TODOGranting unnecessary access weakens the security of Java applications.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SCP32 SEC07-J

?? medium ??

probable

?? high

P??

L??

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

Wiki Markup
\[[JLS 05|AA. Java References#JLS 05]\] Section 6.6
"
 Access Control
"
 [http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.6
Image Removed
Sun Secure Coding Guidelines
The Java Tutorial by Mary Campione and Kathy Walrath
]
\[[SCG 07|AA. Java References#SCG 07]\]
\[[Campione 96|AA. Java References#Campione 96]\] [Access Control|http://www.telecom.ntua.gr/HTML.Tutorials/java/javaOO/accesscontrol.
html#protectedcaveatImage Removed
Securing Java, Chapter 3, Java Language Security
html]
\[[McGraw 00|AA. Java References#McGraw 00]\] Chapter 3, Java Language Security Constructs