Papers in PDF format

Display
Password
Screen
Check User
in Database
yes
no
Valid
User?
Generate
Ticket
Process
Form Data
Script Actions
Store Ticket
in Database
yes
Valid Ticket
For User?
no
Figure 2: The Security Loop
Generate
New Form
Form sent
to Browser
by Server
Check Ticket
in Database
User Submits
Form Data
Server Executes
Script
4. Generate New Form: Based on the results of the processed form or current state associated with the user, a
new form is generated (for example displaying the results of a query or notifying the user of errors in a
form they have completed). The username and ticket must be added to any form destination or link
definition so that the next script can execute securely.
5. User Interaction with the Form: The Web server passes the new form to the browser, which in turn displays
it to the user. When the user submits the form, the form data is then passed back to the Web server which
executes a new script to process it. This script begins the cycle again.
The only way that a user can access the application is by entering via the login screen. Because every other
script must be accompanied by a username and a ticket there is no other way to enter the secure loop. Since we
keep the usernames, passwords and tickets in the application database, the Web interface is as secure as
directly accessing the database through other client/server interfaces.
3.2.3 Caching
Caching decreases the time required to access Web documents by temporarily storing them in an intermediate
location. Pages copied to a local computer can be displayed more quickly than if retrieved from a remote site.
If results of CGI scripts are cached by an Internet Service Provider or cached locally by a browser, sensitive
information could be made available to anyone with access to the cache. Though recent developments in
caching have reduced this problem [Gwertzan, 1996], timed invalidation of tickets can prevent an
unauthorized user from entering the secure loop from the starting point of a cached document.
4. Form Consistency and Maintenance Issues
In a "user-friendly" application, invalid data entry should result in instructive error messages, or valid entry
should result in context sensitive verification screens. Because of the inherent "statelessness" of Web
applications, these common tasks are difficult to implement without somehow associating form contents and
other important information with individual users. In this section, we introduce the “swap,” which solves this
problem by associating tag/value pairs of strings with a user and the current screen they are using. Also, we
present methods to improve the ease of development and maintenance of scripts that implement input forms.