Database security mechanisms for protecting sensitive information over HTTP

Database Security

Design of an online membership and payment management system for the web using a Microsoft SQL Server database and a front end built in Microsoft Visual Stuido C#.net involves a variety of complex security issues. This paper discusses the goals of security and common security threats. It then describes in detail, Microsft SQL Server security techniques along with a brief overview of Web application security measures that can be taken to ensure adequate security for the membership and payment management application.

The Goals of Security

Database security is the protection of the database against unauthorized access, either intentional or accidental (Phippen). Security countermeasures should combat threats and the outcomes of such threats. Given a security policy's specification of "secure" and "nonsecure" actions, these security mechanisms can prevent the attack, detect the attack, or recover from the attack (Bishop, 2003).

Bishop (2003) explains the differences between prevention, detection and recovery. Prevention seeks to make the attack fail. Typically, prevention involves implementation of mechanisms that users cannot override and that are trusted to be implemented in a correct, unalterable way, so that the attacker cannot defeat the mechanism by changing it. Detection accepts that an attack will occur; the goal is to determine that an attack is underway, or has occurred, and report it. The attack may be monitored, however, to provide data about its nature, severity, and results. Typical detection mechanisms monitor various aspects of the system, looking for actions or information indicating an attack. Recovery has two forms. The first is to stop an attack and to assess and repair any damage caused by that attack. As an example, if the attacker deletes a file, one recovery mechanism would be to restore the file from backup tapes. Moreover, the attacker may return, so recovery involves identification and fixing of the vulnerabilities used by the attacker to enter the system.

3. Sources of Security Threats decade ago database security issues were rarely reported. At that time databases were physically security and housed in central data centers. External access was mediated. Now, however, databases are externally accessible so that customers, suppliers and partners may be directly connected. Unfortunately, along with greater access comes greater potential for security threats.

3.1 Points of. Entry

Web-based applications have numerous possible entry points that present opportunity for unwanted access (Burleson):

Internet access - If hackers can guess the IP address of a server, they can telnet to the server and get a login prompt. At this point, all they need is a user ID and password to gain access to the server.

Port access - All Web applications are configured to listen on a predefined port for incoming connections, and they generally use a listener daemon process to poll for connections.

Server access - A four-tiered Web application (illustrated in Figure A) incorporates a series of Web servers, application servers, and database servers. Each of these servers presents a potential point of entry, and if remote shell access is enabled, a hacker that gets access to a single database may get access to many servers.

Network access - If hackers know the port, IP address, database ID, and password, they can gain direct access to the database.

3.2 Types of Threats

Summarized in Table 1 are sources of security threats as well as the ways each can contribute to concerns.

Common Web Application Security Threats

Sources of Threat

Reasons for Threat

Hardware

Fire/flood/bombs

Power loss/surge

Theft of Equipment

DBMS and application software

Program alteration

Theft of programs

Database

Amendment or copying of data

Data corruption

Communication networks

Wire tapping

Cable breakage

Administrators

Inadequate security

Users

Using another user's access

Unauthorized access

Hacking

Blackmail

Viruses

Operators

Trapdoors

Alterations

Inadequate training

Inadequate security

Source: Phippen, A., Database Security

4. Physical Security

Physical security means that your SQL Server system is running in a controlled-access environment in which only approved personnel have physical access to the system (Huston, 2003). This means that SQL Server should be isolated from Web infrastructures and direct Internet access. If there is an absolute requirement for SQL access across the Internet, it should only be available via a proxy system that enforces strict rules and scrubs out data streams that could compromise or damage the system or the data it contains. Further, all indirect access such as access via web sites and online applications should include appropriate bounds checking and input validation. For example, SQL delimiters must be stripped from input prior to passing them to the database system. Further, values for SQL access should always be contained and managed only on the server side of the application, as client manipulation of any client side values is likely and dangerous.

5. Security Mechanisms to Protect a Database

The goals of securing a database are (Zikopoulos, 2001):

Preventing unauthorized access to classified data by anyone without a business need to know

Preventing unauthorized users from committing mischief through malicious deletion or tampering of data

Monitoring user access of data through auditing techniques

This section describes technologies available in Microsoft SQL Server to meet these objectives such as access controls and authentication, views, rules and constraints, concurrency control, audit tracking, encryption, backup and recovery and techniques to prevent SQL Injection. Database security does not supercede other security technologies, such as network-layer firewalls, network monitoring and SSL-secured communications. But data protection in databases needs to be in place as the core element of a complete enterprise security infrastructure.

5.1 Access Controls and Authentication

Access control prevents unauthorized persons from accessing the system itself to obtain information or make changes. Microsoft SQL Server handles access control by allowing the creation of user accounts and passwords to control the log-in process. Additionally, Microsoft SQL Server supports the use of Windows NT Integrated Security where users are identified to the database by their Windows NT user accounts and are not required to enter an additional user ID and password to access the database (Chapple). This approach offers the benefit of shifting the burden of account management to the network administration staff and it provides the ease of a single sign-on to the end user.

According to Policht (2004, April), Windows authentication is far more secure than SQL Server authentication. This is because Windows credentials are delivered to SQL Server without passing the actual password, while SQL authentication sends the login name and password in unencrypted format, meaning that anyone who can capture network traffic carrying client authentication information can easily retrieve it. Anyone using SQL Server authentication should always encrypt communication between SQL server and its clients with the built-in feature of Multiprotocol Net Library or by implementing SSL.

