Java 2 Network Security P2

The class file verifier (which includes the bytecode verifier) checks that the program obeys the rules of the Java Virtual Machine (but note that this does not necessarily mean that it obeys the rules of the Java language). 3. The security manager imposes local restrictions on the things that the program is allowed to do. It is perfectly possible to customize this to allow code limited access to carefully controlled resources. This could mean allowing no access to the local file system, and network access only to the location from which the code, or its Web page, came. You...
Nội dung trích xuất từ tài liệu:
Java 2 Network Security P2 2. The class file verifier (which includes the bytecode verifier) checks that the program obeys the rules of the Java Virtual Machine (but note that this does not necessarily mean that it obeys the rules of the Java language). 3. The security manager imposes local restrictions on the things that the program is allowed to do. It is perfectly possible to customize this to allow code limited access to carefully controlled resources. This could mean allowing no access to the local file system, and network access only to the location from which the code, or its Web page, came. You may wish, for example, to print something from an applet. You are unlikely to want your security manager to allow anyone to do that, but you might allow access to especially trustworthy people. So you download the applet; discover that it is located at a trustworthy URL address and encrypted with someone’s private key; check the accompanying public key certificate to make sure it is valid, and identify someone especially trustworthy; decrypt the applet with that public key, and then allow it the necessary access. One important thing that distinguishes Java from other forms of executable content is that it has both the web of trust that signatures bring and the three security components to validate the downloaded code. These precautions are taken, not because Java users are less trustful than others, but because even the most trusted of code suppliers sometimes make mistakes, or can have their systems compromised. Without the validation, a web of trust can become a web of corruption if any one trusted site is successfully cracked.1.3.3 Java as a Threat to Security So, in the absence of implementation errors, either on the part of the browser vendors or on the part of computer operators, administrators and systems programmers, Java should be safe. The browser vendors have a good reputation for responding to reports of flaws in their implementations, and one of the key purposes of this book is to help you avoid any slips in your installation. If something does go wrong, then the most severe threat you face is system modification, the result of what are sometimes called attack applets. This is worse than someone’s being able to read data from your system, because you have no idea what has been left behind. There could be a virus on your computer, or on any computer to which you are connected. Alternatively, some of your business data could have been modified so that it is no longer valid. This is exactly the sort of thing that Java is intended to prevent, and its defenses against attack applets are strong. They are equally strong against An Overview of Java and Security 9 the next, still severe, threat of privacy invasion, in which read access rather than update access is gained. This does not leave you having to reinstall all your software and reassemble all your business data, but the loss can be serious enough. In addition to the exposure of business data, if your private key is compromised, then it can be used to sign electronic payments in your name. Because Java has the strongest security for executable content, it has been seen as a challenge by security specialists, who find both the intellectual challenge exciting and want to help close any loopholes in Java implementations. Up to the date of writing, all the reported attack applets were developed by such specialists, not by malicious or criminal attackers. There are another couple of, much less severe, threats against which Java does not have strong defenses. The very essence of Java is that a program from a server will come down and run on your client with little, if any, intervention from you. What if the program is not one you want to run... If it is stealing your cycles? The most extreme form of cycle stealing is a denial of service attack. The applet can use so much of the client’s machine time that it cannot perform its normal function. This is the Java equivalent of floodi ...