In a courseware document, the user may be presented with the specification or design of some system. This will generally have special behaviour designed to enhance the user's knowledge. However, when statically presented there are often limits in the understanding that can be reached due to the information only giving one view of the system. It is often more desirable to allow the receiver of the knowledge to ``play'' with the system, adjusting parameters or design aspects, and observing the effect on the system. Such interaction cannot be forecast completely in advance, so an attempt to define all possible variations and cater for it in the courseware is usually doomed to fail. It is desirable to allow for an open-ended interaction with the system.
The courseware considered in this paper is concerned with learning a programming language Lecture Notes For Operating Systems [HREF1] . In doing this, many example programs are presented, each with the intent of illustrating some aspect of the language or of algorithm design or implementation. Just by presenting material, little is offered that is better than a paper-based textbook. However, most GUI browsers will allow selection of text, and pasting into another document, so that an active user will be able to select an example program and paste it into an editor for execution. Once there, it can be modified and experimented with. Despite this, it involves a degree of knowledge and motivation by the user that may be missing (remembering that they are often far from expert with the environment). It would be advantageous if there were mechanisms within the Web document to encourage such exploration directly.
The courseware problem dealt with here is an extreme version of a quite common problem. For example, a fluid dynamics document may illustrate fluid flows around a shape, and various fluid parameters may be set for the diagram to be drawn by software such as Mathematica. Alternatively, in a course on functions, the function to be sketched may be a user-set parameter. Moving closer to our example, the courseware may be exploring the use of macros in spreadsheets, where the user experiments by setting different macros.
This paper looks at a variety of methods that can be used to encourage this type of exploration. It is in fact very easy to set up a mechanism that will allow this, but which can be abused by an unscrupulous user to the extent of compromising the system delivering the courseware. This is discussed in the next section. The following sections address means of solving this by shifting responsibility for aspects of the interaction over to the client (browser) side. This is all done within the context of standard browsers and servers upto HTML version 2. The adequacy of these methods is then discussed. The remaining sections look at experimental or proposed methods with the aim of seeing if they can overcome the remaining problems. These include: HTML version 3 scripting support in Forms HTML Version 3 [HREF2] and Java Java Home Page [HREF3] support for scripting applets. Two solutions to this problem are then presented, using firstly the Common Client Interface CCI Specification [HREF4] , and secondly a proxy server running locally with the browser. The solutions allow a range of other posssible uses, which are touched upon. Some outstanding problems and conclusions are then discussed.
/cgi-bin/) then the server will
attempt to execute the URL as a program,
and return the output back to the browser as a document. For the courseware
we are considering - learning a programming language - the server program
should compile and execute a program in the language, returning the output
to the user. For example, a suitable CGI
Bourne shell script to compile and execute
``hello world'' in C might be
hello.c,
compile it to hello if possible, and either execute it or
return the compiler errors. Then it will clean up all files created doing
this.
(The CGI script does all stages of compile, link, execution, etc. This
avoids any need to maintain state across different CGI programs, which
would be considerably more complex.)
USER_INPUT.
The program will be extracted by the CGI script from the environment,
decoded (as spaces get replaced with +'s, etc), compiled and run.
This can be done with a variant of the CGI script above.
The output will appear as a new page in the browser, and by using the Back and Forward buttons the user will be able to flip between source and output.
The following figure illustrates the information flows:
There is a huge security penalty to this though. The user can change the
program to anything, including to programs that attempt to crack
the server system. Admittedly the CGI script will most likely be running as
user nobody (if the server is correctly set up), but it still
leaves any intruder access to the server system. It should be noted that an
aggressor need not even use the Form at all, but can directly attack the
/cgi-bin/runprog.sh program.
The insecure path from browser to server is shown in red in the above figure.
There is also a fundamental problem in the amount of interaction that is allowed, because the user cannot interact with the program during execution. If the program requires user input then that cannot be given as there is no link between the input to the program and the user. In fact, the program will generally hang, with no possibility for the user to do anything but press the STOP button to halt the execution of the CGI script.
Consequently, this is an unacceptable solution. The server cannot trust the clients to send ``safe'' programs for server-side execution, and runtime interaction with the program is not possible.
Each client usually
maintains a file of MIME types that it recognises, based on file
extensions, such as /usr/local/lib/mosaic/mime.types.
In addition it
maintains a list of handlers for each type, such as
/usr/local/lib/mosaic/mailcap.
So the client can define a new MIME type
.sh in the
mime.types file, and a handler for this type as
mailcap. Each document of type
application/x-shell is now an ``active'' document, executing
on the client side.
If the server now sends a file of type application/x-shell, the
client will then call a shell on it. The CGI script which originally
executed on the server side can be modified by changing the Content-type,
and sending a script down to the client instead. For simplicity, we shall
just send ``hello world'', instead of the program as received from the
client, and will omit the compiler checks:
echo's to standard output the entire shell script that
constructs, compiles
and executes the program, so that the client receives
this as content, and passes it off to a shell /bin/sh as
handler for application/x-shell files. The shell on the client
side now executes the shell script, which builds and runs the user's program,
writing its output to the standard output on the client side.
The following figure illustrates the information flows:
Assuming that we stick to Unix only, the shell script still assumes use of
a compiler cc. For more complex programs it would need to make
further assumptions, such as ANSI-C compatability, or POSIX compatability
for systems programming examples. This can be handled by
programs such as configure which is commonly used by GNU
programs to determine their environment, and which edits the program before
compilation to reflect foibles of any particular environment.
This may mean that the program finally executed is not quite the same as
the program submitted.
Other courseware documents would have their own set of variants, such as requiring the appropriate version of the software to be available.
In addition to the compilation environment, though, there is also the
presentation environment. In the Unix world this may be vanilla X, a
proprietary X (which may have renamed common programs like
xterm) or a character mode tty only. Displaying to stdout may
be inappropriate in an X environment, but existence of xterm
may not be guaranteed. In MSDOS, Microsoft Windows may or may not be
running.
There is also the issue of what happens when the program requires input.
There may be a need to arrange an input mechanism. For example, the input
may need to be directed from /dev/tty (under Unix).
These variations may be handled by adding more ``environment'' fields to the Form (like the ``Unix'' and ``MSDOS'' buttons), but the complexity of this, and the need to repeat this configuration information for all Forms begins to threaten the viability of the active document approach.
For none of these systems do we have the possibility of giving the presentation back to the browser, as the handler is external to the browser. Possible use of the Common Client Interface to resolve this is discussed later.
In addition to these problems, there is also the security issue again. As
seen, the server may need to modify the program that the user sent over in
order for it to run in the user's environment. More drastic possibilities
are open though. The server could send any program back, and this would
generally be executed under the user's id, not as nobody. The
problem here is that the client may not trust the server. There is probably
less likelihood of a server attempting to infiltrate a client system than
the other way round, but the possibility cannot be discounted.
On the client side, the client can define a new MIME type
.c in the
mime.types file, and a handler for this type as
mailcap. Each document of type
application/x-cprogram is now a ``passive'' document,
and the program C-handler on the client side will process it.
The C-handler can compile the program using the local C
compiler, and execute it in the local presentation environment.
For example, to run C-handler as a Korn shell script,
using the gcc compiler, displaying results in an
xterm:
pauseme is a shell command that executest the program
and then waits for a line of input (this is to stop the xterm from
executing the program and vanishing)
The methods discussed in this section on passive documents
answer many of the issues for this
type of problem. Many of the matters relating to the client side, such as
compiler, presentation environment, ability to interact with the executing
program, are all dealt with on the client side. There is the matter of
setting up the C-handler, but this could be done by a once-off
Form, or in a LAN by the system administrator installing suitable handlers
on each type of system.
The following figure illustrates the information flows:
There still remains the problem of security. The desired program is sent on a round-trip across the network, with at least the server having a role in manipulating the information. There are issues of snooping, or of an malignant players altering messages while in transit across the network. Such problems are being dealt with by encrypting messages before transmission, as is done in current versions of Netscape, for example Netscape Home Page [HREF6].
This type of problem is well-known in the PC world, where there is a
continual battle between virus creators and those attempting to detect
them. It has also been recognised as a problem in the arena of ``active
mail'', where mail messages execute on the receiver side. There is a
solution in that arena, and that is by using a ``safe'' language that
is guaranteed not to do damage, such as safe-tcl [Borenstein94].
Here, the courseware may be for any language, not just safe ones. There will be little chance to detect, from the program itself, any inbuilt malignancy. Instead, means must be sought to ensure that only the program sent is actually received.
These problems could all be resolved by handling everything locally, but that will involve non-standard changes to the client, as discussed later. For now, we seek solutions within the context of standard servers and browsers.
The PGP (Pretty Good Privacy) system is a public/private key system in which messages can be encoded using one key and decoded using the other [Garfinkel95]. To ensure that a message can only be read (or verified) by a particular recipient it should be encrypted using the public key of the recipient, who can then decode/verify it using their private key. The general intention is to use this for one party to talk securely to a separate party, using their public key. However, it can also be used to ensure that a message to oneself has not been tampered with in its travels by encrypting it with your own public key and later decrypting it with your own private key. In addition to encryption, documents may be digitally signed with the private key, so that origin and contents may be verified using the public key.
A Form has an attribute of ENCTPYE, which defaults to
application/x-www-form-urlencoded.
No other value is part of the HTML standard.
However, the NCSA server and Mosaic browser have a compile-time option that
allows them to use PGP or PEM (Privacy Enhanced Mail) encodings.
The purpose of these encodings is to ensure secure transmission from client
to server, and vice versa. So when a client sends a GET
command, PGP
encoded, the entire GET request is PGP encrypted using the public key of
the server and signed using the user's private key.
On receipt the signature is checked (and removed) and the message is
decrypted.
The encoding and
decoding mechanisms are controlled by resources on the client side, and the
httpd.conf file on the server side. The
PGPEncrypt and PGPDecrypt resources and
PGPEncryptCmd and PGPDecryptCmd
values point to files on the client and server sides respectively that
perform the encryption and decryption.
There is a set of default files supplied to perform these tasks. However, they are not adequate for our purpose since they are set up for the one-way trip rather than the round-trip required here. The default files ensure security during transmission to the server, but then the encryption and signature are removed. We need the signature to stay. We cannot directly change this for our needs, but we can subvert it.
If the client needs to digitally sign its outgoing message, then it needs a place to do this. The PGP encryption file is a suitable place: when a callout is made to it, firstly sign it with the client's private key, and then allow the default server-key encryption and signing with the client's private key to take place. That way a secure message is transmitted, and also a digitally signed document delivered. When this is returned, the client can verify it came from itself. If desired, the extra wrapper could be turned off, but why not leave it there?
There are of course, a few technical details:
the mesage to be PGP encrypted and signed is a full GET message,
with all of the extra
components beside message contents (such as the list of allowable return
types). We only want to sign the actual message content with the client's
private key since only the message will be returned, not all of the extra
information.
So the actual message has to be stripped out first before signing it
and adding the signature to the contents.
In addition,
the client would only want to place this additional signature on files that
it knows are going to be returned.
Otherwise, the client would be incorrectly signing messages for possibly other
servers that are employing PGP, but only as one-way security.
The GET command contains the URL of the
destination, which should be /cgi-bin/runprog.sh, or whatever
the command is on the server side that will return the program.
These can be done with a straightforward shell script.
The single major drawback to this is that neither the encryption method nor the means of implementing it are standard. So it may not be supported by all browsers, and there may not be this way to ``subvert'' the technique.
There is intended to be a strict limitation on what scripts can do. They should be able to examine a small set of properties of the client such as the client's name, the time of day, but certainly not things such as being able to read and write files, or execute arbitrary programs on the client. This is for security, again.
There is an expectation that certain scripts which are trusted will be able to do more things. This trust will be what we saw earlier, the client trusting the server.
The script will have to do all the customisation work to the particular environment as well, suffering all the problems noted earlier. So this doesn't look too promising a method for this problem.
When run within the HotJava browser, Java programs are known as applets as they are not stand-alone applications.
The more recent versions of Netscape for certain platforms also contain support for Java applets.
A Java program is subject to a set of security restrictions to ensure that it cannot do damage to the client. These are similar in effect to those of HTML 3, and make it difficult to execute a compiler on the client, and impossible to run a program that attempts to access the file system. The courseware that motivated this paper used programs that did need to access the filesystem (e.g. list the files in a directory) so this is not a feasible solution for this type of couresware. Note that this is not an inherent restriction in Java, but is rather a security restriction imposed by current browsers on applets.
CCI is a TCP/IP protocol that allows an application to request Mosaic to
display a particular URL. It can also request that whenever Mosaic issues a
request for a URL from any particular server, a copy of the request is
also sent to the application. This allows an application to play both a
monitoring and a control role. This allows examples such as a ``teacher''
instance of Mosaic informing an application xwebteach whenever
it fetches a URL, and xwebteach in turn informing a set of
``student'' instances to fetch the same URL.
The way we can use CCI is quite straightforward. An application can be written
using the CCI library that just monitors the fetching of URL's. This can
run locally, with the browser. Each time
a URL containing /cgi-bin/runprog.sh is fetched, the local
application will decode the program being sent and execute it and display
it locally. Meanwhile, the server will just ignore that http reference,
or more precisely, send back a document that will not be displayed. For
example, send back a document type of application/x-true that
just executes /bin/true on the client side (with suitable
setup of the mailcap file).
This method almost avoids all security issues, as the program to be executed
would be sent directly from the browser to the application that compiles
and executes it. There is still a problem with
the inherent lack of security in the way that
Mosaic allows an application to talk CCI to it. The user of Mosaic must
explicitly request the ability for external applications to talk using CCI
by turning CCI on and stating which port to use, either by a menu selection
or by resources set in e.g. .Xdefaults. Once enabled, any
application is able to talk CCI to the browser. There is no password
protection, host-based protection, etc.
This is only likely to be a problem if CCI is enabled but the desired application has not connected to it. Even then, there is very little that a different aggressive application can do that is not just nuisance value. The chance that an aggressor will even find an instance of Mosiac in such a state, with a port number that it can use, is very slim. So in practice this should be pretty safe.
The local application can know about the local environment, and perform
appropriate actions, such as using gcc and displaying in an
xterm. It shares with the other local execution methods one
not really desirable feature: the display is done externally to the
browser, unlike the server-side execution by CGI, that returns the result
as an text/plain for display by Mosaic.
A component of the CCI protocol is that an application can ask Mosaic to
DISPLAY a document that is also sent from the application.
This would allow the application to compile and run the desired program,
and package the output for Mosaic to display. Unfortunately, implementation
problems (the need to save the document locally so that it has a real URL) mean
that this component may be dropped. Certainly, it is not implemented in
either the CCI library or in Mosaic. This would be unfortunate - it seems
to be a problem with the internal structure of Mosaic rather than something
inherent in the HTTP protocol. The problem of handling user input may
remain, though.
The following figure illustrates the information flows:
What is required is that certain CGI scripts, those which compile and run
a program, should be intercepted and executed locally. The CERN server
is suitable for this without any modifications apart from to the
configuration file. We can set an Exec rule to look for
particular CGI scripts and translate them into local execution:
With this rule in place, the script given earlier of
The intent is that the script should be run locally, on the same system as the browser. This means that it will be easy to configure the CGI script for the local environment, which is where the courseware is being used. If interactive programs are run, this could call suitable interactive environment such as an xterm, for example:
Although the proxy server may be run with the expectation of local use
only, it can be accessed from other systems. The ability to send the
proxy server an arbitrary program from anywhere suffers the
same security problems as initially faced for a normal server. Thus it is
necessary to restrict access to the proxy. We consider that host-based
protection is adequate: if someone already has an account on a system,
then they are unlikely to waste time attacking it through scripts
running as nobody when they could do so more directly.
The CERN server can restrict access to the local system by means of
a configuration rule
This is the access scheme implemented as solution to this problem. It is
run on a network of computers using NFS file sharing. Netscape is
configured to use a proxy running on localhost. Each server
is configured to allow access to localhost using the
same shared configuration file, and runs the trapped CGI scripts locally.
Note that there are other possibilities for this. One single host could run a proxy, with Netscape configured to use this. This would reduce the number of proxies, but leave the single machine handling all programs. This machine would also have to be capable of running an xterm locally, wiht display on the other machines. This could be useful in a heterogeneous network, with, say, Unix programs being fired up from a browser on a PC.
The following figure illustrates the information flows:
To perform I/O between a program and the user, where the I/O display is managed by the browser, some suitable area needs to be set up for this within the browser. This could be, for example, a TEXTAREA within a Form, or a specially created Text entry and display box. By whatever means the program is being run, when output occurs from the program it must be copied across to this I/O area, and vice versa: whenever the user types into the I/O area the input must be made as input to the program. In the Unix model, this may be line-buffered, but in the MSDOS model it would be raw.
To perform this type of I/O, the browser must contain something that will be able to access key actions occurring in the browser, and similarly generate such actions. There are a variety of possibilities for this: the replayXt system of the author [Newmarch94, HREF7 ], the HTML version 3 Form scripting capabilities, Java, etc.
If a CCI method is used to run the program, then the extension to CCI described by Newmarch in [HREF8] will enable tracking of user events such as keypresses to be monitored. However, an extension of this will still be needed to allow dynamic update of the display as the CCI program executes.
Similar concerns arise in a proxy server model. There is a need for higher-bandwidth communication between the client and proxy server in order to communicate GUI-level information in addition to HTTP information.
Programs that require interaction cannot be run from the server side, and anyway security dictates that this should not be done anyway. The exception to this is when server-side execution cannot do any damage to the server. In this case, nothing more is required than CGI.
If security on the client side is not a problem, then ``passive documents'' sent to a handler on the client side can be done quite simply, and answers the problems of interactive I/O and local customisation of environment. This requires a reasonably straightforward setup to be done on both sides.
If client-side security is a problem, then PGP can be used in a slightly non-standard way. It involves special compilation of client and browser, and more complex setting up. Since this is not an HTML standard, there is no guarantee that all browsers and servers will be able to use this.
Looking at some of the proposed extensions to existing browsers, the CCI method offers a simple solution that avoids nearly all security problems. This is currently only offered in Mosaic for X, version 2.5. However, the interaction with the runnig program must be done outside the browser.
A number of browsers support proxy servers. For these, a proxy server can be built that can run on the client side, answering this and possibly a number of other problems.
Some proposals are made that will allow the I/O of the program to be brought within the browser. These require client-side execution of a scripting system capable of capturing and generating actions, along with other hooks to allow an agent to interact with the browser. A more novel proposal allows GUI components to be created within the browser.
There has been one unstated assumption about all of this, and that is the server will not send as courseware an openly malignant program, even though it may attempt to interfere with a round-trip message. This of course may not be the case. It is quite possible that courseware could be written that says
There is a certain expectation of the user that they will not attempt to execute a program that they do not reasonably well understand. The validity of this expectation may be open to doubt...
| Pointers | |||
|---|---|---|---|
| Conference Presentation | Papers & posters in this theme | All Papers & posters | AusWeb96 Home Page |
AusWeb96 The Second Australian WorldWideWeb Conference ausweb96@scu.edu.au