Session security -- ensuring that data is not intercepted as it is broadcast over the Internet or Intranet

You can view these layers as layers of protection. For each layer of security added, the system becomes more protected. Like a chain, however, the entire shield may be broken if there is a weak link.

Server Security

Server security involves limiting access to data stored on the server. Although this field is primarily the responsibility of the network administrator, the process of publishing data to the Web often requires information systems specialists to take an active hand in installing and implementing the security policy.

The two primary methods in which information from databases is published to the Web are the use of static Web pages and active dynamic Web page creation. These two methods require almost completely different security mechanisms.

Static Web Pages

Static Web pages are simply HTML files stored on the server. Many database specialists consider static page creation the simplest and most flexible method of publishing data to the Web. In a nutshell, a client program is written to query data from a database and generate HTML pages that display this information.

When published as static Web pages, Web files can be uploaded to any server; for dynamic creation, however, the Web server usually must be modified (or new scripts or application software installed). Static pages have the secondary advantage of being generated by traditional client/server tools such as Visual Basic or PowerBuilder. Because almost any development system can output text files, only the necessary HTML codes must be added to make them Web pages. The creation of the pages, therefore, uses standard methods of database access control such as database security and login controls.

Once created, the files must be uploaded to the Web server. Protecting the documents stored there occurs in the same manner that any other Web documents would be secured. One of the most straightforward ways to protect sensitive HTML documents is to limit directory browsing. Most FTP and Web servers allow directories to be configured so that files stored within them may be read but the files may not be listed in the directory. This technique prevents any user who does not know the exact filename from accessing it. Access may be permitted by simply distributing the exact filenames to authorized personnel.

Directories may also be protected using the integrated operating system security. Some Web servers allow security limitations to be placed on particular folders or directories using standard operating system techniques (such as file attributes) and then use this security to restrict access. This implementation will vary among Web servers. These security implementations to gain access to particular files or folders fall under the user-authentication category of security (described in a later section of this article).

Dynamic Page Generation

Favored by large organizations, this method is gaining popularity as the technology to generate Web pages instantly from a database query becomes more robust. A dynamic Web page is stored on the Web server with no actual data but instead a template for the HTML code and a query. When a client accesses the page, the query is executed, and an HTML page containing the data is generated on the fly. The necessary data is filled into the slots defined in the template file in much the same way that a mail merge occurs in a word-processing program. A program may be active on the Web server to generate the necessary Web page, or a CGI script might dynamically create it.

One of the first security issues that a DBA must confront is setting up access to the database from the Web server. Whether using a CGI script, server-based middleware, or a query tool, the server itself must have access to the database.

Database Connections

With most of the dynamic connectors to databases, a connection with full access must be granted to the Web server because various queries will need to access different tables or views to construct the HTML from the query. The danger is obvious: A single data source on the server must be given broad access capabilities.

This makes server security crucial. For example, an ODBC data source given full administrator access could potentially be accessed by any other program on the server. A program could be designed to retrieve private information from a data source regardless of whether the program's author is permitted access. This security problem is most dangerous on a system where users are allowed to upload CGI scripts or programs to run on the server. To prevent unauthorized access to your data, make sure that the server that owns the database connector is physically secure and does not permit unrestricted program execution.

Table Access Control

Standard table access control, if featured in the user authentication system, is more important on Web applications than on traditional client/server systems. DBAs are often lax in restricting access to particular tables because few users would know how to create a custom SQL

query to retrieve data from the database. Most access to a database on a client/server system occurs through a specifically built client that limits access from there.

Not so with Web-based applications: Client/server development requires substantial experience, but even some novices can program or modify HTML code, and most user productivity applications such as word processors or spreadsheets that can access databases also save documents as HTML pages. Therefore, more solutions will be created by intermediate users -- and so valid security is a must. Remember, a little knowledge can be a dangerous thing.

User-Authentication Security

Authentication security governs the barrier that must be passed before the user can access particular information. The user must have some valid form of identification before access is granted. Logins are accomplished in two standard ways: using an HTML form or using an HTTP security request.

If a pass-through is provided to normal database access, traditional security controls can be brought into play. Figure 1 shows an example of a standard security login through the Netscsape Communications Corp.'s Netscape Navigator browser.