5.2 Views

Views are an access control method to restrict low-level (also called row-level) access to data. Views allow a database administrator to hide sensitive rows and columns of information that reside in the original table from SQL statements. The administrator can give a user access to information by granting privileges on a view. Because these privileges are only for the view and do not affect the base table, the user's access is confined to the view, which is generated by creating a subset of the data contained in required table. Microsoft SQL Server 2000 has a feature called the View Index that give the database the capability to define an index on a view (Carpenter, 2000). Additionally, SQL Server View Indexes are dynamic in that changes to the data in the base tables are automatically reflected in the indexed view.

5.3 Rules and Constraints

Both rules and constraints implement data integrity for column values in SQL Server (Mullins, 1998). Rules and constraints in SQL Server can be used to:

enforce the range of data values that can be stored in a column (check constraints) enforce the uniqueness of a column or group of columns within a table (unique / primary key constraints) enforce referential integrity (primary key and foreign key constraints).

Rules are free-standing database objects that can be used to enforce data integrity. This is desirable because it promotes reusability. Unlike constraints, rules are "free-standing" database objects; meaning they stand by themselves outside the scope of any other object.

5.4 Concurrency Control

Concurrency control deals with the issues involved with allowing multiple people simultaneous access to shared entities (Ambler, 2004). A collision occurs when two activities, which may or may not be full-fledged transactions, attempt to change entities within a system of record. A database administrator can either devise ways to avoid collisions or detect and then resolve them. Transactions are collections of actions that potentially modify two or more entities. The easiest way for an application to implement transactions is to use the features supplied by SQL Server. Transactions can be started, attempted, then committed or aborted via SQL code. Also, database APIs such as Java Database Connectivity and Open Database Connectivity provide classes that support basic transactional functionality.

Microsoft SQL Server offers both optimistic and pessimistic concurrency control ("Optimistic and pessimistic concurrency").

Optimistic concurrency control works on the assumption that resource conflicts between multiple users are unlikely and, therefore, allows transactions to execute without locking any resources. With optimistic concurrency control, the database checks resources to determine if any conflicts have occurred only when attempting to change data. If a conflict occurs, the application must read the data and attempt the change again. Pessimistic concurrency, on the other hand, control locks resources as they are required, for the duration of a transaction. Unless deadlocks occur, a transaction is assured of successful completion

5.5 Audit Tracking

Although auditing does not prevent system attacks, it is a vital aid in identifying intruders, attacks in progress, and to diagnose attack footprints (Meier, Mackman, Dunner, Vasireddy, Escamilla and Murukan). It is important to enable Windows operating system level auditing and SQL Server login auditing. SQL Server also offers an auditing capability that complies with the U.S. Government C2 certification. C2 level auditing provides substantially more audit information at the expense of increased disk storage requirements.

5.6 Encryption

SQL Server 2005 will support native database encryption (Songini, 2004). Previous versions had relied on third party tools. Encryption is the conversion of data into a form, called a ciphertext, that cannot be easily understood by unauthorized people. Decryption is the process of converting encrypted data back into its original form, so it can be understood. In order to recover the contents of an encrypted signal, the correct decryption key is required. The key is an algorithm that "undoes" the work of the encryption algorithm. Data encryption adds an important layer of protection because any user trying to access the data needs the right password and the encryption key as well (Database Security and Administration, 2001). One advantage of data encryption is that files are unreadable to people who have access to the database, but no databases privileges.

5.7 Backup and Recovery

Backup and recovery is necessary to restore a database quickly and accurately after loss or damage. SQL Server can back up data in one of three ways: a full database backup, a transaction log backup, and a differential backup ("Backup"). The full option backups the entire database including the transaction log while a differential option backups data between full database backups. A sequence of transaction log backups provides for a continuous chain of transaction information to support recovery forward from database, differential, or file backups. Microsoft SQL Server supports password protection for backup media and backup sets. Using password protection helps safeguard backups against unauthorized restoration of databases, unauthorized appends to the media, and unintentional overwriting of the media.

5.8 SQL Injection Prevention Techniques

SQL Injection is caused by malicious alterations of SQL statements from their intended format, by exploiting weaknesses of a client application that is used to create them (Plicht, 2004, October). Most commonly, this takes place in Internet or intranet scenarios that require users to enter data via text boxes presented through a Web-page interface, which, in turn is used to populate a dynamically formed query.

Policht (2004, October) makes several recommendations for preventing SQL Injection. First, administrators should follow the principle of least privileged access, granting to applications only the rights required to operate properly. It is also important to implement the most secure authentication method possible (refer to section 5.2 in this paper). In cases where the number of applications users is low, creating separate SQL Server logins for each one and using these logins to define connection parameters to the target database from the Web application will make SQL Injection more difficult. Validation of a user's input by testing it for invalid or suspicious characters and checking the type of entered data is also necessary. And, replacing the SQL statement with an equivalent stored procedure, and setting the username and password values as its input parameters will render SQL Injection attacks ineffective. Finally, guarding information that might be revealed via error messages resulting from executing malformed SQL statements is another prevention technique.