Dynamic loading of Java and its security problems

1. What is dynamic loading

Class Loaders is a mechanism for dynamically loading Java classes and resource. It supports the 4 features of Laziness,type-safe linkage,user-defined extensibility and multiple communicating namespaces.

Lazy loading:class only load when needed. This reduces the amount of memory used, can improve the system to reflect the speed;

Type-safe Linkage: Dynamic class loading does not compromise the type safety of the JVM;

User-definable class loading policy: Developers can customize the class loader to control the dynamic class loading process;

Multiple NAMESPACES:JVM allows classes with different class loaders to load the same class name, but different content.

Class loaders existed as early as JDK1.0, and the initial goal was to enable the HotJava browser to load applets. Since then, the dynamic class loading mechanism has been widely applied to other aspects, such as the loading of Servlets in Web application server. The Flaw with class loader in JDK 1.0, version 1.1, has been addressed in JDK 1.2, and its flaw is primarily that writing an incorrect class loader can cause type safety issues.

How the 2.Class loader works

The purpose of class loader is to dynamically load Java classes and resource. Java classes are platform-independent, standard, and have canonical binary file formats. The class file is generated by the compiler and can be loaded by any JVM. The Java class behaves not only as a. class file, but also as a memory buffer, or as a network data stream.

The JVM executes byte code within the class file. But byte code is not the entire contents of a class file, and the class file also contains a symbol table that represents classes, attributes, and method names, as well as references to other classes, properties, and method names within a class. For example, the following class

Class c{

void F () {

D d=new D ();

}

}

Class C refers to D in the class file. In order for the JVM to know what Class D is, the JVM must first load D's class file and create a D class object.

The JVM loads the class file with the ClassLoader and creates a class object. Class loaders are subclass instances of ClassLoader. The Classloader.loadclass method returns a Class object that represents the type of the class, by obtaining a name for the classes. In the above code, if C is loaded with the class loader L, then L is the C loader. The JVM will use L to load all other Java classes referenced by C.

If d is not yet loaded, L will load D:

L.loadclass ("D")

When d is already loaded, the JVM can create an object instance of D.

A Java application can use different types of classloader. For example, in Web Application server, the servlet is loaded using a developer-defined class loader, java.lang.String using the JVM system loader, Bootstrap class Loader, Other classes defined by the developer are loaded by Appclassloader. In the JVM, different Java types are distinguished by class name and ClassLoader. As a result, the JVM allows us to load Java classes of the same namespace with different loaders, while in fact these same namespace Java classes can be completely different classes. This mechanism ensures that the java.lang.String that the JDK comes with is unique.

The process for each ClassLoader loading class is:
1. Check if this class is loaded (that is, if there is this class in the cache), if there is 8, if not to 2
2. If the parent ClassLoader does not exist (without the parent, the parent must be bootstrap ClassLoader), to 4
3. Request the parent ClassLoader to load, if successful to 8, unsuccessful to 5
4. Request that the JVM be loaded from bootstrap ClassLoader if successful to 8
5. Look for the class file (from the classpath associated with this classloader). If not found then to 7.
6. Load class from file to 8.
7. Throw classnotfoundexception.
8. Return to class.

3.JVM Native Class loader principle

When the JVM (Java Virtual machine) starts, it forms an initial ClassLoader hierarchy consisting of three classloader:

Bootstrap classloader-> extension classloader-> system ClassLoader

Bootstrap ClassLoader-Boot (also known as primitive) class loader, which is responsible for loading Java's core classes. In Sun's JVM, you can specify additional classes by using the-xbootclasspath option in a command that executes Java or by using the-D option to specify Sun.boot.class.path system property values. This loader is very special, it is not actually a subclass of Java.lang.ClassLoader, but is implemented by the JVM itself. You can get bootstrap ClassLoader loaded with those core class libraries by executing the following code:
Url[] Urls=sun.misc.launcher.getbootstrapclasspath (). Geturls ();
for (int i = 0; i < urls.length; i++) {
System.out.println (Urls.toexternalform ());
}

Extension ClassLoader-the extension classloader, which is responsible for loading the class pack of the jar in the JRE's extended directory (Java_home/jre/lib/ext or specified by the Java.ext.dirs system properties). This provides a standard mechanism for introducing new functionality beyond the Java core class. Because the default extension directory is common to all JVMs that are launched from the same JRE, the jar class package that is placed in this directory is visible to all JVM and system ClassLoader.

Calling the method on this instance getparent () always returns null NULL, because the bootloader bootstrap ClassLoader is not a true ClassLoader instance. So when you execute the following code:
System.out.println (System.getproperty ("Java.ext.dirs"));
ClassLoader Extensionclassloader=classloader.getsystemclassloader (). GetParent ();
System.out.println ("The parent of Extension ClassLoader:" +extensionclassloader.getparent ());

Extension ClassLoader is the parent of the system ClassLoader, and Bootstrap ClassLoader is the parent of extension ClassLoader, But it is not an actual classloader, so it is null.

System ClassLoader-Systems (also known as applications) ClassLoader, which is responsible for when the JVM is started, Loads the jar class package and classpath from the-classpath or Java.class.path system properties or classpath operating system properties specified in command java. The ClassLoader can always be found through the static method Classloader.getsystemclassloader (). If not specifically specified, any classloader that the user customizes will use the ClassLoader as its parent loader. Execute the following code to get:
System.out.println (System.getproperty ("Java.class.path"));
The output is the Classpath set by the user in the System properties.

4. Security issues

For example, if the jar file is loaded with the same namespace class as the parent class loader, but Java version does not match, then it is easy to cause class security problems.

You can load the jar with the load order of class loader and change the "parent first" rule.

 PublicClassLoader Getdsclassloader (String moudlename) {if(Dsclassloader = =NULL) {            Try{Dsclassloader=NewMcfclassloader (Newurl[] {NewURL ("... xxx.jar")),                               NewURL ("... yyy.jar"))}, Connectorconfigurationparserserviceimpl.class. getClassLoader ()); } Catch(malformedurlexception e) {//TODO auto-generated Catch blockE.printstacktrace (); }        }        returnDsclassloader; }

 PublicClassLoader Getdsclassloader (String moudlename) {if(Dsclassloader = =NULL) {            Try{Dsclassloader=NewMcfclassloader (Newurl[] {NewURL ("... xxx.jar")),                               NewURL ("... yyy.jar"))}, Connectorconfigurationparserserviceimpl.class. getClassLoader ()); } Catch(malformedurlexception e) {//TODO auto-generated Catch blockE.printstacktrace (); }        }        returnDsclassloader; }

Dynamic loading of Java and its security issues