Java Reference
In-Depth Information
Table 1-3.
Methods that use the calling method's class loader
Withtheexception ofthe
loadLibrary()
and
load()
methods,thetabulated methods
do not perform any security manager checks; they delegate security checks to the appro-
priate class loader.
In practice, the trusted code's class loader frequently allows these methods to be in-
voked, 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 un-
trusted code gains visibility to the trusted code. In the absence of such a delegation rela-
tionship, the class loaders would ensure namespace separation; consequently, the untrus-
tedcodewouldbeunabletoobservemembersortoinvokemethodsbelongingtothetrus-
ted code.
The class loader delegation model is fundamental to many Java implementations and
frameworks. Avoid exposing the methods listed in
Tables 1-2
and
1-3
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
onitsown,buttheclassloaderispermittedtodelegatetheclassloadingtoatrustedclass's
class loader, privilege escalation can occur. Furthermore, if the trusted code accepts tain-
tedinputs,thetrustedcode'sclassloadercouldbepersuadedtoloadprivileged,malicious
classes on behalf of the untrusted code.
Classes that have the same defining class loader will exist in the same name-space, but
they can have different privileges depending on the security policy. Security vulnerabil-
ities can arise when privileged code coexists with unprivileged code (or less privileged
