...

However, certain methods use a reduced-security check that checks only that the calling method has access is authorized rather than checking every method in the call stack. Any code that invokes these methods must guarantee that they cannot be invoked on behalf of untrusted code. These methods are listed in the following table.

...

Because the java.lang.reflect.Field.setAccessible() and getAccessible() methods are used to instruct the Java Virtual Machine (JVM) to override the language access checks, they perform standard (and more restrictive) security manager checks and consequently lack the vulnerability described by this guideline. Nevertheless, these methods should also be used with extreme caution. The remaining set* and get* field reflection methods perform only the language access checks and are consequently are vulnerable.

Class Loaders

Class loaders allow a Java application to be dynamically extended at runtime by loading additional classes. For each class that is loaded, the JVM tracks the class loader that was used to load the class. When a loaded class first refers to another class, the virtual machine requests that the referenced class be loaded by the same class loader that was used to load the referencing class. Java's class loader architecture controls interaction between code loaded from different sources by allowing the use of different class loaders. This separation of class loaders is fundamental to the separation of code: it prevents malicious code from gaining access to and subverting trusted code.

...

In practice, the trusted code's class loader frequently allows these methods to be invoked, whereas the untrusted code's class loader may lack these privileges. However, when the untrusted code's class loader delegates to the trusted code's class loader, the untrusted code gains visibility to the trusted code. In the absence of such a delegation relationship, the class loaders would ensure namespace separation; consequently, the untrusted code would be unable to observe members or to invoke methods belonging to the trusted code.

A problem arises because the The class loader delegation model is fundamental to many Java implementations and frameworks. The best advice is to avoid Avoid exposing the methods listed in the table preceding tables to untrusted code.  ConsiderConsider, for example, an attack scenario where untrusted code is attempting to load a privileged class. If its class loader lacks permission to load the requested privileged class on its own, but the class loader is permitted to delegate the class loading to a trusted class's class loader, privilege escalation can occur because the untrusted code's class loader may lack permission to load the requested privileged class on its own. Furthermore, if the trusted code accepts tainted inputs, the trusted code's class loader could load additional privileged—or even malicious—classes on behalf of the untrusted code.The class loader delegation model is fundamental to many Java implementations and frameworks. Avoid exposing the methods listed in the preceding tables to untrusted code. Consider, for example, an attack scenario where untrusted code is attempting to load a privileged class. If its class loader lacks permission to load the requested privileged class on its own, but the class loader is permitted to delegate the class loading to a trusted class's class loader, privilege escalation can occur. Furthermore, if the trusted code accepts tainted inputs, the trusted code's class loader could be persuaded to load privileged, be persuaded to load privileged, malicious classes on behalf of the untrusted code.

...

This code is insecure because it could load a library on behalf of untrusted code. In essence, the untrusted code's class loader may be able to use this code to load a library even though it lacks sufficient permissions to do so directly. After loading the library, the untrusted code can call native methods from the library, if those methods are accessible, because the doPrivileged block stops any security manager checks from being applied to callers further up the execution chainstack.

Nonnative library code can also be susceptible to related security flaws. Suppose there exists a library that contains a vulnerability that is not directly exposed, perhaps because it lies in an unused method. Loading this library may not directly expose a vulnerability. However, an attacker could then load an additional library that exploits the first library's vulnerability. Moveover, nonnative libraries often use doPrivileged blocks, making them attractive targets.

...

The first goal of the exploit code was to access the private sun.awt.SunToolkit class. However, invoking class.forName() directly on the name of this class would cause a SecurityException to be thrown. Consequently, the exploit code used the following method to get access any class, bypassing the security manager:

...

Oracle mitigated this vulnerability in Java 1.7.0 update 7 by patching the com.sun.beans.finder.ClassFinder.findClass() method. The The checkPackageAccess() method checks the entire call stack to ensure that Class.forName(), in this instance only, fetches classes only on behalf of trusted methods.

...

public static Class forName(String name, boolean initialize,
  ClassLoader loader) /* explicitly specify the classClassLoader loader to use */) throws ClassNotFoundException

Do not use the immediate caller's class loader as the third argument when instances must be returned to untrusted code.

Bibliography

...