by Christopher Stone
Before you write any applets or programs with Java, it is important to understand how Java works. This chapter introduces you to the actual language, the limitations of the language (intentional and unintentional), and how code can be made reusable.
Strictly speaking, Java is interpreted, although in reality Java is both interpreted and compiled. In fact, only about 20 percent of the Java code is interpreted by the browser—but this is a crucial 20 percent. Both Java’s security and its ability to run on multiple platforms stem from the fact that the final steps of compilation are handled locally.
A programmer first compiles Java source into bytecode using the Java compiler. This bytecode is binary and architecturally neutral (or platform independent—both work equally well). The bytecode isn’t complete until it’s interpreted by a Java runtime environment: usually a browser. Because each Java runtime environment is for a specific platform, the final product will work on that specific platform.
This platform-specific feature of Java is good news for developers. It means that Java code is Java code is Java code, no matter what platform you’re developing for or on. You could write and compile a Java applet on your UNIX system and embed the applet into your Web page. Three different people on three different machines—with their own environments —can take a peek at your new applet. Provided that each of those people run a Java-capable browser, it wouldn’t matter whether they are on an IBM, HP, or Macintosh. Using Java means that only one source of Java code needs to be maintained for the bytecode to run on a variety of platforms. One pass through a compiler for multiple platforms is good news for programmers.
Be aware that because Java bytecode is interpreted, Web pages with applets frequently take much longer to load than those without. This greater amount of time is because the bytecode that will become the applets or stand-alone application you see contains more compile-time data than is typically used in noninterpreted situations. The bytecode is downloaded to your system, much as the HTML code or images that make up a Web page are downloaded. Then a series of runtime procedures check its security or robustness. Java’s portability is almost limitless at the expense of performance.
This deficiency is being overcome as Just-in-Time, or JIT, compilers are written. A just-in-time compiler compiles Java methods to native code for the platform you're using. Without the JIT compiler, methods are not translated to native code, but remain in the original machine-independent bytecode. This bytecode is interpreted on any platform by the Java Virtual Machine. A Java application is portable, but the just-in-time compiler itself cannot be portable, because it generates native code specific to a platform, exactly as you need a different version of the virtual machine for each new platform. So far, both Netscape Navigator 3.0 and Microsoft’s Internet Explorer 3.0 browsers are using JIT compilers.
Why is this combination of compilation and interpretation a positive feature?
The fact that the final portion of compilation is being accomplished by a platform-specific device, which is maintained by the end-user, relieves you of the responsibility of maintaining multiple sources for multiple platforms. Interpretation also allows data to be incorporated at runtime, which is the foundation of Java’s dynamic behavior.
Java is an object-oriented language. Therefore, it’s part of a family of languages that focuses on defining data as objects and the methods that may be applied to those objects. As I’ve said, Java and C++ share many of the same underlying principles; they just differ in style and structure. Simply put, object-oriented programming languages (OOP, for short) describe interactions among data objects. To make an analogy using medicine, object-oriented doctors would be interested in holistic medicine—examining the body (or object) as a whole first and then determining the proper vaccines, diets, and medicine (the tools) to improve your health after that. Non object-oriented doctors would think primarily of their tools.
Many OOP languages support multiple inheritance, which can sometimes lead to confusion or unnecessary complications. Java doesn’t. As part of its less-is-more philosophy, Java supports only single inheritance. That means each class can inherit from only one other class at any given time. This type of inheritance avoids the problem of a class inheriting classes whose behaviors are contradictory or mutually exclusive. Java allows you to create totally abstract classes known as interfaces. Interfaces allow you to define methods that you can share with several classes, without regard for how the other classes are handling the methods.
Each class, abstract or not, defines the behavior of an object through a set of methods. All of the code used for Java is divided into classes. Methods can be inherited from one class to the next, and at the head of the class hierarchy is the class called Object. The Object class belongs to the java.lang package of the Java Core API. You are introduced in the last section of this chapter to the Java Core API.
Objects can also implement any number of interfaces (or abstract classes). The Java interfaces are a lot like the Interface Definition Language interfaces. This similarity means it’s easy to build a compiler from IDL to Java.
That compiler could be used in the Common Object Request Broker Architecture, or CORBA, system of objects to build distributed object systems. Is this good? Yes. Both IDL interfaces and the CORBA system are used in a wide variety of computer systems, and this variety facilitates Java’s platform independence.
As part of the effort to keep Java simple, not everything in this object-oriented language is an object. Booleans, numbers, and other simple types are not objects, but Java does have wrapper objects for all simple types. Wrapper objects allow all simple types to be implemented as though they are classes. It is important to remember that Java is unforgivingly object-oriented; it simply does not allow you to declare anything that is not encapsulated in an object. Even though C++ is considered an OOP language, it allows you to develop bad habits and not encapsulate types.
Object-oriented design is also the mechanism that allows modules to “plug and play.” The object-oriented facilities of Java are essentially those of C++, with extensions from Objective C for more dynamic method resolution.
The heart of Java is the Java Virtual Machine, or JVM. The JVM is a virtual computer that resides in memory only. The JVM allows Java programs to be executed on a variety of platforms as opposed to only the one platform for which the code was compiled. The fact that Java programs are compiled for the JVM is what makes the language so unique. But in order for Java programs to run on a particular platform, the JVM must be implemented for that platform.
The JVM is the very reason that Java is portable. It provides a layer of abstraction between the compiled Java program and the underlying hardware platform and operating system.
The JVM is actually very small when implemented in RAM. It was purposely designed to be small so that it could be used in a variety of consumer electronics. The whole Java language was originally developed with household electronics in mind. Gadgets such as phones, PCs, appliances, television sets, and so on will soon have the JVM in their firmware and allow Java programs to run. Cool, huh?
Java source code is compiled to the bytecode level, as opposed to the bit code level. The JVM executes the Java bytecode. The javac program, which is the Java compiler, reads files with the .java extension, converts the source code in the .java file into bytecodes, and saves the resulting bytecodes in a file with a .class extension.
The JVM reads the stream of bytecode from the .class file as a sequence of instructions. Each instruction consists of a one-byte opcode, which is a specific and recognizable command, and zero or more operands (the data needed to complete the opcode). The opcode tells the JVM what to do. If the JVM needs more than just the opcode to perform an action, then an operand immediately follows the opcode.
There are four parts to the JVM:
The size of an address in the JVM is 32 bits. Therefore, it can address up to 4G of memory, with each memory location containing one byte. Each register in the JVM stores one 32-bit address. The stack, the garbage-collected heap, and the method area reside somewhere within the 4G of addressable memory. This 4G of addressable memory limit isn’t really a limitation now, as most PCs don’t have more than 32M of RAM. Java methods are limited to 32K in size for each single method.
All processors use registers. The JVM uses the following to manage the system stack:
The Java development team decided that Java would only use four registers because if Java had more registers than the processor it was being ported to, then that processor would take a serious reduction in performance.
The stack is the where parameters are stored in the JVM. The JVM is passed the bytecode from the Java program and creates a stack frame for each method. Each frame holds three kinds of information:
The heap is the collection of memory from which class instances are allocated. Any time you allocate memory with the new operator, that memory comes from the heap. You can call the garbage collector directly, but it is not necessary or recommended under most circumstances. The runtime environment keeps track of the references to each object on the heap and automatically frees the memory occupied by objects that are no longer referenced. Garbage collections run as a thread in the background and clean up during CPU inactivity.
The JVM has two other memory areas:
There is no limitation as to where these memory areas must actually exist, making the JVM more portable and secure. The fact that memory areas can exist anywhere makes the JVM more secure in the fact that a hacker couldn’t forge a memory pointer.
The JVM handles the following primitive data types:
This section is organized into six parts. We will explore the issue of security of networked computing in general, and define the security problem associated with executable content. We will propose a six-step approach to constructing a viable and flexible security mechanism. How the architecture of the Java language implements security mechanisms will also be covered. As with any new technology, there are several open questions related to Java security, which are still being debated on the Net and other forums.
In this section, I analyze the concept of security in the general context of interactivity on the Web and implemented via executable content.
You first examine the duality of security versus interactivity on the Web and examine the evolution of the Web as a medium in the context of this duality. Next, you arrive at a definition of the security problem in the context of executable content.
A program arriving from outside the computer via the network has to be greeted by the user with a certain degree of trust, and allowed a corresponding degree of access to the computer’s resources, to serve any useful purpose. But the program was written by someone else, under no contractual or transactional obligation to the user. If this someone was a hacker, the executable content coming in could be a malicious program with the same degree of freedom as a local program.
Does the user have to restrict completely the outside program from accessing any resource whatsoever on the computer? Of course not. This would cripple the ability of executable content to do anything useful at all. A more complete and viable security solution strategy would be a six-step approach:
Working backwards from the previous solution strategy, the security problem associated with executable content can be stated as consisting of the following six subproblems:
As you learn, Java has been designed from the ground up to address most (but probably not all) of the security problem as defined here. Before you move on to Java security architecture itself, I identify next the attack targets and scenarios.
In this subsection, I list the various possible attack scenarios and resources on a user’s computer that are likely to be targeted by a potentially malicious, external, executable content module.
Attack scenarios could belong to one of the following categories (this is not an exhaustive list):
Table 2.1 lists the resources that could be potentially targeted and the type of attack they could be subject to. A good security strategy will assign security/risk weights to each resource and design an appropriate access policy for external executable content.
Table 2.1 Potential Targets of Attack
| Damage integrity | Smuggle information | Lock up/ deny usage | Steal resource | Non-fatal distraction | Impersonate | |
| File system | X | X | X | X | X | |
| Confidential data | X | X | X | X | X | |
| Network | X | X | X | X | X | |
| CPU | X | X | X | |||
| Memory | X | X | X | X | ||
| Output devices | X | X | X | X | ||
| Input devices | X | X | X | |||
| OS, program stateX | X | X | X |
This following discussion is in reference to the six-step approach outlined in the previous section.
Instead of coming up with every conceivable attack scenario, the Java security architecture posits potential targets of a basic set of attack categories—very similar to the previous attack scenario matrix.
Specifically, the Java security model covers the following potential targets:
against the following attack types listed in table 2.1:
Instead of arriving at a basic set of malicious behavior, Java anticipates a basic set of security hotspots, and implements a mechanism to secure each of these:
Construct a programming environment/computer language that implicitly disallows the basic set of malicious behavior and hence, by implication, all potential malicious behavior.
You guessed it—this language is Java!
Logically or, if possible, axiomatically prove that the language/environment is indeed secure against the intended attack scenarios.
Security mechanisms built into Java have not (yet) been axiomatically or even logically proven to be secure. Instead, Java encapsulates all of its security mechanism into distinct and well-defined layers. Each of these security loci can be observed to be secure by inspection in relation to the language design framework and target execution environment of Java language programs and applets.
The Java class file checker and bytecode verifier achieve this objective.
Design the language such that any new attack scenarios arising in the future can be dealt with by a corresponding set of counter-measures that can be retrofitted into the basic security mechanisms.
The encapsulation of security mechanisms into distinct and well-defined loci, combined with the provision of a Java SecurityManager class, provides a generic mechanism for incremental enhancement of security.
The first tier of security in Java is the language design itself—the syntactical and semantic constructs allowed by the language. The following is an examination of Java language design constructs with a bearing on security.
Java is fully object-oriented, with every single primitive data structure (and, hence, derived data structure) being a first-class, full-fledged object. Having wrappers around each primitive data structure ensures that all of the theoretical security advantages of OOP permeate the entire syntax and semantics of programs written in Java:
Classes and methods can be declared as final, which disallows further subclassing and method overriding. This declaration prevents malicious modification of trusted and verified code.
Typecasting is security checked both statically and dynamically, which ensures that a declared compile-time type of an object is strictly compatible with eventual runtime type, even if the object transitions through type-casts and coersions. Typecasting prevents malicious type camouflaging.
This is possibly the strongest guarantor of security that is built right into the Java language. Banishment of pointers ensures that no portion of a Java program is ever anonymous. Every single data structure and code fragment has a handle that makes it fully traceable.
Java is multithreaded. Java language enforces thread-safe access to data structures and objects. Chapter 14, “Threads,” examines Java threads in detail, with examples and application code.
Every single Java object has a unique hash code that is associated with it. This means that the state of a Java program can be fully inventoried at any time.
At compile time, all of the security mechanisms implied by the Java language syntax and semantics are checked, including conformance to private and public declarations, type-safeness, the initialization of all variables to a guaranteed known value.
Each compiled class file is verified to conform to the currently published official class file format. The class file is checked for both structure and consistency of information within each component of the class file format. Cross references between classes (via method calls or variable assignments) are verified for conformance to public and private declarations.
Each Java class is also assigned a major and minor version number. Version mismatch between classes within the same program is checked.
Java source classes are compiled into bytecodes. The bytecode verifier subjects the compiled code to a variety of consistency and security checks. The verification steps applied to bytecode include:
Java classes are defined within packages. Package names qualify Java class names. Packages ensure that code that comes from the network is distinguished from local code. An incoming class library cannot maliciously shadow and impersonate local trusted class libraries, even if both have the same name. This also ensures unverified, accidental interaction between local and incoming classes.
Late linking and binding ensures that the exact layout of runtime resources, such as stack and heap, is delayed as much as possible. Late linking and binding constitutes a road block to security attacks by using specific assumptions about the allocation of these resources.
The default mechanism of runtime loading of Java classes is to fetch the referred class from a file on the local host machine. Any other way of loading a class—including from across the network—requires an associated ClassLoader. A ClassLoader is a subtype of the standard Java ClassLoader class that has methods that implement all of the consistency and security mechanisms and apply them to every class that is newly loaded.
For security reasons, the ClassLoader cannot make any assumptions about the bytecode. The bytecode could have been created from a Java program compiled with the Java compiler, or it could have been created by a C++ compiler modified to generate Java bytecode. This means the ClassLoader kicks in only after the incoming bytecode has been verified.
ClassLoader has the responsibility of creating a namespace for downloaded code and resolving the names of classes referenced by the downloaded code. The ClassLoader enforces package-delimited namespaces.
In C and C++, the programmer has the explicit responsibility to allocate memory, deallocate memory, and keep track of the all the pointers to allocated memory. This often is a maintenance nightmare and a major source of bugs that result from memory leaks, dangling pointers, null pointers, and mismatched allocation and deallocation operations.
Java eliminates pointers and, with it, the programmer’s obligation to manage memory explicitly. Memory allocation and deallocation are automatic, strictly structured, and fully type-safe. Java uses garbage collection to free unused memory instead of explicit programmer-mediated deallocation. Garbage collection eliminates memory-related bugs as well as potential security holes. Manual allocation and deallocation allows unauthorized replication, cloning, and impersonation of trusted objects, as well as attacks on data consistency.
SecurityManager is a generic and extensible locus for implementing security policies and providing security wrappers around other parts of Java, including class libraries and external environments (such as Java-enabled browsers and native methods). The SecurityManager class itself is not intended to be used directly (each of the checks default to throwing a security exception). It is a shell class that is intended to be fleshed out via subclassing to implement a specific set of security policies.
Among other features, SecurityManager has methods to determine whether a security check is in progress, and to check for the following:
The major source of security threats from and to Java programs is Java code that comes in from across the network and executes on the client machine. This class of transportable Java programs is called the Java applet class. A Java applet has a very distinct set of capabilities and restrictions within the language framework, especially from the security standpoint.
Applets loaded over the network have the following restrictions imposed on them:
The previous strict set of restrictions on access to a local file system applies to applets running under Netscape Navigator 3.0 versions. The JDK 1.0 Appletviewer slightly relaxes the restrictions by letting the user define a specific, explicit list of files that can be accessed by applets.
Applets cannot do any of the following:
Applets can read some system properties by invoking System.getProperty(String key). Applets under Netscape 3.0 have unrestricted access to these properties. Sun JDK 1.0 Appletviewer allows individual control over access to each property. Table 2.2 lists the type of information returned for various values of key.
Table 2.2 System Variable Availability
| Key | Information Returned |
| java.version | Java version number |
| java.vendor | Java vendor-specific string |
| java.vendor.url | Java vendor URL |
| java.class.version | Java class version number |
| os.name | Operating system name |
| os.arch | Operating system architecture |
| file.separator | File separator (such as /) |
| path.separator | Path separator (such as :) |
| line.separator | Line separator |
The information provided in table 2.3 is not accessible to applets under Netscape 3.0. JDK 1.0 Appletviewer, and the HotJava browser allow user-controllable access to one or more of these resources.
Table 2.3 System Variables Restricted from Applets
| Key | Information Returned |
| java.home | Java installation directory |
| java.class.path | Java classpath |
| user.name | User account name |
| user.home | User home directory |
| user.dir | User's current working directory |
There are two different ways that applets are loaded by a Java system. An applet can arrive over the network or be loaded from the local file system. The way an applet is loaded determines its degree of freedom.
If an applet arrives over the network, it is loaded by the ClassLoader and is subject to security checks imposed by the ClassLoader and SecurityManager classes. If an applet resides on the client's local file system in a directory listed in the user’s CLASSPATH environment variable, then it is loaded by the file system loader.
From a security standpoint, locally loaded applets can:
Having examined the issue of security of executable content both in general and specifically in the framework of Java, you now examine some aspects of security that are not fully addressed by the current version of the Java architecture. You also learn if, for some types of threats, 100 percent security can be achieved at all.
The following components of the Java architecture are the loci of security mechanisms:
However, security provided by each of these layers can be diluted or defeated in some ways with varying degrees of difficulty:
Security issues that cannot easily be addressed within Java (or any other mechanism of executable content, for that matter) include:
One generic way to deal with security problems is for Java applet classes to be sent encrypted and digitally signed. The ClassLoader, SecurityManager, and even the bytecode verifier can include built-in decryption and signature verification methods.
In this section you find some excellent resources available online that reference the Java language and network security. The wealth of information available in UseNet groups is incredible. No matter what questions you may have, feel free to post them, as chances are someone else knows the answer or at least where to refer you to find the answer.
Some UseNet newsgroups to look for include the following:
The following list contains various FAQs and white papers covering Java security. This list covers everything from security at the language level all the up to applets and Java-enabled browsers:
The Java Application Programming Interface, or API, is a set of classes developed by Sun for use with the Java language. It is designed to assist you in developing your own classes, applets, and applications. With these sets of classes already written for you, you can write an application in Java that is only a few lines long, as opposed to an application that would be hundreds of lines long if it were written in C. Which would you rather debug?
The classes in the Java API are grouped into packages, each of which may have several classes and interfaces. Furthermore, each of these items may also have several properties, such as fields and/or methods.
While it is possible to program in Java without knowing too much about the API, every class that you develop will be dependent on at least one class within the API, with the exception of java.lang.Object, which is the superclass of all other objects. Consequently, when you begin to develop more complex programs that deal with strings, sockets, and graphical interfaces, it is extremely helpful for you to know the objects provided to you by Sun, as well as the properties of these objects.
The following list contains several APIs outside of the core API that are available or under development:
The Core API is the API that is currently shipped with Java 1.0.2. These packages make up the objects that are guaranteed to be available, regardless of the Java implementation:
The java.lang package consists of classes that are the core of the Java language. It provides you not only with the basic data types, such as Character and Integer, but also the means of handling errors through the Throwable and Error classes. Furthermore, the SecurityManager and System classes supply you with some degree of control over the Java Run-Time System.
The java.io package serves as the standard input/output library for the Java language. This package provides you with the ability to create and handle streams of data in several ways. It provides you with types as simple as a String and as complex as a StreamTokenizer.
The java.util package is composed essentially of a variety of useful classes that did not truly fit in any one of the other packages. Among these handy classes are:
The java.net package is the package that makes Java a networked-based language. It provides you with the ability to communicate with remote sources by creating or connecting to sockets or using URLs. For example, you can write your own Telnet, Chat, or FTP clients and/or servers by using this package.
The java.awt package is also known as the Java Abstract Window Toolkit (AWT). It consists of resources that enable you to create rich, attractive, and useful interfaces in your applets and stand-alone applications. The AWT not only contains managerial classes, such as GridBagLayout, but it also has several concrete interactive tools, such as Button and TextField. More importantly, however, is the Graphics class that provides you with a wealth of graphical abilities, including the ability to draw shapes and display images.
The java.awt.image package is closely related to the java.awt package. This package consists of tools that are designed to handle and manipulate images coming across a network.
The java.awt.peer is a package of interfaces that serve as intermediaries between your code and the computer on which your code is running. You probably won’t need to work directly with this package.
The java.applet package is the smallest package in the API, but it is also the most notable as a result of the Applet class. This class is full of useful methods, as it lays the foundation for all applets and is also able to provide you with information regarding the applet’s surroundings via the AppletContext interface.
The Java Enterprise API supports connectivity to enterprise databases and legacy applications. With these APIs, corporate developers are building distributed client/server applets and applications in Java that run on any OS or hardware platform in the enterprise.
Java Database Connectivity, or JDBCTM, is a standard SQL database access interface that provides uniform access to a wide range of relational databases. I am sure you have heard of ODBC. Sun has left no stone unturned in making Java applicable to every standard in the computing industry today.
Java IDL is developed to the OMG Interface Definition Language specification as a language-neutral way to specify an interface between an object and its client on a different platform.
Java RMI is remote-method invocation between peers or the client and server when applications at both ends of the invocation are written in Java.
The Java Commerce API brings secure purchasing and financial management to the Web. JavaWallet is the initial component, which defines and implements a client-side framework for credit card, debit card, and electronic cash transactions. Just imagine—surfing the Internet will take up all of your spare time...and money!
Java Server API is an extensible framework that enables and eases the development of a whole spectrum of Java-powered Internet and Intranet servers. The Java Server API provides uniform and consistent access to the server and administrative system resources. This API is required for developers to quickly develop their own Java servlets—executable programs that users upload to run on networks or servers.
The Java Media API easily and flexibly allows developers and users to take advantage of a wide range of rich, interactive media on the Web. The Media Framework has clocks for synchronizing and media players for playing audio, video, and MIDI. 2D and 3D provide advanced imaging models. Animation provides for motion and transformations of 2D objects. Java Share provides for sharing of applications among multiple users, such as a shared white board. Finally, Telephony integrates the telephone with the computer. This API is probably the most fun of all to explore.
The Java Security API is a framework for developers to include security functionality easily and securely in their applets and applications. This functionality includes cryptography with digital signatures, encryption, and authentication.
Java Management API provides a rich set of extensible Java objects and methods for building applets that can manage an enterprise network over the Internet and intranets. It has been developed in collaboration with SunSoft and a broad range of industry leaders including AutoTrol, Bay Networks, BGS, BMC, Central Design Systems, Cisco Systems, Computer Associates, CompuWare, LandMark Technologies, Legato Systems, Novell, OpenVision, Platinum Technologies, Tivoli Systems, and 3Com.
The Java Beans API defines a portable, platform-neutral set of APIs for software components. Java Bean components will be able to plug into existing component architectures, such as Microsoft's OLE/COM/Active-X architecture, OpenDoc, and Netscape's LiveConnect. End users will be able to compose together Java Beans components using application builders. For example, a button component could trigger a bar chart to be drawn in another component, or a live data feed component could be represented as a chart in another component. (Java Beans is currently an internal code name.)
The Java Embedded API specifies how the Java API may be subsetted for embedded devices that are incapable of supporting the full Java Core API. It includes a minimal embedded API based on java.lang, java.util, and parts of java.io. It then defines a series of extensions for particular areas, such as networking and GUIs.
| Previous Chapter | Next Chapter |
| Que Home Page | Digital Bookshelf | Disclaimer |
To order books from QUE, call us at 800-716-0044 or 317-361-5400.
For comments or technical support for our books and software, select Talk to Us.
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.