One of the most significant aspects of Java programming is that it creates applications that have extraordinary relevance to computer security. Few UNIX administrators would be prepared to allow millions of users to execute programs as root (the administrative superuser) on their system, yet this level of potentially total power is what every user cedes when they point their browser at a URL containing some form of Java executable. Because of this, knowledge of computer security is becoming a requirement for Java programmers, and Java developers are being held accountable for the security implications of their code. Java experts who can speak authoritatively on security issues will be in greater demand.
This short series of articles won't dwell on the relative advantage or disadvantage of Java as a programming language, although it assumes that Java will be increasingly significant. Instead, it will discuss the reasons why it is so security-relevant and how you can be a more effective Java developer by becoming more familiar with information security concepts. I will be speaking to you not as an expert Java programmer, but as an experienced network security consultant who will present his views on the security implications of Java.
The First Java Security Hole
Most Java security incidents - especially the truly dangerous - have taken place in the laboratory. The first publicized Java security hole was discovered by a team of researchers at Princeton. While Java applets execute in a highly-controlled environment that prevents their accessing files and drives on a client machine, an early implementation of Netscape 2.X allowed an applet to access the network stack on the PC running the browser. As shown in simplified form in Figure 1, the team at Princeton created an innocent-looking applet that actually had a hidden agenda. A user executing this applet on their browser...even from within the protective boundary of their firewall...was actually launching a Trojan horse. This applet was then able to exploit a weakness in the sendmail program (the most common UNIX SMTP mail server) on a host on the same LAN segment, providing it root (total) privileges and allowing it to steal and send data back to the host serving the applet.
This security breach only occurred in the laboratory and the security hole in Netscape was quickly plugged, but it demonstrates several important security ideas:
- Firewalls are just access control devices. This one was only doing what it was asked to do and did not fail.
- Security weaknesses are cumulative: A small hole on the client PC and a UNIX weakness normally protected by the firewall added up to a significant security breach.
- Complex and new technology has unexpected consequences.
- Some people have very devious minds...expect the unexpected.
You Are What You Execute
Java shares a characteristic with computer viruses: it runs without a user's interactive choice. Java applets are essentially executable content and have become so common that users who disable Java miss many of the best Web pages. Common personal computer operating systems, like MS-Windows and MacOS, allow executing programs full access to the entire system...in essence, all applications under Windows95 run as root. An unfriendly or faulty program can completely destroy the client system it is running on. The distribution of executables provides unprecedented convenience and power...with commensurate new risk.
PC users browsing the Web with Java-compatible browsers are subject to the execution of arbitrary Java applets which potentially have the power to do anything. This is what has so many people worried about Java. Anticipating these concerns, the developers of Java have implemented a number of security features and Java applets run within a tightly-controlled environment (summarized in JavaSoft's "FAQ - Applet Security"). Theoretically, this protects the client PC from rogue applets, but Java is complex enough that some experts fear it can never be adequately secured. Developers creating Java programs for Intranet use must be extremely careful because their code will not execute in the controlled environment that the applets do. All Java programmers should understand and explain the security ramifications of their applications.
An understanding of computer security concepts will be helpful in understanding the security implications of Java and developed code. Like any discipline, familiarity with the terminology goes a long way towards establishing expertise and eventual mastery of the material.
Computer security lectures often begin with an explanation of the CIA' acronym. While this is hardly a total explanation of information security, it is easy to remember. The letters stand for:
Confidentiality, which is usually provided by encryption (although it can also be provided by completely isolating a system physically from unauthorized access), is what most people think of when they hear the term computer security. In practice, it turns out that privacy is often the least important security requirement. Java developers need to be aware of the sensitivity of the data that they will be processing through their code. If this is an issue, as with applications involving medical, financial or proprietary data, then the code must be written in such a way as to avoid data compromise. While encryption provides protection from unwanted viewing in transmission, it doesn't protect the information from compromise before or after transmission. The web infrastructure provides several built-in methods of ensuring the privacy of transmitted data (e.g., SSL and S-HTTP) and the Java Development Kit is being constantly extended to include new security APIs.
- Confidentiality...sometimes referred to as privacy, the protection of information from unwanted access
- Integrity...ensuring that data has not been unexpectedly altered
- Availability...or accessibility, allowing data to be available when it is needed
Integrity normally refers to freedom from data-tampering, but integrity would also be violated if code were created that contained bugs which introduced data errors. Java's security functionality is designed to prevent manipulation of existing data on the client, but it places no restrictions on what can be done on the server side before or after the user accesses it. Programmers must take care to maintain the integrity of data when they are writing an application that modifies it. The nature of the Web makes it even more important to ensure the security of server-based data because so many users have the potential to access it through Web-enabled applications. WANs are a complex security environment compared to the easily understood architecture of terminals hard-wired to a mainframe.
Availability refers to the reliable provision of access to necessary data. Uninterruptable power supplies and tape backups are two common technologies intended to maintain data availability. Denial of Service attacks are attempts to reduce or deny access to data. The Hostile Applets Home Page contains a number of applets designed to attack client systems. With the exception of one that steals e-mail addresses (a confidentiality attack), they all attempt to deny service by making either Netscape or the workstation unusable. Some experts draw a distinction between nuisance' applets and destructive' applets. In computer security terminology, this is only a matter of degree. The fact that for most users they are more of a nuisance than a problem does not change the fact that they are unwanted. Any rogue code has the potential to cause catastrophic harm and must be prevented.
Several other security requirements are relevant to Web applications. Identification and Authentication (I&A) is the first step in the two-step process of determining the exact identity of an entity and then referencing a table to determine what that entity is privileged to do. A 4-digit pin is a very weak identification method, while a retinal scan is virtually impossible to counterfeit. Java developers might be asked to program for an I&A environment in which users carry electronic identification cards that provide a one-time password and result in the granting of a Kerberos token that an application can trust. Increasingly, cryptographically-based identification is being used on the Web, such as the certificates provided by firms like VeriSign.
Non-Repudiation is the ability to prove that a transmission was sent by a specific entity and can allow that entity to prove that it was received. A mandatory requirement for electronic commerce, it provides the assurance necessary before paper communications (including fax) can be replaced. Normal SMTP mail, for instance, is easily spoofed, so it is not trustable. Anyone can deny having sent a message if it later proves inconvenient, citing the insecure nature of the medium. For most electronic commerce applications, non-repudiation is a higher priority than confidentiality.
A Security Policy is an organization's codification of what activities represent acceptable risk. Risk is difficult to quantify, but a good security policy is based upon a Risk Analysis that takes into account information system goals, vulnerabilities (weaknesses), and threats (things that could exploit weaknesses). A security policy is a prerequisite before creating any applications with a significant security risk. Java itself was created without a security policy, which probably explains some of its shortcomings.
What Does All This Mean to the Java Developer?
Projects might be canceled or not approved because of concerns over security. The optimum response to such concerns would be to demonstrate that the project in question is consistent with organizational security policies. Most organizations lack a formal policy, operating instead by the seat-of-the-pants. It is difficult to comply with an unwritten standard; encouraging the IS department to develop a security policy containing specific guidelines will make the developer's job easier.
"Writing crash-proof software is hard. Writing secure software is even harder." The Princeton Safe Internet Programming Team sums it up well in their Java Security FAQ. It is the very convenience and power of both the Web and Java that exacerbates the impact of insecure code. Distributed computing and the Web have permanently increased the requirement for security expertise on the part of application developers.
Be careful if you are using borrowed code. One would expect programmers to review source code before using it, but Web masters will grab useful applets where they can find them. It is not impossible that some applet creators might have their own hidden agenda.
Make your pages user-friendly. Many security-aware users have already begun to rebel against cookies. Such concern about confidentiality indicates that Web consumers are becoming sophisticated about security. Before implementing intrusive technology, consider that it coulds discourage some users from accessing your page. If you expect use of your code on the Internet, take into account the security requirements of your users and do not compromise their privacy. Security is always a trade-off between convenience and level of risk.
Be prepared to learn new security APIs if you deal with electronic commerce or sensitive information. If you are going to provide applets to Webmasters, you might need to provide assurance that they will not cause security problems. The best way to win your case will be to base your argument on well-reasoned security concepts.
A great deal of information is available on the Web on this topic. In addition to the sources already cited, take a look at Dr. Gary McGraw's "The Java Security Hotlist". Java is moving along so quickly that information can be obsolete as soon as it is published. Some of the seminal work on Java security is now a year old, making it older than most Java applications. Be aware that not all experts agree on the significance of all Java security issues. The more knowledgeable you are about this increasingly important issue, the more effective you will be both in writing good code and in avoiding political battles over its appropriateness.
About the Author
Jay Heiser is the Director of Internet Products for HomeCom Internet Security Services, where he is currently providing network security consulting to several major financial institutions and retail chains. He has lectured on information security in the US and Europe at events such as InfoWarCon, The Internet Conference, and FOSE. Jay also has animated several presentations on basic network security topics and made them available on the Web at http://www.homecom.com/services/hiss/LearnAbout.html. He can be reached at [email protected]