Architecture & DesignJava Language Integrity & Security: Serializing Classes

Java Language Integrity & Security: Serializing Classes

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

This series, The Object-Oriented Thought Process, is intended for someone just learning an object-oriented language and who wants to understand the basic concepts before jumping into the code, or someone who wants to understand the infrastructure behind an object-oriented language he or she is already using. These concepts are part of the foundation that any programmer will need to make the paradigm shift from procedural programming to object-oriented programming.

Compiling the Code

I used a Command Prompt to compile the code. On certain machines, it is called a DOS Shell; on others, it is called a Command Prompt. You can open a Command Prompt in the Programs->Accessories option area.

Type the following code at the command prompt to compile all three of the files. I created a batch file called make.bat to handle this so I don’t have to keep typing in these lines of code. Thus, all I have to do is type out the word make at the C: prompt like this:

C:column31> make

This command will invoke the make.bat file and execute the following lines of code.

"C:Program FilesJavajdk1.5.0_06binjavac"
   -classpath . Employee.java
"C:Program FilesJavajdk1.5.0_06binjavac"
   -classpath . Client.java
"C:Program FilesJavajdk1.5.0_06binjavac"
   -classpath . Server.java

Figure 1 shows the screen shot of what happens when this batch file is executed and the Java files are compiled.

Figure 1: Compiling the Code

At this point, you now will have three class files: Employee.class, Server.class, and Client.class. Employee.class is the class that will be sent over the network; Client.class and Server.class represent the client and server applications respectively. These files are seen in Figure 2.

Figure 2: The application code

Starting the Server

In one of the DOS Shells, type the following line at the command prompt:

"C:Program FilesJavajdk1.5.0_06binjava" –classpath . Server

Figure 3 shows what happens in Command Prompt.

Figure 3: Starting the Server

If everything is working properly, the “Server Waiting” message is displayed. At this point, you can start the Client.

Starting the Client

In a separate DOS Shell, start the Client with the following line.

"C:Program FilesJavajdk1.5.0_06binjava" -classpath . Client

The result is shown in Figure 4.

Figure 4: Starting the Client

If all is well, you will see that the employeeNumber has been updated by the server. The original value of 150 was sent to the server by the client. The server then updated the employeeNumber and sent that value back to the client—which then prints it. You can put some specific identification in the print statements to provide further assurance.

With the circuit complete, the Server should exit cleanly, as shown in Figure 5.

Figure 5: Completing the System

Causing Trouble

Now that the framework for this example is in place, explore a situation that may cause some application integrity and security issues.

It is important to note that the both Client.java and Server.java use the same definition of the Employee class. The Client instantiates the actual Employee object:

Employee joe = new Employee(150);

Whereas the Server creates an Employee reference and uses this as a handle to the Employee object that comes off the network connection; see Diagram 2.

Diagram 2: Passing the Employee object

This represents one of the beauties of dynamically loading classes; the Server can accept a valid Employee object from any Client that chooses to send it one. The operative term here is valid. As you saw in the previous article, the Employee class definition can change without that update being reflected in the Employee class definition that the Server is using. In other words, what happens if the Client and Server both start off with the same Employee class definition but the Client decides to change the Employee class without broadcasting the change to the Server? See what happens.

Separating the Server

To illustrate this, you need to move the Server into a separate directory. The reason for this provides a good demonstration of how classes are dynamically loaded. First, change the Employee class by adding another attribute, the added attribute employeeName in Listing 4.

Listing 4: The Updated Employee Class

import java.io.*;
import java.util.*;

public class Employee implements Serializable {


private int employeeName;
private int employeeNumber; Employee(int num) { employeeNumber = num; } public int getEmployeeNumber() { return employeeNumber ; } public void setEmployeeNumber(int num) { employeeNumber = num; } }

Now, recompile the example; however, do not recompile the Server. This is simple to do by using the rem Command Prompt keyword. This keyword treats the line as a remark, or comment, and will not execute it.

"C:Program FilesJavajdk1.5.0_06binjavac"
   -classpath . Employee.java
"C:Program FilesJavajdk1.5.0_06binjavac"
   -classpath . Client.java
rem "C:Program FilesJavajdk1.5.0_06binjavac"
   -classpath . Server.java

Now, execute the complete system in the exact same way as you did earlier in the article. You should get the exact same results.

This may seem surprising because you did not recompile the Server to reflect the change in the Client. However, don’t forget that the Employee class definition was recompiled and that the Server loads it dynamically—thus, the Server actually did pick up the new version. To really check what happens if the Client and Server have different versions of the Employee class, you need to separate the Server from the Client and make sure that they truly have different versions of the Employee class.

