Security Issues
Depending upon the application, security issues must be addressed any time sensitive information is involved. Listed below are three security measures which can be incorporated when developing a Web interface.- Domain restrictions
- Username / password authorization
- Mid-entry prevention
<Limit> allow from utk.edu </Limit>By using this code segment, all documents in this directory are only accessible from clients running on machines within the domain utk.edu. These documents could include a top-level HTML form. In a similar fashion, a username and password authorization can be implemented.
A third security feature which should also be considered is called mid-entry prevention. Passwords and domain restrictions can easily be used to prevent outsiders from accessing the top-level interface of an application. However, if an interface goes multiple-levels deep, then it is also a good idea to prevent clever, yet authorized, users from deliberately jumping into the middle of the interface and supplying new values. The problem in some applications is that state information must be passed from one interface to the next. This information is sometimes passed using the "hidden" HTML forms tag. While information passed using this tag is not shown on the browser's window, this information is accessible by viewing the document source code. Hence, it is possible that a clever user could examine the document source of a script, find the parameters and variable names used, and recreate a different HTML page to pass forged values on to the next script.
This problem can be avoided by examining the value of the CGI variable HTTP_REFERER. If the value of this variable does not match the previous link from the Web interface, then an error message should be returned. This variable was designed to help perform logging, optimize caching, and tracing obsolete or mistyped links; but it can also be used to help prevent mid-entry into a secure Web interface.
Concurrency Issues
One of the biggest challenges in developing interactive Web interfaces is handling concurrency control. Concurrency control is the process of controlling concurrent access to a resource to ensure that the correctness of the resource is maintained. If a web application allows users to directly update information on-line, then concurrency must be considered. If this issue is ignored, undesirable consequences might result such as information being overwritten or lost.Traditional non-Web based interfaces are connection oriented and solve the concurrency control problem by locking resources. The resources are locked while they are updated to avoid conflicts, and then are released when a transaction is completed or the connection is broken. Because of the connectionless nature of the WWW, locking resources on the Web is not simple. The problem with locking resources on the Web is that a user may fail to reach a state that unlocks the resource and because there is no connection to be broken, this resource could remain locked thus inconveniencing other users.
When using the Web, concurrency control can be solved using one of two different methods.
- Do not allow real updates. When using this method,
concurrency problems are avoided by queuing requests and
then sequentially performing time-stamped inserts.
The problem with this approach is that the information is not
always accurate and up-to-date.
- Use time-out locking. When using this method, concurrency problems are avoided by assigning locks to resources for a specified time period. Although, this approach may be slightly more difficult to implement, it ensures that the information is always accurate and up-to-date.
Considering the power and flexibility that the Internet offers, one can expect more Web-based office applications to be developed in the future. One office application which the author has helped develop is a Web-based scheduling and calendar interface. The interface is called SCOUT and can be experimented with at (http://www.admin.utk.edu/scout). This interface allows faculty, staff, and students at the University of Tennessee to store their scheduling and calendar information at a web site. By using a WWW browser, users can directly access and modify their personal appointment calendars from any computer on campus or in the world.
To illustrate how closely a Web application can resemble a traditional MS-DOS/Windows or X-Windows applications, and to provide some insight and pointers into developing a user-friendly Web application, the SCOUT interface will briefly be examined. The SCOUT interface uses time-out locking for concurrency control and incorporates the three security measures mentioned earlier.
The SCOUT application is composed of five different screens and uses four different CGI Perl scripts. To help the user reference the screens, a labeled image is displayed in the upper right-hand corner of each window as shown in Figure 1. Our experience has shown that these labels can be very helpful when users are reading on-line documentation, asking support questions, and navigating through the application. By clearly labeling each screen of the Web interface, the users can more quickly become fluent with navigating through the application.
Figure 1
For the first screen capture, the entire browser window is shown to give you an idea of how SCOUT appears on your monitor. The remaining screens displayed in this paper have been cropped to only show the contents of the browser window.
As shown above, the first screen welcomes the user to their calendar and allows them to quickly select a month. When the current month is selected (option #1), the UNIX "date" command is invoked to find the numeric value of the current month. Given this numeric value, the UNIX "cal" command is then executed and produces an ASCII version of the current month. With a little conversion, this information is formatted into HTML and displayed as shown in Figure 2. Once displayed, the user can select to view appointments for a specified day, week, or the entire month.
If a user wants to limit viewing access to their calendar, they can add domain restrictions and username/password authorization by placing access restrictions in the directory that contains the HTML file which corresponds to the first screen shown in Figure 1.
Figure 2
In this example, the user has chosen to view only the appointments for Monday, April 22, 1996. A nice feature which this interface incorporates is the ability to quickly navigate back and forth. For example, options exist to allow the users to quickly display the "previous" and "next" months. To pass selected information from one CGI script to the next, the HTML input tag type "hidden" is used. In this example, the date April 22, 1996, is passed to the next script which displays an output similar to Figure 3.
Figure 3
Figure 3 shows three appointments have been scheduled for Monday, April 22, 1996. In addition to displaying appointments, this screen allows the user to add, modify, and delete appointments. For example, when the "Add" button is pressed, a screen similar to the one in Figure 4 is displayed.
Figure 4
Figure 4 shows an additional meeting being scheduled from 3:30 to 4:00 P.M. Select tags quickly allow the user to choose a start and stop time in half hour increments. If an appointment needs to be scheduled for a time which is not on the half hour, the user can enter these times in the input boxes to the right of the pull-down menus.
To make a modification, another username and password are entered, authentication is verified, and if approved, a message similar to the one in Figure 5 is displayed. This second username/password authorization is independent of the HTTP server, providing an additional level of security. However, because most users quickly get tired of entering their username and password every time they modify their calendar, a remote host can be specified so that changes can be made from the specified hosts without having to enter a username and password.
The entire calendar is stored in a single ASCII file in HTML format using the tabular environment. Each entry is composed of three columns. The columns correspond to 1) start time, 2) stop time, and 3) description of the appointment. The appointments are stored chronologically by start times. For example, the contents for April 22, 1996, are stored as follows.
<1996-04-22> <table CELLSPACING=1 BORDER=1 CELLPADDING=4> <tr> <td>8:30 AM</td> <td>9:30 AM</td> <td>Council on International Education (4th floor Conference Room)</td> </tr> <tr> <td>1:30 PM</td> <td>3:00 PM</td> <td>Staff Meeting - (5th floor Conference Room)</td> </tr> <tr> <td>6:00 PM</td> <td> - </td> <td>ACM Banquet - (Hermitage Room)</td> </tr> </table> </1996-04-22>
Before performing the final step of modifying a calendar, the last CGI script also ensures that an illegal jump was not attempted. An illegal entry is performed by examining the CGI environment variable $ENV{HTTP_REFERER}. The value of this variable should match the URL of the previous CGI script.
Figure 5
Conclusions
Web applications and interfaces such as SCOUT are proving that the Web is much more than a server protocol for transferring static documents. Considering the power and flexibility which the Web offers, developing Web-based interfaces for future applications might help position organizations for the rapidly changing electronic world which we live in.
Hypertext References
- HREF 1
- Guidelines
for Multimedia on the Web, Jakob Nielsen, Sun Microsystems, Inc.,
December 1995.
(http://www.sun.com/951201/columns/alertbox/)
- HREF 2
- Mosaic
User Authentication Tutorial, NCSA HTTPd Development Team,
National Center for Supercomputing Applications,
University of Illinois.
(http://hoohoo.ncsa.uiuc.edu/docs/tutorials/user.html)
- HREF 3
- Mosaic
Forms Database Access: A Palaeobotanic case study, David Gee and Mike
Boulter, International Organization of Palaeobotany, University of East
London.
(http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/GenSci/gee/pfrwww.html)
- HREF 4
- WWW-to-PAT
Gateway: Exploiting an SGML-aware system through the Web,
University of Michigan,
June 18, 1994.
(http://sansfoy.hti.umich.edu/www-to-pat/)
- HREF 5
- RAD Technologies - Where Multimedia Gets Down to Business on the World Wide Web, RAD Technologies, Inc., Palo Alto, California. (http://www.rad.com/rad/company/overview2.html)
Copyright
William Rosener ©, 1996. The author assigns to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grants a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers, and for the document to be published on mirrors on the World Wide Web. Any other usage is prohibited without the express permission of the author.| Pointers to Abstract and Conference Presentation | |||
|---|---|---|---|
| Abstract | Papers & posters in this theme | All Papers & posters | AusWeb96 Home Page |
AusWeb96 The Second Australian WorldWideWeb Conference "ausweb96@scu.edu.au"