84-10-29

DATA SECURITY MANAGEMENT

SECURITY OF APPLETS AND APPLICATION CONTROL John R. Vacca

INSIDE

What Applets Are Prevented from Doing; Can Applets Read or Write Files; How to Let an Applet Read a File; How to Let an Applet Write a File

INTRODUCTION

In general, unsecured applets2 loaded over the Net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host. In addition, unsecured applets loaded over the Net are prevented from starting other programs on the client. Unsecured applets loaded over the Net are also not allowed to load libraries, or to define native method calls. If an unsecured applet could define native method calls, that would give the applet direct access to the underlying computer. There are other specific capabilities denied to unsecured applets loaded over the Net, but most of the applet security policy is described by the two preceding paragraphs. Read on for the gory details. HOW APPLETS CAN READ OR WRITE FILES

So, can applets read or write files? In Java-enabled browsers, unsecured applets cannot read or write files at all. By default, downloaded applets

PAYOFF

IDEA

This article shows how to run unsecured applets in a secure application controlled environment. The approach taken here is to be conservative at first, and to add functionality when it can be added securely. The intent is to prevent applets from inspecting or changing files on the client 1 file system. Also, the intent is to prevent applets from using network connections to circumvent file protections or people’s expectations of privacy. This article also provides the basic technology for loading and authenticating signed classes. This enables browsers to run trusted applets in a trusted secure application controlled environment. This does not make obsolete the need to run unsecured applets in a secure way. In addition, this article also provides information on tools for finergrained control of flexible applet and application control security policies. Furthermore, when computer-processed data are an important or integral part of the audit and the data’s reliability is crucial to accomplishing the audit objectives, auditors need to satisfy themselves that the data is relevant and reliable. This is important regardless of whether the data is provided to the auditor or the auditor independently extracts them. This article also shows how to determine the reliability of the data. In other words, the auditors can either (1) conduct a review of the application controls in the computer-based systems including tests as are warranted, or (2) if the application controls are not reviewed or are determined to be unreliable, conduct other tests and procedures.

Auerbach Publications © 2000 CRC Press LLC

DAT A S EC URI T Y MA NA GEMENT

are considered unsecured. There are two ways for an applet to be considered secure. First, the applet is installed on the local hard disk, in a directory on the CLASSPATH used by the program used to run the applet. Usually, this is a Java-enabled browser, but it could be the appletviewer, or other Java programs that know how to load applets. Second, the applet is signed by an identity marked as secure in the identity database. For example, Sun’s3 appletviewer allows secure applets to read files that reside in directories on the access control lists. If the file is not on the client’s access control list, then applets cannot access the file in any way. Specifically, unsecured applets cannot: • • • • • • • • •

check for the existence of the file check the file’s type check the timestamp when the file was last modified check the file’s size create a directory on the client file system list the files in this file (as if it were a directory) read the file rename the file write the file

LETTING AN APPLET READ A FILE

Unsecured applets loaded into a Java-enabled browser cannot read files. For example, Sun’s appletviewer allows applets to read files that are named on the access control list for reading. The access control list for reading is null by default in the Java Development Kit (JDK). One can allow secure applets to read directories or files by naming them in the acl.read property in the ~/.hotjava/properties file.4 As an example, to allow any files in the directory home/me to be read by secure applets loaded into the appletviewer, add this line to the ~/.hotjava/properties file: acl.read=/home/me One can specify one file to be read: acl.read=/home/me/somedir/somefile Use “:” to separate entries: acl.read=/home/foo:/home/me/somedir/somefile Allowing a secure applet to read a directory means that it can read all the files in that directory, including any files in any subdirectories that might be hanging off that directory. Auerbach Publications © 2000 CRC Press LLC

SECURITY OF APPLETS AND APPLICATION CONTROL

LETTING AN APPLET WRITE A FILE

Unsecured applets loaded into a Java-enabled browser cannot write files. Sun’s appletviewer allows secure applets to write files that are named on the access control list for writing. The access control list for writing is empty by default. One can allow secure applets to write to the /tmp directory by setting the acl.write property in ~/.hotjava/properties file: acl.write=/tmp One can allow secure applets to write to a particular file by naming it explicitly: acl.write=/home/me/somedir/somefile Use “:” to separate entries: acl.write=/tmp:/home/me/somedir/somefile Bear in mind that if one opens up the file system for writing by secure applets, there is no way to limit the amount of disk space an applet might use. HOW TYPES OF SYSTEM PROPERTIES CAN BE READ BY APPLETS

