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.
Figure 6: No CheckingAccount class.
Now, copy the rogue CheckingAccount class into the actual application directory. After you do this, the directory will contain the CheckingAccount class, as seen in Figure 7.
Figure 7: Rogue CheckingAccount class inserted.
Just by looking at the directory, there is nothing suspicious. It looks like the original and intended copy of the CheckingAccount class. Yet, you know that this is actually a rogue version of CheckingAccount. If you run the application, you get the output seen in Figure 8.
Figure 8: Rogue CheckingAccount class ouput.
As you can see, the account balance now is valued at 2,000,000, not the intended 1,000,000.
Although this is a very simplistic and contrived example, it illustrates the vulnerability that exists when classes are loaded dynamically. If this were a statically linked application, the only way to hack into the application would be to edit the executable code and alter it directly. On top of that problem, each of the distributed executable files would have to be altered (and distributed) as well. In other words, if a statically linked application is distributed (say, a Windows EXE file) to 100 customers, each of the 100 EXE files would have to be tracked down and altered.
However, if a dynamically loaded class is used (in this case, assume that the class is loaded over an Internet connection, perhaps a web page), theoretically the class need be changed only in one place. This is what is meant by other distribution possibilities. It is not simply a case of creating a rogue class on the same machine, or even with a single project. The rogue class can be created and substituted over an Internet connection or any other network connection. It may even be as simple as substituting in a single location, say a server, because in this case all clients will access the same server and thus the same class.
Diagram 3: Inserting a rogue class file.
There are built-in measures that are in place to allow the virtual machine to identify situations when the class has been tampered with or innocently changed and incorrectly distributed. This is very evident when class IDs are changed and sent over a network. You will explore several of these scenarios in future articles.
This article covered the basic concept of how classes are dynamically loaded and how this relates to both performance and security. Dynamically loaded classes provide a very substantial performance boost to application development. However, as is often the case, there are some downsides as well; in this case, some security concerns need to be addressed.
It is very helpful to try and create some simple applications and try to produce the results that you covered in this article. As is always the case, experimenting with code firsthand will greatly benefit the learning process. As an added incentive, the lines of code required to illustrate these issues are very small.
In the next article, you will explore how the built-in measures that the compiler and Virtual Machine possess keep security problems for dynamically loaded classes to a minimum.
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.