Systems and Methodologies for Identifying and Protecting Weak Spots in Your Web-Enabled Database -- Before Someone Else Does.
As the use of the Web grows on both Intranets and the public Internet, information security is becoming crucial to organizations. The Web provides a convenient, cheap, and instantaneous way of publishing data. Now that it is extremely easy to disseminate information, it is equally important to ensure that the information is only accessible to those who have the rights to use it.
With many systems implementing dynamic creation of Web pages from a database, corporate information security is even more vital. Previously, strict database access or specialized client software was required to view the data. Now anyone with a Web browser can view data in a database that is not properly protected. Never before has information security had so many vulnerable points. As the computing industry moves from the mainframe era to the client/server era to the Internet era, a substantially increasing number of points of penetration have opened up.
For much of Internet security, database specialists have had to rely on network administrators implementing precautions such as firewalls to protect local data. Because of the nature of Intranet/ Internet information access, however, many security functions fall into a gray area of responsibility. This article describes the primary areas where security falls within the domain of the DBA, who must create the information solutions.
New security procedures and technology are pioneered daily, and this article explains the various security systems involved with solving the current problems. This article should provide a primer for further study of Web security and a framework for understanding current security methodology. For Web security, you must address three primary areas:
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.
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).
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.
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.
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.
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.
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.
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. (See Figure 2.)
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-key system.
SSL uses Secure HTTP (S-HTTP) as its basic transmission protocol. This protocol is a variation of HTTP that provides the secure foundation for SSL transmission. S-HTTP performs what is known as a handshake when establishing a connection to exchange keys and creates an encrypted connection. Addresses to an SSL secure page use the prefix "https" instead of the common "http." Therefore, a secure page address would read https://www.dbmsmag.com.
The public-key system requires that each party has a public and a private key. These keys must be generated by a trusted source. For Internet broadcast, a few companies offer this service, the largest of which is VeriSign Inc. (Mountain View, Calif., www.verisign.com). Generating a key costs about $300 per server for the first year and around $100 for each year after that. You must wait between two and three weeks to receive a key.
Intranets, however, have just as much reason to protect their data. In fact, the National Computer Security Association (NCSA) estimates that perhaps as much as 80 percent of an organization's security breaches occur within that organization. For private database information, all the authentication in the world won't prevent packet sniffers from intercepting data that is sent across the network. For this reason, organizations have begun to set up their own public-key servers.
A Certificate Server enables a company to become its own trusted key generator. Rather than having Verisign generate the public/private key pair, a Certificate Server within the company creates the keys and stamps its creator name on each key.
The public keys themselves are also kept on file on the server. A user can request the public key of John Smith to decode a document supposedly sent by John Smith. If the document wasn't encrypted with Smith's private key, the public key on the Certificate Server will not decode it properly.
Encrypted private keys could then be stored on servers, in smart cards, or on your credit card. Access to a database, for example, would only be permitted by sending a certain code encrypted with your private key. The encoded document is received by the user authentication program, it is decoded with your public key, and access is granted.
Kerberos has a function similar to that of a Certificate Server: It serves as a guardian, ensuring that a user is identified and validated. Using tokens and various other technologies, a Kerberos system creates a secure distributed network. Combined with public-key transfer, Kerberos may prove ubiquitous in the deployment of Web security over the next few years.
Oracle also modified the HTTP protocol to allow a state connection to be established between the client and the server. This connection actually defines a session in which the user is identified by a generated ID to identify the user.
These enhancements are present in the Secure Network Server (SNS) included in the Oracle Universal Database. The SNS incorporates support for the Kerberos security standard. Through a Kerberos system, a single login permits access to any Oracle database in an enterprise system. The Java security classes are used by the Oracle development tools to provide complete security integration with the client.
Sybase provides a piece of middleware called Web.sql that is used to interface with the Netscape Web servers. Communication between the Netscape Suitespot servers and the database passes through the API for Web.sql.
With Internet Information Server (IIS), Microsoft has included most of the key security technologies. For user authentication, Microsoft provides its tried-and-true challenge/response mechanism. Traditional login on the Web features the same security present at basic Windows NT login. Unfortunately, only the Microsoft Internet Explorer browser supports this login approach, and Netscape has made no announcements to integrate it into Navigator.
For database access, Microsoft has integrated IIS security with Microsoft SQL Server through the Internet Database Connector. User logins must occur through an HTML login form, but the information may be verified using a SQL Server stored procedure. Look for better integrated security with the release of SQL Server 7.0.
Microsoft is also integrating the Kerberos security architecture into Windows NT Server 5.0. By releasing the server, Microsoft hopes to integrate the Kerberos native to NT Server with public key security. Microsoft already released a Certificate Server API in an attempt to create a Certificate Server standard.
Currently, user authentication occurs by passing information to the data source via middleware. Most companies, including Sybase, Oracle, and Informix, provide the necessary connectors for this process to occur.
Netscape's Certificate Server will be the cornerstone of this secure system. It can generate a key pair (public and private keys) for users and store the public certificate for automated retrieval. Netscape positions its Certificate Server along with SSL/S-HTTP as the primary means of providing security for Web access. The Certificate Server complies with the public standard X.509, SSL, PKCS, and LDAP.
Cold Fusion handles user authentication by passing the username and password through the ODBC data source for authentication. Unfortunately, these pieces of private information are sent across the network unencoded. Therefore, for true security, make sure that this information transfer occurs used only under an SSL-encoded session or when security is not crucial.
Database and Web server vendors are constantly upgrading their systems, so staying current on the particular architectures is a must. For general security information available on the Web, the best place to begin your search is with the National Computer Security Association (NCSA) at www.ncsa.com.
Figure 1.
--A Netscape Security Access dialog.
Figure 2.
--Encryption with private key, and decryption with public key.
April 1997 Table of Contents | Other Contents | Article Index | Search | Site Index | Home
DBMS and Internet Systems (http://www.dbmsmag.com)
Copyright © 1997 Miller Freeman, Inc. ALL RIGHTS RESERVED
Redistribution without permission is prohibited.