To accomplish this, you can simply create a new directory, call it Server, and place a copy of the original version of the Server and Employee class in this directory. This setup is shown in Figure 6. Note that the only files in this directory are the original version of the Employee class, the Server, and the batch file that starts the Server.

Figure 6: The Separate Server Directory

Now return to the directory that contains the entire application,

C:column31>

The Employee object and the Client include the updated code with the following line—this is absent in the code inside the new server directory.

private int employeeName;

Now, you can start up the Server application from the new directory as seen in Figure 7.

Figure 7: Starting the Original Server

While the Server waits, you now complete the process by starting up the Client with the updated code as seen in Figure 8. Note that the Client application now throws an exception.

Figure 8: Starting the Original Server

The Server also encounters a problem; in fact, it crashes. You get the message:

java.io.InvalidClassException: Employee; local class incompatible:
   stream classd
esc serialVersionUID = 8052846892556280666,
   local class serialVersionUID = 75684
47985707181517

Figure 9: The Server Crashes

This message is generated because the serialVersionUID of the classes do not match. The serialVersionUID is one of the measures used by the Java environment to keep rogue classes from getting inserted into systems.

Note: I will discuss the serialization of objects in great detail in a later article.

Removing the Serializable Interface

Before you spend time getting into detail about how objects are serialized, see what happens when you don’t serialize an object. You may have noticed the following line of code in the Employee class.

public class Employee implements Serializable {

This is how the Sun documentation describes the Serializable interface.

public interface Serializable

Serializability of a class is enabled by the class implementing the java.io.Serializable interface. Classes that do not implement this interface will not have any of their state serialized or deserialized. All subtypes of a serializable class are themselves serializable. The serialization interface has no methods or fields and serves only to identify the semantics of being serializable.

To allow subtypes of non-serializable classes to be serialized, the subtype may assume responsibility for saving and restoring the state of the supertype’s public, protected, and (if accessible) package fields.

Perhaps the key phrase in this description is saving and restoring and that “the serialization interface has no methods or fields and serves only to identify the semantics of being serializable.” You use the serialization interface to marshal objects over wires when writing to files, networks, and so forth.

Now, eliminate the serialization interface from the Employee class as seen in Listing 5:

Listing 5: The Updated Employee Class

import java.io.*;
import java.util.*;


public class Employee {
private int employeeNumber; Employee(int num) { employeeNumber = num; } public int getEmployeeNumber() { return employeeNumber ; } public void setEmployeeNumber(int num) { employeeNumber = num; } }

Compile all the code just as you did when you initially began with this example.


"C:Program FilesJavajdk1.5.0_06binjavac"
   -classpath . Employee.java
"C:Program FilesJavajdk1.5.0_06binjavac"
   -classpath . Client.java
"C:Program FilesJavajdk1.5.0_06binjavac"
   -classpath . Server.java

When you start up the Server, you get business as usual; however, when you run the Client, you get the exception seen in Figure 10, java.io.NotSerializableException.

Figure 10: The Client Crashes

The NotSerializableException is described in the Java documentation as follows:

public class NotSerializableException extends ObjectStreamException
Thrown when an instance is required to have a Serializable interface. The serialization runtime or the class of the instance can throw this exception.

Based on this exception, you see that you do need to serialize the Employee object by including the Serializable interface. Otherwise, you can’t send the object across the network. Knowing that you need the Serializable interface is one thing; however, what is the Serializable interface and what actually does it do? You will explore this in a future article.

Conclusion

In this article, you reconstructed an example from a previous column in this series and altered it to explain how classes are dynamically loaded over a network. You also demonstrated that there are some potential issues that may lead to compromises in the integrity and security of dynamically loaded classes.

The mechanism for marshalling objects across a wire includes the use of the Serializable interface. You were able to see that if the Serializable interface was not included in the Employee class, an exception was generated—in short, you need to utilize the Serializable interface.

In the future, you will explore the Serializable interface in much greater detail to see exactly what it does and how it is used.

Reference

www.sun.com

About the Author

Matt Weisfeld is a faculty member at Cuyahoga Community College (Tri-C) in Cleveland, Ohio. Matt is a member of the Information Technology department, teaching programming languages such as C++, Java, C#, and .NET as well as various Web technologies. Prior to joining Tri-C, Matt spent 20 years in the information technology industry gaining experience in software development, project management, business development, corporate training, and part-time teaching. Matt holds an MS in computer science and an MBA in project management. Besides The Object-Oriented Thought Process, which is now in its second edition, Matt has published two other computer books, and more than a dozen articles in magazines and journals such as Dr. Dobb’s Journal, The C/C++ Users Journal, Software Development Magazine, Java Report, and the international journal Project Management. Matt has presented at conferences throughout the United States and Canada.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories