ClientServer Authentication Advanced JAAS Topics

practices by the end user. If your policy is never to run shareware programs downloaded from the Internet, then your policy should be never to install local classes on your system. And while newer versions of browsers, along with the ability in Java 2 to run applications in a secure environment, help to mitigate the potential danger of installing a local class file, such features will never obviate the need for users and system administrators to understand and work with the security model. There may be real bugs in the Java implementation −− but dont assume that all reports you hear about the sandbox being broken fall into that category. Bugs that are misclassified; that is, actual bugs that are reported as being security bugs when they are not. As weve seen, security is pervasive in the Java platform −− the bytecode verifier, the class loader, the security manager, and the compiler all have aspects of security to them. Hence, bugs in these areas are often considered security bugs even when they are not. For example, a bug in the bytecode verifier is usually assumed to be a security bug, even if it is not; if the verifier doesnt accept a particular construct that it should accept, for example, no security concerns arise. 2. Web−related bugs that are not Java−specific. Often, security problems on the Internet are associated with Java without any direct cause. In particular, bugs related to JavaScript TM and to ActiveX often fall into this category. When the first reports of ActiveX security bugs were circulated, there was a lot of discussion about active content; the assertion in many quarters was that the security problems that plagued ActiveX were inherent in any active content system. This assertion attempted to place Java in the same light as ActiveX since both were active content systems. The reality is that Java and ActiveX have very different security models. Similarly, bugs in JavaScript are often confused with bugs in Java, in part because of the name. It is probably well known by this point, but it doesnt hurt to reiterate: JavaScript and Java are completely different technologies produced by separate companies AOL and Sun, respectively. The two technologies are complementary in many ways, but they are fundamentally different from a security perspective. Finally, Java is not immune to security problems that plague the Web in general. Data that is sent between sites among Java applets and servers can be snooped just like data that is sent via HTTP can be snooped unless the Java traffic is using SSL or another encryption technique. A hacker that sets up a site to impersonate XYZ.com will be able to serve Java applets just as she is able to serve HTML. 3. Bugs in third−party trusted classes. When you install third−party classes, it is possible that one of them may breach the security model that you think is in place: it may provide a mechanism for an untrusted class to open a file, for example, based upon the permissions normally given to the third−party class. Complicating this factor is the manner in which these classes are often installed: they are often put into a directory and the users classpath is globally set to include those classes. Now untrusted classes will be able to access the third−party classes. 4. Bugs in the Java implementation. There have been several well−publicized bugs that do involve Javas security implementation; and as with any large computer system, there are bound to be others. 5. This last point should not minimized −− there have been and will be bugs in the Java security implementation. But the potential for bugs and their potential impact must be weighed against the potential benefits of using