Reflection enables a Java program to analyze and modify itself. In particular, a program can discover the values of field variables and change them [Forman 2005], [Sun 2002]. The Java reflection API includes a method that enables fields that are normally inaccessible to be accessed under reflection. The following code prints out the names and values of all fields of an object
someObject of class
A field could be set to a new value as follows:
When the default security manager is used, it prevents fields that are normally inaccessible from being accessed under reflection. The default security manager throws a
java.security.AccessControlException in these circumstances. However,
java.lang.reflect.ReflectPermission can be granted with action
suppressAccessChecks to override this default behavior.
For example, the Java Virtual Machine (JVM) normally protects private members of a class from being accessed by an object of a different class. When a method uses reflection to access class members (that is, uses the APIs belonging to the
java.lang.reflect package), the reflection uses the same restrictions. That is, a foreign object that cannot access private members of a class normally also cannot use reflection to access those members. However, a class with private members but also with a public method that uses reflection to indirectly access those members can inadvertently enable a foreign object to access those private members using the public method, bypassing the intended accessibility restrictions. Consequently, unwary programmers can create an opportunity for a privilege escalation attack by untrusted callers.
The following table lists the APIs that should be used with care [SCG 2009].
APIs That Mirror Language Checks
getAccessible() methods of class
java.lang.reflect.Field are used to instruct the JVM to override the language access checks, they perform standard (and more restrictive) security manager checks and consequently lack the vulnerability discussed in this rule. Nevertheless, these methods should be used only with extreme caution. The remaining
get*() field reflection methods perform only the language access checks and are vulnerable.
Use of reflection complicates security analysis and can easily introduce security vulnerabilities. Consequently, programmers should avoid using the reflection APIs when it is feasible to do so. Exercise extreme caution when the use of reflection is necessary.
In particular, reflection must not be used to provide access to classes, methods, and fields unless those items are already accessible without the use of reflection. For example, the use of reflection to access or modify fields is not allowed unless those fields are already accessible and modifiable by other means, such as through getter and setter methods.
This rule is similar to MET04-J. Do not increase the accessibility of overridden or hidden methods, but it warns against using reflection, rather than inheritance, to subvert accessibility.
Noncompliant Code Example
In this noncompliant code example, the private fields
j can be modified using reflection via a
Field object. Furthermore, any class can modify these fields using reflection via the
zeroField() method. However, only class
FieldExample can modify these fields without the use of reflection.
Allowing hostile code to pass arbitrary field names to the
zeroField() method can
- Leak information about field names by throwing an exception for invalid or inaccessible field names (see ERR01-J. Do not allow exceptions to expose sensitive information for additional information). This example complies with ERR01-J by catching the relevant exceptions at the end of the method.
- Access potentially sensitive data that is visible to
zeroField()but is hidden from the attacking method. This privilege escalation attack can be difficult to find during code review because the specific field or fields being accessed are controlled by strings in the attacker's code rather than by locally visible source code.
Compliant Solution (Private)
When you must use reflection, make sure that the immediate caller (method) is isolated from hostile code by declaring it private or final, as in this compliant solution:
Note that when language access checks are overridden using
java.lang.reflect.Field.setAccessible, the immediate caller gains access even to the private fields of other classes. To ensure that the security manager will block attempts to access private fields of other classes, never grant the permission
ReflectPermission with action
Compliant Solution (Nonreflection)
When a class must use reflection to provide access to fields, it must also provide the same access using a nonreflection interface. This compliant solution provides limited setter methods that grant every caller the ability to zero out its fields without using reflection. If these setter methods comply with all other rules or security policies, the use of reflection also complies with this rule.
Noncompliant Code Example
In this noncompliant code example, the programmer intends that code outside the
Safe package should be prevented from creating a new instance of an arbitrary class. Consequently, the
Trusted class uses a package-private constructor. However, because the API is public, an attacker can pass
Trusted.class itself as an argument to the
create() method and bypass the language access checks that prevent code outside the package from invoking the package-private constructor. The
create() method returns an unauthorized instance of the
In the presence of a security manager
Class.newInstance() method throws a security exception when (a)
s.checkMemberAccess(this, Member.PUBLIC) denies creation of new instances of this class or (b) the caller's class loader is not the same class loader or an ancestor of the class loader for the current class, and invocation of
s.checkPackageAccess() denies access to the package of this class.
checkMemberAccess method allows access to public members and classes that have the same class loader as the caller. However, the class loader comparison is often insufficient; for example, all applets share the same class loader by convention, consequently allowing a malicious applet to pass the security check in this case.
Compliant Solution (Access Reduction)
This compliant solution reduces the access of the
create() method to package-private, preventing a caller from outside the package from using that method to bypass the language access checks to create an instance of the
Trusted class. Any caller that can create a
Trusted class instance using reflection can simply call the
Trusted() constructor instead.
Compliant Solution (Security Manager Check)
This compliant solution uses the
getConstructors() method to check whether the class provided as an argument has public constructors. The security issue is irrelevant when public constructors are present because such constructors are already accessible even to malicious code. When public constructors are absent, the
create() method uses the security manager's
checkPackageAccess() method to ensure that all callers in the execution chain have sufficient permissions to access classes and their respective members defined in package
The disadvantage of this compliant solution is that the class must be granted reflection permissions to permit the call to
Compliant Solution (
This compliant solution uses the
java.beans.Beans API to check whether the
Class object being received has any public constructors:
Beans.instantiate() method succeeds only when the class being instantiated has a public constructor; otherwise, it throws an
IllegalAccessException. The method uses a class loader argument along with the name of the class to instantiate. Unlike the previous compliant solution, this approach avoids the need for any reflection permissions.
CERT Vulnerability #636312 describes an exploit in Java that allows malicious code to disable any security manager currently in effect. Among other vulnerabilities, the attack code exploited the following method defined in
sun.awt.SunToolkit, for Java 7:
This code operates inside a
doPrivileged() block. It then uses the reflection method
Class.getDeclaredField() to obtain a field given the field's class and name. This method would normally be blocked by a security manager. It then uses the reflection method
Field.setAccessible() to make the field accessible, even if it were protected or private. But this method is public, so anyone can call it.
Misuse of APIs that perform language access checks only against the immediate caller can break data encapsulation, leak sensitive information, or permit privilege escalation attacks.
Reflection Bypasses Member Accessibility (Java)
|Avoid using reflection methods
|Changing or bypassing accessibility is security-sensitive
|Implemented (since 4.5.0)
Guideline 9-10 / ACCESS-10: Be aware of standard APIs that perform Java language access checks against the immediate caller
Android Implementation Details
Reflection can be used on Android, so this rule is applicable. Also, the use of reflection may allow a developer to access private Android APIs and so requires caution.