Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

CHAPTER 41
Security

by Mike Morgan

In this chapter

Executable Content and Security 1142

The Java Approach to Security 1145

Applets Versus ActiveX Controls 1152

The Security of Compiled Code 1154

Security in the Java Runtime System 1158

Making and Using Signed Applets 1161

Making a JAR 1164

Signing Your JARs 1166

Open Issues on Security 1174

Further References on Java and Security 1175

Executable Content and Security

Java has changed the face of the Web from a static publishing medium to an interactive application development platform by providing executable “live” content embedded in HTML documents. This is a frightening thought to many system administrators. After all, it’s bad enough that people can download software that might contain viruses that could damage their machines. How can the network stay secure with programs coming in and running on the host machines all on their own? What is to keep somebody from reading sensitive data, wiping out hard drives, setting up back doors to the network, or something worse? Fortunately, the folks at Sun gave this matter some thought and designed Java with security in mind from the ground up, starting with the language and continuing on through the compiler, compiled code, and runtime environment.

To understand Java’s preventative measures, we’ll start by reviewing the special security concerns that apply to interactive content. We’ll then cover the types of attacks that unscrupulous programmers attempt and the kinds of security issues that relate to a well-intentioned but poorly written program. After we’ve covered the issues, we’ll discuss the security features of the Java language, the Java compiler, and the Java Virtual Machine. Finally, we’ll talk about the remaining open issues related to Java security and what you can (and can’t) do about them, as well as the new Security API being implemented in Java 1.2.

In this section, we’ll briefly discuss how interactivity on the Web has evolved and how security issues have changed with each new technique. We’ll then focus on how live content, executing on host machines, poses the most challenging security issues of all.

We will discuss the general security issues that relate only to executable content on the Web, as opposed to other means of interactivity. From there, we’ll outline the issues and illustrate possible attack scenarios.

Interactivity Versus Security

A direct correlation exists between interactivity and security:

The greater the level of interactivity, the greater the security risk.

The Internet enables information to be spread, but this capability is also what makes it potentially dangerous. This risk is especially high when the information is executable code, such as Java. An image or other non-program file cannot execute instructions on your machine, and so is inherently safer than a Java applet (or ActiveX control). As you will see, this relationship between interactivity and security is true on the server side as well as the client side.

Let’s step back to the basic building block of the Web—HTTP. HTTP, the Hypertext Transfer Protocol, is the protocol of the Web. It is a simple, stateless protocol. When an HTTP server receives a request for a file, it simply hands that file over. No interaction occurs between the server and client beyond the call and response. An HTTP server is similar to a television transmitter, and an HTTP client is similar to a television. A television is a receiver that receives signals from a transmitter. The only real difference between the way television transmitters and HTTP servers interact with televisions and HTTP clients is that instead of broadcasting, the server is responding to individual requests. The HTTP server is sending out whatever was specifically requested by an HTTP client and not just pumping out information to everyone. HTTP is a fairly secure protocol on both the client and server sides. The server controls what files and information the client has access to by choosing what it serves. The client is open to very little risk, except maybe being overloaded by too much data from the server, but the operating system on the client side usually prevents that. Although this protocol is quite reliable and more interactive than television, it is still a relatively passive medium.

Of course, the basic HTTP protocol leaves much to be desired in the way of interactivity, and people had to really fight it to build compelling, interactive content. Still, interactivity techniques were developed. The most popular of these have been the combination of forms and CGI programs.

The use of forms and CGI is still relatively secure on the client side, but significantly less so for the server. The process works like this. The browser on the client side receives an HTML form document. The form can contain combo boxes, radio buttons, check boxes, and text fields as well as buttons to post the form data. An end user fills out the form and submits its contents to the server. Form contents are submitted by passing them as an argument to a program that executes on the server. Most often, this program is a CGI (Common Gateway Interface) program. It can be written in any language that executes on the server and commonly consists of a UNIX shell script, a C program, or a Perl script. The CGI program parses up the parameter string supplied by the client and utilizes the data. The CGI program can store the data in a local database, email it, and so forth. All access to the server is accomplished by the CGI program. No direct access to the server by the client ever occurs. This arrangement presents a server-side security risk because badly behaved CGI programs can damage a server by depleting system resources, corrupting files, or doing anything else an executable program is capable of doing.

Although Active Server Pages and other non-CGI server-side scripting methods were not mentioned in the preceding discussion, the security issues are much the same.

•  For more information on CGI programs and security, see Chapter 35, “Server-Side Security Issues.”