Database security

Editor's Notes

• #4: For example, a typical telephone directory contains one entry for each subscriber, with columns for name, telephone number, and address. Such a table is called a flat file because it is a single two-dimensional data. In a flat file, all of the data are stored in a single table. For the telephone directory, there might be a number of subscribers with the same name, but the telephone numbers should be unique, so that the telephone number serves as a unique identifier for a row. However, two or more people sharing the same phone number might each be listed in the directory, but with the same telephone number, which is no longer unique. Figure 5.2 here shows how new services and features can be added to the telephone database without reconstructing the main table. In this example, there is a primary table with basic information for each telephone number. The telephone number serves as a primary key. A query language allows the user to request selected items of data from all records that fit a given set of criteria. For example, a telephone company representative could retrieve a subscriber's billing information as well as the status of special services or the latest payment received, all displayed on one screen.
• #5: Commercial and open-source DBMSs typically provide an access control capability for the database. The DBMS operates on the assumption that the computer system has authenticated each user. As an additional line of defense, the computer system may use the overall access control system described in Chapter 4 to determine whether a user may have access to the database as a whole. For users who are authenticated and granted access to the database, a database access control system provides a specific capability that controls access to portions of the database. Commercial and open-source DBMSs provide discretionary or role-based access control. We defer a discussion of mandatory access control considerations to Chapter 13 . Typically, a DBMS can support a range of administrative policies, including the following: • Centralized administration: A small number of privileged users may grant and revoke access rights. • Ownership-based administration: The owner (creator) of a table may grant and revoke access rights to the table. • Decentralized administration: In addition to granting and revoking access rights to a table, the owner of the table may grant and revoke authorization rights to other users, allowing them to grant and revoke access rights to the table. As with any access control system, a database access control system distinguishes different access rights, including create, insert, delete, update, read, and write. Some DBMSs provide considerable control over the granularity of access rights. Access rights can be to the entire database, to individual tables, or to selected rows or columns within a table. Access rights can be determined based on the contents of a table entry. For example, in a personnel database, some users may be limited to seeing salary information only up to a certain maximum value. And a department manager may only be allowed to view salary information for employees in his or her department.
• #6: SQL provides two commands for managing access rights, GRANT and REVOKE. For different versions of SQL, the syntax is slightly different. In general terms, the GRANT command has the following syntax: 1 GRANT { privileges | role } [ON table] TO { user | role | PUBLIC } [IDENTIFIED BY password] [WITH GRANT OPTION] This command can be used to grant one or more access rights or can be used to assign a user to a role. For access rights, the command can optionally specify that it applies only to a specified table. The TO clause specifies the user or role to which the rights are granted. A PUBLIC value indicates that any user has the specified access rights. The optional IDENTIFIED BY clause specifies a password that must be used to revoke the access rights of this GRANT command. The GRANT OPTION indicates that the grantee can grant this access right to other users, with or without the grant option. As a simple example, consider the following statement. GRANT SELECT ON ANY TABLE TO ricflair This statement enables user ricflair to query any table in the database. Different implementations of SQL provide different ranges of access rights. The following is a typical list: • Select: Grantee may read entire database; individual tables; or specific columns in a table. • Insert: Grantee may insert rows in a table; or insert rows with values for specific columns in a table. • Update: Semantics is similar to INSERT. • Delete: Grantee may delete rows from a table. • References: Grantee is allowed to define foreign keys in another table that refer to the specified columns. The REVOKE command has the following syntax: REVOKE { privileges | role } [ON table] FROM { user | role | PUBLIC } Thus, the following statement revokes the access rights of the preceding example: REVOKE SELECT ON ANY TABLE FROM ricflair
• #7: SQL provides two commands for managing access rights, GRANT and REVOKE. For different versions of SQL, the syntax is slightly different. The GRANT command can be used to grant one or more access rights or can be used to assign a user to a role. For access rights, the command can optionally specify that it applies only to a specified table. The TO clause specifies the user or role to which the rights are granted. A PUBLIC value indicates that any user has the specified access rights. The optional IDENTIFIED BY clause specifies a password that must be used to revoke the access rights of this GRANT command. The GRANT OPTION indicates that the grantee can grant this access right to other users, with our without the grant option. Consider the simple example shown, which enables user ricflair to query any table in the database. The REVOKE command has the syntax shown. The example revokes the access rights of the preceding example. Different implementations of SQL provide different ranges of access rights, e.g.: • SELECT: Grantee may read entire database; individual tables; or specific columns in a table. • INSERT: Grantee may insert rows in a table; or insert rows with values for specific columns in a table. • UPDATE: Semantics is similar to INSERT. • DELETE: Grantee may delete rows from a table. • REFERENCES: Grantee is allowed to define foreign keys in another table that refer to the specified columns.
• #8: A role-based access control (RBAC) scheme is a natural fit for database access control. Unlike a file system associated with a single or a few applications, a database system often supports dozens of applications. In such an environment, an individual user may use a variety of applications to perform a variety of tasks, each of which requires its own set of privileges. It would be poor administrative practice to simply grant users all of the access rights they require for all the tasks they perform. RBAC provides a means of easing the administrative burden and improving security. In a discretionary access control environment, we can classify database users in three broad categories: • Application owner: An end user who owns database objects (tables, columns, rows) as part of an application. That is, the database objects are generated by the application or are prepared for use by the application. End user other than application owner: An end user who operates on database objects via a particular application but does not own any of the database objects. • Administrator: User who has administrative responsibility for part or all of the database. We can make some general statements about RBAC concerning these three types of users. An application has associated with it a number of tasks, with each task requiring specific access rights to portions of the database. For each task, one or more roles can be defined that specify the needed access rights. The application owner may assign roles to end users. Administrators are responsible for more sensitive or general roles, including those having to do with managing physical and logical database components, such as data files, users, and security mechanisms. The system needs to be set up to give certain administrators certain privileges. Administrators in turn can assign users to administrative-related roles. A database RBAC facility needs to provide the following capabilities: • Create and delete roles. • Define permissions for a role. • Assign and cancel assignment of users to roles.
• #9: Inference, as it relates to database security, is the process of performing authorized queries and deducing unauthorized information from the legitimate responses received. The inference problem arises when the combination of a number of data items is more sensitive than the individual items, or when a combination of data items can be used to infer data of a higher sensitivity. Figure 5.5here illustrates the process. The attacker may make use of nonsensitive data as well as metadata. Metadata refers to knowledge about correlations or dependencies among data items that can be used to deduce information not otherwise available to a particular user. The information transfer path by which unauthorized data is obtained is referred to as an inference channel. In general terms, two inference techniques can be used to derive additional information: analyzing functional dependencies between attributes within a table or across tables; and merging views with the same constraints.
• #11: An example of inference across tables is shown in Figure 5.6. Figure 5.6a shows a table Employee with five columns. Figure 5.6b shows two views. Users of these views are not authorized to access the relationship between Name and Salary. A user who has access to either or both views cannot infer the relationship by functional dependencies. That is, there is not a functional relationship between Name and Salary such that knowing Name and perhaps other information is sufficient to deduce Salary. However, suppose the two views are created with the access constraint that Name and Salary cannot be access together. A user who knows the structure of the Employee table and who knows that the view tables maintain the same row order as the Employee table is then able to merge the two views to construct the table shown in Figure 5.6c. This violates the access control policy that the relationship of attributes Name and Salary must not be disclosed.
• #12: There are two approaches to dealing with the threat of disclosure by inference. • Inference detection during database design: removes an inference channel by altering the database structure or by changing the access control regime to prevent inference. Examples include removing data dependencies by splitting a table into multiple tables or using more fine-grain access control roles in an RBAC scheme. • Inference detection at query time: eliminate an inference channel violation during a query or series of queries. If inference channel detected, query is denied or altered. For either of the preceding approaches, some inference detection algorithm is needed. This is a difficult problem and the subject of ongoing research. Consider a database containing personnel information, including names addresses, and salaries of employees. Individually, the name, address, and salary information is available to a subordinate role, such as Clerk, but the association of names and salaries is restricted to a superior role, such as Administrator. One solution to this problem is to construct three tables. The Employees Table and the Salaries Table are accessible to the Clerk role, but the Emp-Salary table is only available to the Administrator role. In this structure, the sensitive relationship between employees and salaries is protected from users assigned the Clerk role. Now suppose we add a new attribute, employee start date, which is not sensitive. This could be added to the Salaries table. However, an employee's start data is an easily observable or discoverable attribute of an employee. Thus a user in the Clerk role should be able to infer (or partially infer) the employee's name. This would compromise the relationship between employee and salary. Hence we should add the Start-Date column to the Employees Table instead.
• #13: A statistical database (SDB) is one that provides data of a statistical nature, such as counts and averages. The term statistical database is used in two contexts: • Pure statistical database: This type of database only stores statistical data. An example is a census database. Typically, access control for a pure SDB is straightforward: certain users are authorized to access the entire database. • Ordinary database with statistical access: This type of database contains individual entries; this is the type of database discussed so far in this chapter. The database supports a population of nonstatistical users who are allowed access to selected portions of the database using DAC, RBAC, or MAC. In addition, the database supports a set of statistical users who are only permitted statistical queries. For these latter users, aggregate statistics based on the underlying raw data are generated in response to a user query, or may be pre-calculated and stored as part of the database. We are mainly concerned with this type of SDB. The access control objective for an SDB system is to provide users with the aggregate information without compromising the confidentiality of any individual entity represented in the database. The security problem is one of inference. The database administrator must prevent, or at least detect, the statistical user who attempts to gain individual information through one or a series of statistical queries.
• #14: Statistics are derived from a database by means of a characteristic formula, C, which is a logical formula over the values of attributes. A characteristic formula uses the operators OR, AND, and NOT (+ . ~). A characteristic formula specifies a subset of the records in the database. The example specifies all male students majoring in either CS or EE. For numerical attributes, relational operators may be used. The query set of characteristic formula C, denoted as X(C), is the set of records matching that characteristic. A statistical query is a query that produces a value calculated over a query set. Some simple statistics that can be derived from a query set are count, sum, average, median, max, min. A statistical user of an underlying database of individual records is restricted to obtaining only aggregate, or statistical, data from the database and is prohibited access to individual records. The inference problem in this context is that a user may infer confidential information about individual entities represented in the SDB, Such an inference is called a compromise. In some cases, a sequence of queries may reveal information. In general terms, the inference problem for an SDB can be stated as follows. A characteristic function C defines a subset of records (rows) within the database. A query using C provides statistics on the selected subset. If the subset is small enough, perhaps even a single record, the questioner may be able to infer characteristics of a single individual or a small group. Even for larger subsets, the nature or structure of the data may be such that unauthorized information may be released.
• #15: The example shown here from Table 5.3 is a database containing 13 confidential records of students in a university that has 50 departments. A characteristic formula C specifies a subset of the records in the database. For example C = (GP > 3.7) specifies all students whose grade point average exceeds 3.7. The query set of is the set of records matching some characteristic C. For example, for C = Female CS, X(C) consists of records 1 and 4, the records for Allen and Davis. A statistical query is a query that produces a value calculated over a query set. Examples: count(Female . CS) = 2; sum(Female . CS, SAT) = 1400. The inference problem is that a user may infer confidential information about individual entities represented in the SDB. For example, the statistic sum(EE Female, GP) = 2.5 compromises the database if the user knows that Baker is the only female EE student. In some cases, a sequence of queries may reveal information. For example, suppose a questioner knows that Baker is a female EE student, but does not know if she is the only one. Consider the following sequence of two queries that reveals the sensitive information: count(EE Female) = 1 sum(EE Female, GP) = 2.5
• #16: A statistical query is a query that produces a value calculated over a query set. Table 5.4 lists some simple statistics that can be derived from a query set. Examples: count (Female • CS) 2; sum (Female • CS, SAT) 1400.
• #19: SDB implementers have developed two distinct approaches to protection of an SDB from inference attacks (Figure 5.8). Query restriction: Rejects a query that can lead to a compromise. The answers provided are accurate. Query restriction techniques defend against inference by restricting statistical queries so that they do not reveal user confidential information. Restriction in this context simply means that some queries are denied. The simplest form of query restriction is query size restriction. For a database of size N (number of rows, or records), a query q(C) is permitted only if the number of records that match C satisfies: k <= |X(C)| <= N-k, where k is a fixed integer greater than 1. Thus, the user may not access any query set of less than k records. Note that the upper bound is also needed. The upper bound of N – k guarantees that the user does not have access to statistics on query sets of less than k records. In practice, queries of the form q(All) are allowed, enabling users to easily access statistics calculated on the entire database. Query size restriction counters attacks based on very small query sets. Perturbation: Provides answers to all queries, but the answers are approximate, due to the addition of noise to the statistics generated from the original data. This can be done in one of two ways: the data in the SDB can be modified (perturbed) so as to produce statistics that cannot be used to infer values for individual records( data perturbation). Alternatively, when a statistical query is made, the system can generate statistics that are modified from those that the original database would provide, again thwarting attempts to gain knowledge of individual records (output perturbation). Regardless of the specific perturbation technique, the designer must attempt to produce statistics that accurately reflect the underlying database.
• #20: The database is typically the most valuable information resource for any organization and is therefore protected by multiple layers of security, including firewalls, authentication mechanisms, general access control systems, and database access control systems, and for particularly sensitive data database encryption. Encryption can be applied to the entire database, at the record level (encrypt selected records), at the attribute level (encrypt selected columns), or at the level of the individual field. One approach is to encrypt the entire database and not provide the encryption/ decryption keys to the service provider. This solution, by itself is inflexible. The user has little ability to access individual data items based on searches or indexing on key parameters, but rather would have to download entire tables from the database, decrypt the tables, and work with the results. To provide more flexibility, it must be possible to work with the database in its encrypted form. The simplest possible arrangement is that each individual item in the database is encrypted separately, all using the same encryption key. The encrypted database is stored at the server, but the server does not have the key, so that the data is secure at the server. The client system does have a copy of the encryption key, so can encrypt fields to check in the query and decrypt returned results. This method is straightforward but lacks flexibility. The set of encrypted values do not preserve the ordering of values in the original attribute. To provide more flexibility, each record (row) of a table in the database is encrypted as a block. To assist in data retrieval, attribute indexes are associated with each table. For some or all of the attributes an index value is created. This arrangement provides for more efficient data retrieval, but does leak rough ordering info to any attacker.
• #24: The SQL injection (SQLi) attack is one of the most prevalent and dangerous network-based security threats. Consider the following reports: 1. The July 2013 Imperva Web Application Attack Report [IMPE13] surveyed a cross-section of Web application servers in industry and monitored eight different types of common attacks. The report found that SQLi attacks ranked first or second in total number of attack incidents, the number of attack requests per attack incident, and average number of days per month that an application experienced at least one attack incident. Imperva observed a single Web site that received 94,057 SQL injection attack requests in one day. 2. The Open Web Application Security Project’s 2013 report [OWAS13] on the ten most critical Web application security risks listed injection attacks, especially SQLi attacks, as the top risk. This ranking is unchanged from its 2010 report. 3. The Veracode 2013 State of Software Security Report [VERA13] found that percentage of applications affected by SQLi attacks is around 32% and that SQLi attacks account for 26% of all reported breaches. Veracode also considers this among the most dangerous threats, reporting that three of the biggest SQL injection attacks in 2012 resulted in millions of email addresses, user names, and passwords being exposed and damaged the respective brands. 4. The Trustwave 2013 Global Security Report [TRUS13] lists SQLi attacks as one of the top two intrusion techniques. The report notes that poor coding practices have allowed the SQL injection attack vector to remain on the threat landscape for more than 15 years, but that proper programming and security measures can prevent these attacks. In general terms, an SQLi attack is designed to exploit the nature of Web application pages. In contrast to the static Web pages of years gone by, most current Web sites have dynamic components and content. Many such pages ask for information, such as location, personal identity information, and credit card information. This dynamic content is usually transferred to and from back-end databases that contain volumes of information—anything from cardholder data to which type of running shoes is most purchased. An application server Web page will make SQL queries to databases to send and receive information critical to making a positive user experience. In such an environment, an SQLi attack is designed to send malicious SQL commands to the database server. The most common attack goal is bulk extraction of data. Attackers can dump database tables with hundreds of thousands of customer records. Depending on the environment, SQL injection can also be exploited to modify or delete data, execute arbitrary operating system commands, or launch denial-of-service (DoS) attacks.
• #25: SQLi is an attack that exploits a security vulnerability occurring in the database layer of an application (such as queries). Using SQL injection, the attacker can extract or manipulate the web application’s data. The attack is viable when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed, and thereby unexpectedly executed. Figure 5.5, from [ACUN13], is a typical example of an SQLi attack. The steps involved are as follows: 1. Hacker finds a vulnerability in a custom Web application and injects an SQL command to a database by sending the command to the Web server. The command is injected into traffic that will be accepted by the firewall. 2. The Web server receives the malicious code and sends it to the Web application server. 3. The Web application server receives the malicious code from the Web server and sends it to the database server. 4. The database server executes the malicious code on the database. The database returns data from credit cards table. 5. The Web application server dynamically generates a page with data including credit card details from the database. 6. The Web server sends the credit card details to the hacker.
• #26: The SQLi attack typically works by prematurely terminating a text string and appending a new command. Because the inserted command may have additional strings appended to it before it is executed, the attacker terminates the injected string with a comment mark “--”. Subsequent text is ignored at execution time.
• #27: We can characterize SQLi attacks in terms of the avenue of attack and the type of attack [CHAN11, HALF06]. The main avenues of attack are as follows: • User input: In this case, attackers inject SQL commands by providing suitably crafted user input. A Web application can read user input in several ways based on the environment in which the application is deployed. In most SQLi attacks that target Web applications, user input typically comes from form submissions that are sent to the Web application via HTTP GET or POST requests. Web applications are generally able to access the user input contained in these requests as they would access any other variable in the environment. • Server variables: Server variables are a collection of variables that contain HTTP headers, network protocol headers, and environmental variables. Web applications use these server variables in a variety of ways, such as logging usage statistics and identifying browsing trends. If these variables are logged to a database without sanitization, this could create an SQL injection vulnerability. Because attackers can forge the values that are placed in HTTP and network headers, they can exploit this vulnerability by placing data directly into the headers. When the query to log the server variable is issued to the database, the attack in the forged header is then triggered. • Second-order injection: Second-order injection occurs when incomplete prevention mechanisms against SQL injection attacks are in place. In second-order injection, a malicious user could rely on data already present in the system or database to trigger an SQL injection attack, so when the attack occurs, the input that modifies the query to cause an attack does not come from the user, but from within the system itself. • Cookies: When a client returns to a Web application, cookies can be used to restore the client’s state information. Because the client has control over cookies, an attacker could alter cookies such that when the application server builds an SQL query based on the cookie’s content, the structure and function of the query is modified. • Physical user input: SQL injection is possible by supplying user input that constructs an attack outside the realm of web requests. This user-input could take the form of conventional barcodes, RFID tags, or even paper forms which are scanned using optical character recognition and passed to a database management system.
• #28: Because SQLi attacks are so prevalent, damaging, and varied both by attack avenue and type, a single countermeasure is insufficient. Rather an integrated set of techniques is necessary. In this section, we provide a brief overview of the types of countermeasures that are in use or being researched, using the classification in [SHAR13]. These countermeasures can be classified into three types: defensive coding, detection, and run-time prevention. Many SQLi attacks succeed because developers have used insecure coding practices. Thus, defensive coding is an effective way to dramatically reduce the threat from SQLi. Examples of defensive coding include the following: • Manual defensive coding practices: A common vulnerability exploited by SQLi attacks is insufficient input validation. The straightforward solution for eliminating these vulnerabilities is to apply suitable defensive coding practices. An example is input type checking, to check that inputs that are supposed to be numeric contain no characters other than digits. This type of technique can avoid attacks based on forcing errors in the database management system. Another type of coding practice is one that performs pattern matching to try to distinguish normal input from abnormal input. • Parameterized query insertion: This approach attempts to prevent SQLi by allowing the application developer to more accurately specify the structure of an SQL query, and pass the value parameters to it separately such that any unsanitary user input is not allowed to modify the query structure. • SQL DOM: SQL DOM is a set of classes that enables automated data type validation and escaping [MCCL05]. This approach uses encapsulation of database queries to provide a safe and reliable way to access databases. This changes the query-building process from an unregulated one that uses string concatenation to a systematic one that uses a type-checked API. Within the API, developers are able to systematically apply coding best practices such as input filtering and rigorous type checking of user input. A variety of detection methods have been developed, including the following: • Signature based: This technique attempts to match specific attack patterns. Such an approach must be constantly updated and may not work against self-modifying attacks. • Anomaly based: This approach attempts to define normal behavior and then detect behavior patterns outside the normal range. A number of approaches have been used. In general terms, there is a training phase, in which the system learns the range of normal behavior, followed by the actual detection phase. • Code analysis: Code analysis techniques involve the use of a test suite to detect SQLi vulnerabilities. The test suite is designed to generate a wide range of SQLi attacks and assess the response of the system. Finally, a number of run-time prevention techniques have been developed as SQLi countermeasures. These techniques check queries at runtime to see if they conform to a model of expected queries. Various automated tools are available for this purpose [CHAN12, SHAR13].