|
|
|
| |
        
|
 |
|
To access the contents, click the chapter and section titles.
Platinum Edition Using HTML 4, XML, and Java 1.2
The Java Approach to SecurityNot only is Java a programming language, it also is a cross-platform operating environment—the Java Virtual Machine (JVM). The JVM is separate and independent of Java, the language. The Java Development Kit (JDK) also includes a compiler (javac) for the Java language that produces bytecodes for the JVM. The JVM could run bytecodes compiled from any language, not only Java, and the .class files that make up Java objects could be created by any compiler that targeted the Java Virtual Machine. Security needs to be implemented separately on each of these fronts: in the language, the compiler, and the Virtual Machine. What is special about the Java programming language that makes it more secure than other languages? The Java language was designed to be
Many of these requirements affect the way security is implemented in the language, the compiler, and the Virtual Machine. The portability requirement, for example, means that Java cannot rely on any security measures built into an operating system because it needs to run on any system. Defending Against Attacks from Network SoftwareIf you’re going to design a language that makes it easy for programmers to send their work to end users, you have to deal with an unpleasant reality: Not all programmers are as nice as you are. In fact, a few twisted people write programs that are positively malicious. Trojan horse programs pretend to be useful applications, but when they run they carry out some hidden (and generally malicious) operation. Viruses attach themselves to other programs. As part of their function, they copy themselves to still other programs. As these programs are spread around the network, more and more machines are affected. At some point, the virus delivers its payload, which may be anything from a mischievous message on the screen to actually deleting data. Two lines of defense prevent programs such as trojan horses and viruses from being spread. First, you can enable the developer to “sign” the program with an unforgeable signature. If the signature is valid, the program does not have any viruses or other code that was added after the programmer finished the program. Second, you can design the language in such a way that certain operations, such as reading or writing the local hard drive, are prohibited. Although these operations may be useful to some programs, they are also exploited by malicious programmers. The only serious competitor to Java applets is Microsoft’s ActiveX control. Both Java and ActiveX give the programmer a way to digitally sign the program so the end user can be confident that the code he or she is downloading is actually the program the programmer wrote. Java differs from ActiveX, however, in that Java prevents the programmer from doing things on the client’s machine that might be used by a virus or a trojan horse. If you have a signed program that can do anything it likes to the end user’s machine, you have a serious vulnerability. Not every malicious operation is immediately obvious. If a malicious program starts deleting files off your hard drive, you’ll probably notice. But will you notice if it goes through your Web browser’s disk cache looking up confidential information from your intranet? Even if you detect a malicious program at work, you may not be able to identify which program is doing the work. In fact, there’s no guarantee that the problem-causing program came to you over the Internet. Some security experts have reported that more viruses are loaded from CD-ROMs than from the Internet. So the best that an electronic signature can guarantee you is that if you detect something going wrong, and if you can determine that the problem was caused by something you downloaded, and if you can determine which downloaded program caused the problem, you now have someone to blame. Many security experts—not to mention users—would prefer that the problem never occur in the first place. That’s the Java approach—deny the malicious programmer any opportunity to write a virus or a trojan horse in the first place.
To ensure security, Java designers implemented a mechanism called the sandbox. The sandbox ensures that untrusted (and possibly malicious) Java applets are allowed access to only a limited set of capabilities on the end user’s machine.
This section describes the three major mechanisms that implement a sandbox:
JVM-Level ChecksSuppose you’ve written a Java applet and have compiled it into a class file. You use this applet on your Web page; when an end user who uses a Java-aware browser downloads this page, he also downloads the applet. In order to ensure that the applet cannot access system-level resources such as the hard drive, the Java Virtual Machine (JVM) that is built into the browser performs several checks. First, the JVM includes a class loader, which is responsible for finding and downloading all the classes used by the applet. Second, before the class file is allowed to execute, the contents of the class file are tested by the bytecode verifier. Third, the class runs under the supervision of the JVM Security Manager. Figure 41.1 illustrates how these three components work together.
|
|
Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.
|
)
){kind=link}