Java uses security managers and security policies together to prevent untrusted code from performing privileged operations. In standard installations, a restrictive systemwide security policy prevents instantiation of sensitive classes such as java.lang.ClassLoader, for example, in the context of a web browser, for example. It remains critically important to ensure that untrusted code cannot indirectly use the privileges of trusted code to perform privileged operations.
Most APIs install security manager checks to prevent such privilege escalation attacks; some APIs fail to do so. These APIs are tabulated below. Note, however, that the loadLibrary and load APIs throw a security exception when the caller lacks permission to dynamically link the library code. These APIs are nevertheless listed as unsafe because they use the immediate caller's class loader to find and load the requested library. Moreover, because the loadLibrary and load APIs are typically used from within a doPrivileged block defined in trusted code, untrusted callers can directly invoke it without requiring any special permissions.in the following table.
APIs |
|---|
|
|
|
|
|
|
|
|
|
|
The loadLibrary and load APIs throw a security exception when the caller lacks permission to dynamically link the library code. These APIs are nevertheless listed as unsafe because they use the immediate caller's class loader to find and load the requested library. Moreover, because the loadLibrary and load APIs are typically used from within a doPrivileged block, unprivileged callers can directly invoke it without requiring any special permissions.
These APIs perform tasks using the immediate caller's class loader. They can be exploited when (1) they are invoked indirectly by untrusted code and/ or (2) when they accept tainted inputs from untrusted code.
...