Java applets obviously have many potential capabilities. Many things can be done using these applets that, until now, were impossible to implement on such a broad scale. Java applets can be used to build full-featured graphical user interfaces, communicate over the Internet to a host server, and even communicate with other applets on a form. All of this can be done in an operating-environment-neutral manner, which is what makes this such a great technology. For Java to be truly successful, however, the client security has to be completely assured. Because of this, security measures place some limitations on Java applets. By default, applets cannot communicate with any server other than the originating server. Applets also cannot read or write files to the local file system. The following section discusses the Java security model and focuses on how this applies to Java applets.
The growth of technologies such as Web-based client/server application development and electronic commerce has been severely limited by the lack of "industrial-strength" security. Because the underlying Internet was never designed to handle secure transactions (the Department of Defense has a separate net for this purpose), the entire infrastructure of the Internet was somewhat unprepared for the phenomenal growth of the World Wide Web over the last few years. The concept of applets (or related technologies such as software agents) has been discussed in academic circles for years, yet most theoreticians realized the security shortcomings of the current programming languages such as C and C++.
Programming languages that allow manipulation of pointers (memory addresses) allow programmers to overrun memory boundaries and find "trap doors" into unsuspecting users' systems. Operating systems such as UNIX have continually struggled to patch well-documented security holes. Because the designers of Java were well aware of these problems, security measures were designed into Java at nearly every layer. The Java language's lack of support for pointers also leads to simpler, easier-to-read code. (Many programming errors by C programmers can be traced to improper manipulation of pointers to memory.)
The basic security model for Java treats all Java applets and applications as unknown, unsecured objects running within a secure environment. What this means is that a clever developer can produce subversive code to his heart's content, but the underlying Java runtime environment is designed to trap any problems. When the media publicizes a Java security "bug," this generally means that a team of researchers isolated a security flaw in the underlying runtime environment that hackers could capitalize on. An example of an early Java bug allowed a Web server to track all Web sites a user visits after the Web server itself has been visited. Although Java applets will never be used in the near future to implement truly secret applications, the Java security model makes security exceedingly difficult to circumvent.
The Java designers handled security at three levels:
- The elimination of pointersfrom the language eliminates an entire class of security problems. Programmers in C, for instance, can fake objects in memory because it is loosely typed and allows pointers.
- The bytecode verificationprocess forces uploaded Java applets to undergo a rigorous set of checks in order to run on the local system. In other words, this will foil "bad" users who decided to write a hostile compiler. Keep in mind that no matter what features are built into the language, a rogue compiler could still produce Java applets capable of circumventing the Java security model. Bytecode verification will be explained later in the chapter.
- Client-side precautions add another layer of security. Most Web browsers (more on this later) preclude Java applets from doing file access or communicating with any computer on the Internet other than the computer that the applet was uploaded from. The Java class loader assists in this process.
Bytecode Verification
Language security features are simply not enough to prevent an applet from reformatting your hard drive or some other unspeakable act. (Keep in mind that file I/O is allowed and even provided using the JDK class libraries.) Features needed to be built into the entire runtime system to prevent specially compiled applets from invading remote systems. Java is an interpreted language. This means that actual memory management for the application is put off until runtime (it is not built into the compiled Java classes). This feature allows Java to run on many different platforms thanks to the installed Java Virtual Machine. However, it also allows the Java runtime engine to verify that the bytecodes being loaded are, in fact, good bytecodes. This is done using a part of the Virtual Machine known as the verifier. The verifier has the unenviable task of checking each bytecode before it is executed (interpreted) to make sure that it is not going to perform an illegal operation. After the bytecode has been verified, the applet is guaranteed to do the following:
- Obey access restrictions such as public, protected, private, and friendly. No class will be allowed to access data that goes against these restrictions.
- Never perform illegal data conversions. Because Java is a strongly typed language, automatic conversions from arrays to pointers, for instance, are not allowed.
- Conform to all return, parameter, and argument types when calling methods.
- Live within its allocated stack. An applet that overruns its memory will not be loaded.
The verification process checks many of the things that a good Java compiler will check, but it is important to recognize that the verification process takes place on the client's computer. Security on the server side is virtually meaningless to Internet clients because of the unknown nature of most servers.
Client-Side Precautions
The set of precautions enforced by the client Web browser (or other applet loader) is done by a part of the Java runtime engine known as the class loader. The class loader does what its name says: it loads classes.
| Note |
The class loader can vary from browser to browser. Security features in the HotJava web browser allow the user to control security restrictions and even remove them altogether. The Netscape Navigator browser, however, offers no user-controlled security measures. Instead, applets are forced into a very rigid set of rules. Therefore, it is probably wise if applets are written to conform to the most restrictive case because then they will run on every user's computer. |
Three possible worlds are recognized by the class loader:
- The local system (highest level)
- The local network within a firewall (middle level)
- The Internet at large (lowest level)
The class loader implements defined rules that allow it to intelligently prevent an applet from wreaking havoc on your system. It does this by never allowing a class loaded from a lower level to replace a class existing on a higher level. The following example illustrates what this means.
An applet located on a Web server across the Internet imports the java.awt.Button class so that it can display a button on the screen. The developer on the remote machine changed some of the button's internal functionality but kept the class interface without changing anything. Fortunately for you (and unfortunately for the developer across the Internet), the java.awt.Button class is included with the Java Virtual Machine installed on your system. Therefore, when the applet is uploaded to your machine, the class loader will always retrieve your local Button.classfile.
In addition to this, classes cannot call methods from other classes in other security levels unless those methods are explicitly declared to be public. This means that Java applets loaded from a remote machine cannot call file system I/O methods. If those methods were called, the class loader would catch the error, and the applet load would fail.
Are Java Applets Safe?
Java handles security at several different levels. The language is designed in a manner that removes many security holes because it does not allow pointer manipulation. The bytecode verifier is used to verify each uploaded Java class to ensure that it obeys all Java language rules. The class loader enforces security on another level by controlling applet operations at runtime. It is important to realize that the bytecode verifier and class loader both exist on the local system and are part of the Java Virtual Machine. Because these two components are critical to the success of the Java security model, the user must rely on these components to ensure that Java applets are secure. At the current time, Sun, Netscape, Microsoft, IBM, and others are all working on implementations of the Java Virtual Machine for a host of operating platforms. As the number of "third-party" virtual machines increases, it is critical that these virtual machines be verified by some independent source to ensure that they operate according to the JVM specification. Sun is currently working on a test suite to do just this. In short: Yes, the Java environment is safe and secure. Vendor-specific implementations, however, must be validated to ensure that they comply with the Java specifications.
No comments:
Post a Comment