In Java-enabled browsers, secure applets can read the system properties by invoking a System.getProperty(String key), as shown in Exhibit 1. Unsecured applets are prevented from reading the system properties shown in Exhibit 2. To read a system property from within a secure applet, simply invoke System.getProperty (key) on the property of interest. For example: String s = System.getProperty(“os.name”) HIDING SYSTEM PROPERTIES

So, how does one hide system properties that secure applets are allowed to read by default? There is no way to hide the preceding ten system properties shown in Exhibit 1 from unsecured applets loaded into a Javaenabled browser. The reason is that the browsers do not consult any external files as part of their Java configuration, as a security precaution, including the ~/.hotjava/properties file. From Sun’s appletviewer, one can prevent applets from finding out anything about the system by redefining the property in the ~/.hotjava/properties file. For instance, to hide the name of the operating system being used, add this line to the ~/.hotjava/properties file:

Auerbach Publications © 2000 CRC Press LLC

DAT A S EC URI T Y MA NA GEMENT

EXHIBIT 1 — System Properties That Can Be Read by Secure Applets Key

Meaning

java.version java.vendor java.vendor.url java.class.version os.name os.arch os.version file.separator path.separator line.separator

Java version number Java vendor-specific string Java vendor URL Java class version number Operating system name Operating system architecture Operating system version File separator (e.g., “/”) Path separator (e.g., “:”) Line separator

os.name=null ALLOWING APPLETS TO READ SYSTEM PROPERTIES

Can one allow unsecured applets to read system properties that they are not allowed to read by default? There is no way to allow an unsecured applet loaded into a Java-enabled browser to read system properties that they are not allowed to read by default. To allow applets loaded into Sun’s appletviewer to read the property named by key, add the property key.applet=true to the ~/.hotjava/property file. For instance, to allow secure applets to record one’s user name, add this line to the ~/.hotjava/properties file: user.name.applet=true HOW TO LET AN APPLET OPEN A NETWORK CONNECTION ON THE INTERNET

Unsecured applets are not allowed to open network connections to any computer, except for the host that provided the .class files. This is either the host where the HTML page came from, or the host specified in the codebase parameter in the applet tag, with codebase taking precedence. For example, if one tries to do this from an applet that did not originate from the machine foo.com, it will fail with a security exception: EXHIBIT 2 — System Properties that Cannot Be Read by Unsecured Applets Key

Meaning

java.home java.class.path user.name user.home user.dir

Java installation directory Java classpath User account name User home directory User’s current working directory

Auerbach Publications © 2000 CRC Press LLC

SE C URITY OF A P P L ET S A ND A P P L I C A T I ON C ONT ROL

Socket s = new Socket(“foo.com,” 25, true); HOW TO LET AN APPLET OPEN A NETWORK CONNECTION TO ITS ORIGINATING HOST

One must be sure to name the originating host exactly as it was specified when the applet was loaded into the browser. That is, if one loads an HTML page using the URL: http://foo.state.edu/~me/appletPage.html,5 then the applet will be able to connect to its host only by using the name foo.state.edu. Using the IP address for foo.state.edu will not work, and using a shorthand form of the host name, like foo.state instead of foo.state.edu, will not work either. HOW TO LET AN APPLET MAINTAIN A PERSISTENT STATE

There is no explicit support in the JDK applet application program interface (API) for a persistent state on the client side. However, a secure applet can maintain its own persistent state on the server6 side. That is, it can create files on the server side and read files from the server side. STARTING ANOTHER PROGRAM ON THE CLIENT

No unsecured applets loaded over the Internet are allowed to start programs on the client. That is, an unsecured applet that one visits cannot start some rogue process on a PC. In UNIX terminology, unsecured applets are not allowed to execute or fork processes. In particular, this means that unsecured applets cannot invoke some program to list the contents of a file system; and it also means that unsecured applets cannot invoke System.exit() in an attempt to kill the Web browser. Unsecured applets are also not allowed to manipulate threads outside the applet’s own thread group. BUILDING SECURE APPLETS

Java programs do not use pointers explicitly. Objects are accessed by getting a handle to the object. Effectively, this is like getting a pointer to an object, but Java does not allow the equivalent of pointer arithmetic on object handles. Object handles cannot be modified in any way by the Java applet or application. Furthermore, C and C++ programmers are accustomed to manipulating pointers to implement strings arrays. Java has high-level support for both strings and arrays, so programmers do not need to resort to pointer arithmetic in order to use those data structures. Also, arrays are bounds-checked at runtime. Using a negative index causes a runtime exception, and using an index that is larger than the Auerbach Publications © 2000 CRC Press LLC