The HTML login is simply an HTML page that contains the username and password form fields. The actual IDs and passwords are stored in a table on the server. This information is brought to the server through a CGI script or some piece of database middleware for lookup in a user identification database. This method has the advantage of letting the DBA define a particular user's privilege. By using a table created by the DBA, numerous security privileges specific to a particular project can be defined.

Once a login has occurred, a piece of data called a "cookie" can be written onto the client machine to track the user session. A cookie is data (similar to a key and a value in an .ini file) sent from the Web server and stored by a client's browser. The Web server can then send a message to the browser, and the data is returned to the server. Because an HTTP connection is not persistent, a user ID could be written as a cookie so that the user might be identified during the duration of the session.

HTML form login security, however, must be implemented by hand. Often this means reinventing the wheel. Not only must a database table or other file be kept to track users and passwords, but authentication routines must be performed, whether through CGI script or via another method. Additionally, unless using a secured connection (see the section on SSL later in this article), both the username and password are broadcast across the network, where they might be intercepted.

HTML form login is excellent when security of the data is not paramount yet specialized access controls are required. Browser login is most useful when it is integrated with existing database security through some type of middleware. Even with users properly authenticated, additional security concerns arise.

Session Security

After the user has supplied proper identification and access is granted to data, session security ensures that private data is not intercepted or interfered with during the session. The basic protocols of the network do not set up a point-to-point connection, as a telephone system does. Instead, information is broadcast across a network for reception by a particular machine.

TCP/IP is the basic protocol for transmission on the Internet. The protocol was never designed for security, and as such it is very insecure. Because data sent from one machine to another is actually broadcast across the entire network, a program called a "packet sniffer" can be used to intercept information packets bound for a particular user. Therefore, even though a user has properly logged onto a system, any information that is accessed can be intercepted and captured by another user on the network. There is no easy way to prevent this interception except by encrypting all of the information that flows both ways.

Public and Private Key Security

The world of encryption is often a fairly arcane field of study. The growth -- as well as the insecurity -- of the Internet has forced users unfamiliar with even the basic concepts of cryptography to become at least acquainted with its common implementations.

Two basic types of encryption are used in Web security: secret-key security (using a single key) and public-key security (using two keys).

Secret-key security (which is also known as symmetrical-key security) is somewhat familiar to most people. A Little Orphan Annie decoder ring is a common example. The secret key, in this case the decoder ring, is used by each party to encrypt and decrypt messages. Both parties must have access to the same private key for them to exchange messages. If the key is lost or exposed, the system is compromised. Public-key security is a little more complicated.

With public-key security, each individual holds two keys, one public and one private. The public key is freely published, and the private key is kept private. Once a message is encrypted with one key, it cannot be decoded without the other key.

Using this type of encryption, someone can take a data file and encode it with your public key. Only your private key can be used to decode it. Likewise, if you encode a data file with your

private key, it can only be decoded with your public key. Therefore, the receiver of the data file knows that it came from you because only your private key can generate a file that can be decoded by the public key. This is so reliable, in fact, that it is admissible in a court of law. Only you, or someone with access to your private key, could possibly have created data that can be decoded with your public key.

The primary difference between implementing these two systems is computational. Using a secret-key system, encryption and decryption can take place between 100 and 10,000 times faster than the equivalent data using a public-key system. The private-key systems often use a smaller key, perhaps even a user password. The public-key systems use computers to generate the keys, each of which is usually 512 or 1024 bits long. That's about 50 to 100 characters long -- not easy to remember off the top of your head. Most Internet systems use a combination of the two to provide secure communication. Typically they use the public-key encryption system to encrypt a secret key (usually machine-generated based on a time code).

Both the server and the client encrypt a secret key with their private keys and send the encrypted data and their public keys to each other. Alternatively, the public keys might be retrieved from a trusted third party such as a Certificate Server (which I describe later in this article).

The public keys are now used to decode the data, so both the client and the server now have secret keys. When exchanging information, the data is encrypted with the secret key and sent between the machines. This system combines the authentication and extra security of a public-key system with the speed and convenience of a secret-public-key system.

Chapter 7