Database Security
By Dan Rahmel
Internet Systems , April 1997
Systems and Methodologies
for Identifying and Protecting Weak Spots in Your Web-Enabled
Database -- Before Someone Else Does.
Technorati Tag: Database Security
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 i
mportant
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:
- Server security -- ensuring security relating to
the actual data or private HTML files stored on the
server
- User-authentication security -- ensuring login security
that prevents unauthorized access to information
- 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. ( 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.
Secure Sockets Layer (SSL) and
S-HTTP
Public/secret-key systems such as the one I just described
are widely implemented on the Internet. Most large Internet
product developers (such as Netscape, Microsoft Corp.,
and IBM Corp.) agreed to use an encryption protocol known
as the Secure Sockets Layer (SSL). SSL encrypts all data
transmitted between a client and a server during a session.
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.
Certificate Servers
Many organizations want a way to generate and track keys
on a public-key system. A great deal of recent press has
focused on digital signatures, digital certificates, or
digital IDs. A digital signature is merely the public
key of a public-key system. There is a standard called
X.509 for the format of the digital certificates. For
example, a user can use his private key to encrypt the
text of the book War and Peace . The user can
then send the encrypted book as well as his or her public
key to another user. The public key or digital signature
contains the ID of the trusted party that generated the
key (such as Verisign and AT&T). The receiver of the
document verifies that the key used to generate it was
created by a trusted party and then decodes the information.
Only that user's private key could have encoded the document.
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.
Digital Signatures as Passwords
The real plan for the public-key system is to use it in
conjunction with the secret-key system. Rather than having
a large private key that must be transported from computer
to computer, the private key would instead be encrypted
using a secret-key system. The user then simply remembers
a simple password (like the PIN for his or her ATM card)
that is used to decrypt the private key.
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
Kerberos is a server of secured user names and passwords.
The power of Kerberos is that it provides one centralized
security server for all data and resources on the network.
Database access, login, resource control, and other security
features are centralized on trusted Kerberos servers.
Security companies are currently looking to merge Kerberos
and Certificate Servers to provide a networkwide secure
system. Invented at MIT, Kerberos was named after the
three-headed monster that guards the gates of hell in
Greek mythology -- only in this case it guards the gates
of a network.
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.
Vendor-Specific Security
Individual vendors largely determine the security scheme
that will be implemented to provide the link between the
database and the published HTML page. Following are some
of the security components provided by major vendors.
Like client/server systems, solutions must be pieced together
using multiple vendor products.
Oracle
Oracle Corp. (Redwood Shores, Calif.), while providing
SSL and S-HTTP security, is planning on using Java as
a basic component of its security model. The company created
its Oracle Web Server to work most effectively with Oracle
clients such as Oracle Power Browser and solutions created
with the Developer/2000 development tools.
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
Sybase Inc. (Emeryville, Calif.) provides a rather elegant
way of protecting data access through the Web. Rather
than construct its own custom Web framework, the logon
security present in the Web server simply passes through
to the database server for authentication, taking advantage
of the native security present in the database.
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.
Informix
Informix Corp. (Menlo Park, Calif.), like Sybase, currently
relies on the logon security present in the Web server.
Therefore, any access is specified through traditional
ODBC-type login channels, passing the user and password
information through the connectivity middleware. Specific
drivers called Universal Web Connect are available to
integrate Informix database security with both Netscape
and Microsoft Web servers.
Microsoft
Microsoft Corp. (Redmond, Wash.) is one of the most active
players in the Internet security field because of its
pursuit of the twin markets of Intranet deployment and
Internet commerce, both of which require extensive security.
By taking an active role in the security standards debate,
Microsoft hopes to shape policy to its advantage.
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.
Netscape
Netscape Communications Corp. (Mountain View, Calif.)
intends to market its suite of servers as a complete system
for security on the Internet. Login occurs originally
through the browser and then, as in Novell Directory Services,
all certification is unified in this model. Therefore,
once login to the browser occurs, any resources that are
permitted to the user are now accessible.
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.
Allaire
A popular piece of database connector middleware software
is Cold Fusion by Allaire Corp. (Cambridge, Mass.). Cold
Fusion can access any ODBC-standard database for publishing
information to the Web. Cold Fusion does not have any
built-in security foundation.
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.
Consider All the Angles
Making your data secure for broadcast over the Internet
or Intranet is no easy task. The best way to evaluate
your security needs is to weigh the disadvantages of unauthorized
users seeing your data. The more privacy your data requires,
the more security you should have in place. Security is
often far easier to implement than to maintain. Make sure
that the necessary processes in your organization keep
your system current. Security is often neglected or bypassed
by day-to-day users for convenience. By the time loss
of data or security breaks have been discovered, much
damage may have already been done.
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 .
Dan Rahmel has 12 years of professional experience in
design, programming, implementation, consulting, and writing
about the computer industry. He currently works for Coherent
Data, a service provider of secure commerce Web sites.
He is also coauthor of the book Developing Client/Server
Applications with Visual Basic (SAMS Publishing, 1996).
You can email Dan at cvisual@electriciti.com, or check
out Client/Server Central (www.coherentdata.com/cscentral)
for resource information. |