DAT A S EC URI T Y MA NA GEMENT

size of the array causes a runtime exception. Once an array object is created, its length never changes. In addition, strings in Java are immutable. A string is zero or more characters enclosed in double quotes, and it is an instance of the String class. Using immutable strings can help prevent common runtime errors that could be exploited by hostile applets. The Java compiler also checks that all type casts are legal. Java is a strongly typed language, unlike C or C++, and objects cannot be cast to a subclass without an explicit runtime check. The final modifier can also be used when initializing a variable, to prevent runtime modification of that variable. The compiler catches attempts to modify final variables. Before a method is invoked on an object, the compiler checks that the object is the correct type for that method. For example, invoking: t.currentThread() when t is not a Thread object causes a compile time error. Java also provides four access modifiers for methods and variables defined within classes. It makes sure that the following access barriers are not violated: • Default: if no modifier is specified, then by default, a method is accessible only within its defining package. • Private: a private method is accessible only within its defining class. • Protected: a protected method is accessible by a child of a class as long as it is trying to access fields in a similarly typed class. For example: class Parent { protected int x; } class Child extends Parent { ... }

The class Child can access the field “x” only on objects that are of type Child (or a subset of Child). • Public: a public method is accessible anywhere the class name is accessible. For instance, programmers can choose to implement sensitive functions as private methods. The compiler and the runtime checks ensure that no objects outside the class can invoke the private methods. APPLETS LOADED OVER THE NET VERSUS APPLETS LOADED VIA THE FILE SYSTEM

There are two different ways that secure applets are loaded by a Java system. The way an applet enters the system affects what it is allowed to do.

Auerbach Publications © 2000 CRC Press LLC

SE C URITY OF A P P L ET S A ND A P P L I C A T I ON C ONT ROL

If a secure applet is loaded over the Net, then it is loaded by the applet class loader, and is subject to the restrictions enforced by the applet security manager. If a secure applet resides on the client’s local disk, and in a directory that is on the client’s CLASSPATH, then it is loaded by the file system loader. The most important differences are: • Secure applets loaded via the file system are allowed to execute processes. • Secure applets loaded via the file system are allowed to exit the virtual machine. • Secure applets loaded via the file system are allowed to load libraries on the client. • Secure applets loaded via the file system are allowed to read and write files. • Unsecured applets loaded via the file system are not passed through the bytecode verifier. Java-enabled browsers use the applet class loader to load applets specified with file: URLs. Thus, the restrictions and protections that accrue from the class loader and its associated security manager are now in effect for applets loaded via file: URLs. This means that if one specifies the URL as: Location: file:/home/me/public_html/something.html and the file something.html contains an applet, the browser loads it using its applet class loader. APPLET CLASS LOADER

So, what is an applet class loader, and what does it buy? Secure applets loaded over the Internet are loaded by the applet class loader. For example, the Sun appletviewer’s applet class loader is implemented by the class sun.applet.AppletClassLoader. The class loader enforces the Java name space hierarchy. The class loader also guarantees that a unique namespace exists for classes that come from the local file system, and that a unique namespace exists for each network source. When a browser loads a secure applet over the Net, that applet’s classes are placed in a private namespace associated with the applet’s origin. Thus, applets loaded from different network sources are partitioned from each other. Also, classes loaded by the class loader are passed through the verifier. The verifier checks that the class file conforms to the Java language specification. It does not assume that the class file was produced by a friendly or trusted compiler. On the contrary, it checks the class file for Auerbach Publications © 2000 CRC Press LLC

DAT A S EC URI T Y MA NA GEMENT

purposeful violations of the language type rules and name space restrictions. The verifier ensures that: • • • •

all register accesses and stores are valid the parameters to all bytecode instructions are correct there are no stack overflows or underflows there is no illegal data conversion

The verifier accomplishes the preceding by doing a dataflow analysis of the bytecode instruction stream, along with checking the class file format, object signatures, and special analysis of finally clauses that are used for Java exception handling. On the other hand, a Web browser uses only one class loader, which is established at start-up. Thereafter, the system class loader cannot be extended, overloaded, overridden, or replaced. Unsecured applets cannot create or reference their own class loader. THE APPLET SECURITY MANAGER

