Classes and class members (classes, interfaces, fields and methods) are subject to access control in Java. 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.
...
Classes and class members should be given the minimum access possible so that malicious code has the least chance to manipulate of manipulating 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. AlsoAdditionally, even if a class's visibility is default, it can be susceptible to misuse if it exposes a public method.
...
In this noncompliant example, the class PublicClass has been is declared public. This may well be necessary. However, the The member function getPoint as well as the (x, y) coordinates are also declared public. This gives world-access to the class members. A real world exploit vulnerability, for example, can arise , when a malicious applet attempts to access the credit card field of another object that is not protecteddeclared public. Note that a non-public class may also be vulnerable if its members are declared public.
| Code Block | ||
|---|---|---|
| ||
public class PublicClass {
public int x;
public int y;
public void getPoint() {
System.out.println("(" + x + "," + y + ")");
}
}
|
...
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 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 access conditions are demonstrated in this compliant solution.
| Code Block | ||
|---|---|---|
| ||
final class PrivateClass {
private int x;
private int y;
private void getPoint() {
System.out.println("(" + x + "," + y + ")");
}
}
|
...
Noncompliant Code Example
This noncompliant code example overrides the finalize() method of the superclass and changes its accessibility from protected to public.
According to Sun's Secure Coding Guidelines [[SCG 07]]:
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.
| Code Block | ||
|---|---|---|
| ||
final class SubClass extends Base {
public void finalize() {
// ...
}
}
|
Compliant SOlution
This compliant solution correctly declares the finalize() method protected.
| Code Block | ||
|---|---|---|
| ||
final class SubClass extends Base {
protected void finalize() {
// ...
}
}
|
Risk Assessment
Granting unnecessary access weakens the security of Java applications.
...