Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
| "All Java applet security relies on using a recent and updated virtual machine. This is the first step in avoiding security leaks. " |
For a programming language that downloads foreign code to run on an end user’s machine, Java is extremely secure. Java’s sandbox model, securitymanager(), language protocols, memory management, and class library all help work together to make running applets from the Web as safe as possible. However, no system is one hundred percent secure.
Staying current with Java security is an ongoing education. Flaws and bugs are still occasionally found, and designers continue to use applications in new and unforeseen ways (the Java language historically is a good example of unforeseen ingenuity). Many security software products today disable Java automatically, and the Computer Emergency Response Team (CERT) recommends that users disable Java when traveling to unknown Websites. The reason for this cautionary approach is mostly due to hostile applets.
Hostile applets exist that can seize and take control of your operating system, damage local file systems, block access to specific Website applications, and fake e-mail. These applets are sometimes the result of malicious programmers but are also often the result of poorly coded applets. Since applets can often bypass firewalls and other standard security measures, they can be extremely dangerous.
Denial of Service Attacks
Probably the most common form of hostile applets are ones that create DoS attacks. Applet DoS attacks are not usually considered a serious security risk, because system integrity is usually not breached; they just deny the end user access to their own system.
DoS attacking applets generally run daunting tasks that grab all of a computer’s CPU cycles to do their own work, or they eat up event handling to lock a user away from his mouse or keyboard. They may do this by opening up a never-ending series of windows, attempting to allocate all available memory, hogging all screen space, or hanging a system, making it wait for an event that never happens. An example of this is setting up an applet that sends a user to the same URL over and over again; a second is one that fills all of a browser’s available memory with large computations to crash it.
This kind of attack is simple for Java and is sometimes set up accidentally. By assigning a high thread priority, or running constant multiple tasks, a programmer could accidentally create a thread that never ends. A malicious user could also cause a DoS attack by overriding the methods stop() and try/finally(), making it impossible to end the thread.
To end a DoS attack, you simply have to close the browser that is running the applet. A force quit or system shutdown usually turns these hazards into inconveniences.
Thread Wars
It should not be possible for threads from one applet to kill or disable other threads. However, something called ThreadMurder can kill a thread from any applet up through JDK 1.1.5. Since applets from a specific site or server do not necessarily stop running when you leave the specific site, thread murder can be set up to sit and wait on a browser, running silently, until it encounters a thread from a competing Website or company. It then launches and overrides these other threads using a DoS style attack or simply terminates the opposing thread.
An applet thread can also be set up that runs invisibly or under the guise of another application, monitoring the browser and sending info on its activities back to the original server. Applets could be used in this manner to take an occasional CPU cycle from its host machine to run computations for its host server, or to monitor the end user as she browses different sites.
Other Attacks
There have been known instances of applets forging e-mail messages, popping up fake dialogue boxes (asking for user information to be sent back to a host server), and ones that cause an end user’s modem to dial out. Many improvements to Java security have been made to stop or halt most of these attacks: Code signing, changes in the language to stop type confusion, and updates to securitymanager() are all recent additions to Java security.
Securing Yourself from Hostile Applets
All Java applet security relies on using a recent and updated virtual machine. This is the first step in avoiding security leaks. Many applet exploits have been made impossible by recent security updates in browsers, virtual machines, and the Java language itself. (Standalone Java programs still have the same security risks as any other program that you run on your computer.)
Except for a few rare circumstances, the danger from a hostile applet ends when the browser running the applet is closed. CERT stills recommends turning off Java in your browser before going to unknown sites, and to only allow Java applets to download from a source you trust.
You can inspect unknown code using a Java decompiler. By traveling to a new Website with Java in your browser turned off, you can read the HTML, and then snag any applets directly by pointing the browser to the exact applet URL. Then you can use a decompiler to unravel the code and look for dangers manually. Please note, however, that it is illegal to decompile copyrighted code, even for security reasons.
Designing Secure Applets
Although not meant to be comprehensive, here are some simple rules you can follow for making your applets more secure and less exploitable by attackers. These rules can also help you to avoid accidentally turning your applet into a hostile one.
- Do not store harmful or security-related information in your code. Even if using encryption or obfuscation, assume that your code is completely accessible and readable by anyone who runs it.
- Every class, method, or variable should be private, unless you have a good reason for it not to be. Anything that is not private is a possible security risk. If a class is not labeled as public, private, or protected, it is accessible within the same package. Because classes in Java are not closed, an attacker can introduce a new class into your package and have access you did not intend.
- Scope is not designed as a security tool, like securitymanager(). Do not rely on it or use it for security purposes.
- Do not override methods unless you have good, specific reasons. In particular, do not override stop() and finally(), and avoid overriding thread management methods. All methods should be final unless you have a good reason.
- Java’s new security features that allow for signing code can allow applets more access to the end user’s resources and system. You should sign code only if absolutely necessary. Unsigned code is much less likely to be able do damage.
Resources and References
- University of Washington Department of Computer Science and Engineering, The Kimera Java Security Project.
- Princeton University Department of Computer Science, Secure Internet Programming.
- Dageforde, Mary. Security in JDK 1.1, and Security in Java 2 SDK 1.2 (In Sun’s Java Tutorial), Sun Microsystems.
- Joworski, Jamie. Java Developer’s Guide, Sams.net Publishing, 1996.
- Felton, Ed; McGraw, Gary. Securing Java, John Wiley & Sons, Inc., 1999.
- Naughton, Patrick; O’Neil, Joe; Schildt, Herbert. Java 2: The Complete Reference, Third Edition, Osborne/McGraw-Hill, 1999.
- Vanderberg, Glenn. Tricks of the Java Programming Gurus, Sams.net publishing, 1996.
About the Author
Thomas Gutschmidt is a freelance writer, in Bellevue, WA, who also works for Webvan Group Inc./HomeGrocer.com.