The applet security manager is the Java mechanism for enforcing the applet restrictions previously described. Sun’s appletviewer’s applet security manager is implemented by sun.applet.AppletSecurity. A browser may only have one security manager. The security manager is established at start-up, and it cannot thereafter be replaced, overloaded, overridden, or extended. Applets cannot create or reference their own security manager. APPLET SECURITY MODEL

Finally, if other languages are compiled to Java bytecodes, how does that affect the applet security model? The verifier is independent of Sun’s reference implementation of the Java compiler and the high-level specification of the Java language. It verifies bytecodes generated by other Java compilers. It also verifies bytecodes generated by compiling other languages into the bytecode format. Bytecodes imported over the Net that pass the verifier can be trusted to run on the Java virtual machine. In order to pass the verifier, bytecodes must conform to the strict typing, the object signatures, the class file format, and the predictability of the runtime stack that are all defined by the Java language implementation. Now take a look at how to run unsecured applets in a secure application controlled environment. APPLICATION CONTROL

When computer-processed secure applets are an important or integral part of the audit and the applet’s reliability is crucial to accomplishing the audit objectives, auditors need to satisfy themselves that the applets are relevant and reliable. This is important regardless of whether the applets Auerbach Publications © 2000 CRC Press LLC

SE C URITY OF A P P L ET S A ND A P P L I C A T I ON C ONT ROL

are provided to the auditor or the auditor independently extracts them. To determine the reliability of the applets, the auditors may either (1) conduct a review of the application controls in the computer-based systems, including tests as are warranted; or (2) if the application controls7 are not reviewed or are determined to be unreliable, conduct other tests and procedures. When the reliability of a computer-based system is the primary objective of the audit, auditors should conduct a review of the system’s application controls. When computer-processed applets are used by the auditor, or included in the report, for background or informational purposes and are not significant to the audit results, citing the source of the applets in the report will usually satisfy the reporting standards for accuracy and completeness. System Review Versus a Limited Approach

There are basically two approaches to assessing the reliability of computer-based applets: the systems review generally performed by specialists and the more limited approach designed for evaluators/auditors. A systems review assesses and tests all controls in a computer system for the full range of its application functions and products. These reviews: 1. examine a computer system’s application controls 2. test whether those controls are being complied with 3. test data produced by the system While the preceding approach provides the best understanding of a system’s design and operation, it tends to be time-consuming. When the assignment’s objective(s) dictate a complete system review, specialists should be consulted. The limited review is targeted to particular applets. As a result, it normally requires a less extensive understanding of application controls. Pertinent controls are examined to the extent necessary to judge the level of data testing needed to determine data reliability. This can usually be performed by the generalist enterprise staff. Understanding Application Controls

Enterprise staff should understand system controls and their purposes to determine whether they can be relied on to reduce applets testing. This understanding includes application controls that relate to assignment evidence. In understanding application controls, enterprise staff should consider matters such as the following: • applets user’s views of data reliability • error detection and correction procedures Auerbach Publications © 2000 CRC Press LLC

DAT A S EC URI T Y MA NA GEMENT

• frequency of system modification and the reasons for it • internal audit reports and other evaluations or studies • procedures to ensure that application software and subsequent modifications are authorized and tested before implementation • reconciliation of output records with input entries • tables used in computer processing, their sources, and the frequency of updating • existence of current narrative system descriptions and flowcharts • review, approval, control, and editing of source transactions to ensure completeness and prevent error • whether program changes are controlled and promptly documented Regardless of how well-conceived and well-designed system controls may be, they are ineffective if applied incorrectly and inconsistently. For example, a system may have a control that requires an applet quality control group to verify that source data are accounted for and that they are complete and accurate, have been appropriately authorized, and transmitted in a timely manner. But if that group is bypassed, the control contributes nothing to ensuring the integrity of applet entry. Many reasons exist for bypassing or overriding controls, such as time pressures, fatigue, boredom, inattention — or even collusion for personal gain. As a result, enterprise staff should select the most significant control procedures and confirm adherence to them. Although it is unnecessary to test all procedures, enterprise staff should conduct sufficient tests to afford a reasonable basis for reducing testing by relying on the adequacy of controls. Observing the work environment for an ordered and enterprise-like atmosphere can be helpful. Documentation of a well-controlled system should be complete and current. Absence of such documentation may indicate that controls do not exist or, if they do, that they are not understood or adequately applied. Other red flags that suggest vulnerability to applet errors include: • complex or messy applet structures • frequent processing and updating activity • high employee turnover (data entry clerks, operators, and analysts) and inadequate training • lack of EDP standards, especially related to security, access, and program change control • large number of coded applet elements • large volumes of data • numerous transaction types and sources • old systems with high program maintenance Finally, discussions with knowledgeable agency personnel can provide an effective beginning in gaining an overall system understanding. Auerbach Publications © 2000 CRC Press LLC

