Shulou(Shulou.com)06/03 Report--

This article mainly introduces "Why not use Java serialization". In daily operation, I believe many people have doubts about why they do not use Java serialization. The editor consulted all kinds of data and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "Why not use Java serialization"! Next, please follow the editor to study!

As a Java developer, why do I recommend that you avoid using Java serialization in your development?

Nowadays, most of the back-end services are based on the micro-service architecture, and the services are split according to the business division, which not only decouples the services, but also brings some new problems, such as the communication between different businesses needs to be called through the interface. In order to share a data object between two services, it is necessary to convert the object into a binary stream, transmit it through the network, transmit it to each other's service, and then convert it into an object for the service method to call. This encoding and decoding process is called serialization and deserialization.

In high concurrency systems, the speed of serialization will affect the response time of requests, and the large volume of serialized transmission data will lead to a decline in network throughput. Therefore, an excellent serialization framework can improve the overall performance of the system.

We all know that Java provides a RMI framework for service-to-service interface exposure and invocation, and Java serialization is used for data object serialization in RMI. However, Java serialization is rarely used in mainstream frameworks, such as Json serialization used by SpringCloud. Although Dubbo is compatible with Java serialization, Hessian serialization is still used by default.

Java serialization

First, let's take a look at what Java serialization and implementation principles are. Java provides a serialization mechanism that serializes an object into binary form, which can be written to disk or output to the network, while the byte array read from the network or disk is deserialized into an object and used in the program.

The two input and output stream objects ObjectInputStream and ObjectOutputStream provided by JDK can only deserialize and serialize objects of classes that implement the Serializable interface.

The default serialization method of ObjectOutputStream, which serializes only the non-transient instance variables of the object, not the transient instance variables of the object, nor the static variables.

In an object of a class that implements the Serializable interface, a serialVersionUID version number is generated. What is the use of this version number? It verifies that the serialized object loads the deserialized class during deserialization, and if it is a class with the same class name and a different version number, the object cannot be obtained in deserialization.

The specific implementation of serialization is writeObject and readObject, usually these two methods are the default, we can also override them in the class that implements the Serializable interface to customize our own serialization and deserialization mechanisms.

Two override methods are also defined in the Java serialization class: writeReplace (), which is used to replace the serialized object before serialization, and readResolve (), which is used to process the returned object after serialization.

Java serialization defect

We rarely find the serialization provided by JDK in the used RPC communication framework, mainly because the default serialization of JDK has the following defects: unable to cross languages, easy to be attacked, too large serialized stream, poor serialization performance and so on.

1. Unable to cross languages

At present, many systems have high complexity and use multiple languages to code, but Java serialization only supports the framework implemented in Java language. Most other languages do not use Java serialization framework and do not implement Java serialization protocol. Therefore, if two applications written based on different languages communicate, use Java serialization It is not possible to serialize and deserialize the transfer objects between two application services.

two。 Vulnerable to attack

The Java official website security coding guidelines state that "deserialization of untrusted data is inherently dangerous and should be avoided." You can see that Java serialization is not secure.

We know that objects are deserialized by calling the readObject () method on ObjectInputStream, which is actually a magic constructor that instantiates almost all objects on the classpath that implement the Serializable interface. This means that this method can execute any type of code in the process of deserializing the byte stream, which is very dangerous.

For objects that need to be deserialized for a long time, you don't need to execute any code to launch an attack. An attacker can create a chain of circular objects and then transfer the serialized object to the program for deserialization, which can cause the number of calls to the hashCode method to explode to the power and cause a stack overflow exception. For example, the following case can be well illustrated.

Set root = new HashSet (); Set S1 = root; Set S2 = new HashSet (); for (int I = 0; I < 100; iTunes +) {Set T1 = new HashSet (); Set T2 = new HashSet (); t1.add ("test"); / / make T2 not equal to T1 s1.add (T1); s1.add (T2); s2.add (T1); s2.add (T2); S1 = T1 S2 = T2;}

As mentioned in a previous paper by the FoxGlove Security security team: it can be exploited through Apache Commons Collections,Java deserialization vulnerabilities, which once swept the latest versions of WebLogic, WebSphere, JBoss, Jenkins and OpenNMS, and the major Java Web Server lay guns one after another.

In fact, Apache Commons Collections is a third-party basic library, which extends the Collection structure in the Java standard library, provides many powerful data structure types, and implements a variety of collection tool classes.

The principle of the attack: Apache Commons Collections allows chain-like arbitrary class functions to reflect calls. The attacker uploads the attack code to the server by implementing the port of the Java serialization protocol, and then executes the attack code by the TransformedMap in Apache Commons Collections.

How to solve this loophole?

Many serialization protocols have developed a set of data structures to store and retrieve objects. For example, JSON serialization, ProtocolBuf, and so on, only support some basic types and array data types, which can avoid deserialization to create some uncertain instances. Although their design is simple, they are sufficient to meet the data transmission needs of most current systems. We can also control deserialization objects by deserializing the whitelist of objects. We can override the resolveClass method and verify the object name in that method. The code is as follows:

@ Override protected Class resolveClass (ObjectStreamClass desc) throws IOException,ClassNotFoundException {if (! desc.getName (). Equals (Bicycle.class.getName () {throw new InvalidClassException ("Unauthorized deserialization attempt", desc.getName ());} return super.resolveClass (desc);}

3. The serialized stream is too large

The serialized binary stream size reflects the performance of serialization. The larger the serialized binary array, the more storage space is consumed and the higher the cost of storage hardware. If we are carrying out network transmission, we will occupy more bandwidth, which will affect the throughput of the system.

ObjectOutputStream is used in Java serialization to convert objects to binary encoding, so is there any difference between the size of the binary array encoded by this serialization mechanism and the size of the binary array implemented by ByteBuffer in NIO?

We can verify it with a simple example:

User user = new User (); user.setUserName ("test"); user.setPassword ("test"); ByteArrayOutputStream os = new ByteArrayOutputStream (); ObjectOutputStream out = new ObjectOutputStream (os); out.writeObject (user); byte [] testByte = os.toByteArray (); System.out.print ("ObjectOutputStream byte code length:" + testByte.length + "\ n"); ByteBuffer byteBuffer = ByteBuffer.allocate (2048); byte [] userName = user.getUserName (). GetBytes (); byte [] password = user.getPassword (). GetBytes () ByteBuffer.putInt (userName.length); byteBuffer.put (userName); byteBuffer.putInt (password.length); byteBuffer.put (password); byteBuffer.flip (); byte [] bytes = new byte [byteBuffer.remaining ()]; System.out.print ("ByteBuffer byte code length:" + bytes.length+ "\ n")

Running structure:

ObjectOutputStream byte encoding length: 99 ByteBuffer bytes encoding length: 16

Here we can clearly see that the binary array size of the binary coding implemented by Java serialization is several times larger than the binary array size of the binary coding implemented by ByteBuffer. Therefore, the flow after the Java sequence will become larger, which will eventually affect the throughput of the system.

4. Poor serialization performance

The speed of serialization is also an important indicator of serialization performance. If the serialization speed is slow, it will affect the efficiency of network communication and increase the response time of the system. Let's use the above example to compare the performance of Java serialization with ByteBuffer encoding in NIO:

User user = new User (); user.setUserName ("test"); user.setPassword ("test"); long startTime = System.currentTimeMillis (); for (int iTuno; I

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.