...
Note that the language access checks do not apply to java.lang.reflect.Field.setAccessible/getAccessible
methods but to the remaining set*
and get*
field methods. The former APIs are protected by standard security manager checks.
Noncompliant Code Example
In this noncompliant code snippet, the package-private field i
of class C
can be accessed from class ReflectionExample
. Method makeAccessible
accepts fieldName
as an input parameter which can be supplied by untrusted code. This is dangerous because despite the untrusted code not having the same capabilities as that of the immediate caller (method makeAccessible
), it is allowed to carry out sensitive operations. In this case, the immediate caller has the capability of modifying package-private fields without triggering any language access checks. Hostile code should not be allowed to make such modifications by using it as an oracle.
Code Block | ||
---|---|---|
| ||
// Class 'ReflectionExample' and 'C' belong to the same package public class ReflectionExample { public static void makeAccessible(String fieldName) { C c = new C(); try { Field f = c.getClass().getDeclaredField(fieldName); System.out.println(f.getInt(c)); // prints 10 f.setInt(c, 1); // set to 1; bypasses language access checks System.out.println(f.getInt(c)); // now prints 1 } catch(NoSuchFieldException nsfa){} catch(IllegalAccessException iae) {} } } class C { int i = 10; // package-private } |
Compliant Solution
Do not operate on tainted inputs provided by untrusted code. Likewise, do not return values to an untrusted caller. If you must use Reflection, make sure that the immediate caller (method) is isolated from hostile code by declaring it final
, reducing it's scope to private
and making it non-static
. Also, declare sensitive fields in other classes (Class c
) as private
.
...
The permission ReflectPermission
with action suppressAccessChecks
should also not be granted so that the security manager blocks attempts to access private fields of other classes. (See SEC32-J. Do not grant ReflectPermission with action suppressAccessChecks)
Noncompliant Code Example
The class Trusted
uses a package-private constructor in this noncompliant code example. It is desired that the code that exists outside the package be not allowed to create a new instance of an arbitrary class. However, since the API is public
, it fails to achieve this condition. The bigger problem is that the attacker can exploit the method to create an instance of an arbitrary class as opposed to a trusted class.
Code Block | ||
---|---|---|
| ||
public class Trusted { Trusted() { } public static <T> T create(Class<T> c) throws Exception { return c.newInstance(); } } |
Compliant Solution
Code Block | ||
---|---|---|
| ||
TODO |
Risk Assessment
Misuse of APIs that perform language access checks against the immediate caller only, can break data encapsulation.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
SEC04-J | high | probable | medium | P12 | L1 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
Wiki Markup |
---|
\[[Chan 99|AA. Java References#Chan 99]\] java.lang.reflect AccessibleObject \[[SCG 07|AA. Java References#SCG 07]\] Guideline 6-4 Be aware of standard APIs that perform Java language access checks against the immediate caller |
...