SECURITY OF APPLETS AND APPLICATION CONTROL

EXHIBIT 3 — Summary of a Secure Applet’s Capabilities Stricter → Less strict

Read file in /home/me, acl.read=null Read file in /home/me, acl.read=/home/me Write file in /tmp, acl.write=null Write file in /tmp, acl.write=/tmp Get file info, acl.read=null acl.write=null Get file info, acl.read=/home/me acl.write=/tmp Delete file, using File.delete() Delete file, using exec /usr/bin/rm Read the user.name property Connect to port on client Connect to port on 3rd host Load library Exit(-1) Create a popup window without a warning

Nn

Nl

An

Al

Js

No No No No No No No No No No No No No No

No No No No No No No No Yes No No Yes No Yes

No Yes No Yes No Yes No No No No No No No No

Yes Yes Yes Yes Yes Yes No Yes Yes Yes Yes Yes Yes Yes

Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

Key: NN: Netscape Navigator 5.x, loading unsigned applets over the Net NL: Netscape Navigator 5.x, loading unsigned applets from the Local file system AN: Appletviewer, JDK 2.x, loading applets over the Net AL: Appletviewer, JDK 2.x, loading applets from the local file system JS: Java stand-alone applications8

Their testimonial evidence, however, should be corroborated through independent observations or tests whenever possible. CONCLUSION

Exhibit 3 shows a summary of a secure applet’s capabilities. Exhibit 3 is not meant to be an exhaustive list of a secure applet’s capabilities, but is meant to answer the questions one hears most often about what secure applets can and cannot do. Finally, application controls should provide assurances that computers and the applets they contain are properly protected against theft, loss, unauthorized access, and natural disaster. Reviews might consider: • • • • •

Are two persons present in the computer room at all times? Does the enterprise have an emergency disaster recovery plan? Have responsibilities for computer security been formally assigned? Is a periodic risk analysis performed and documented? Is access to the computer room controlled through use of some physical device (locked door, security badges, etc.)? • Is computer software used to control access to the computer system by identifying and verifying people who try to gain access? Auerbach Publications © 2000 CRC Press LLC

DAT A S EC URI T Y MA NA GEMENT

• Is the disaster recovery plan periodically tested? • Is the responsibility for storing magnetic data clearly documented? Furthermore, controls that are incorporated directly into individual applications are intended to ensure accurate and reliable processing of applets. They address the three major operations of data input, data processing, and data output for the enterprise. Notes 1. The client is the computer that displays the Web page that contains an applet. The terms “server” and “client” are sometimes used to refer to computers, and are sometimes used to refer to computer programs. For example, www.sun.com is a server, and the httpd process running on www.sun.com is its server process. My computer at home is a client, and the Web browser running on my computer at home acts as the client process. 2. An applet is a Java program that is run from inside a Web browser. The HTML page loaded into the Web browser contains an tag, which tells the browser where to find the Java .class files. For example, appletviewer http://foo.com/~jo/coolApplet.html. 3. Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 U.S., 1999. 4. The “~” (tilde) symbol is used on UNIX systems to refer to one’s home directory. If one installs a Web browser on the F:\ drive on your PC, and creates a top-level directory named .hotjava, then properties file is found in F:\.hotjava\properties. 5. Do not try to link to this URL; it is only an example. 6. A server is the computer that hosts the Web page that contains an applet. The .class files that comprise the applet, and the .html files that reference the applet, reside on the server. When someone on the Internet connects to a Web page that contains an applet, the server delivers the .class files over the Internet to the client that made the request. The server is also known as the originating host. 7. Application controls are methods and procedures designed for each application to ensure the authority of data origination, the accuracy of data input, integrity of processing, and verification and distribution of output. 8. A stand-alone Java application is a Java program that is run by invoking the Java interpreter. For example, java coolApplication

John Vacca is an information technology consultant and internationally known author based in Pomeroy, Ohio. John can be reached on the Internet at [email protected].

Auerbach Publications © 2000 CRC Press LLC