DATABASE SECURITY

DATABASE SECURITY....................................................................................................3 Authentication vs Authorization......................................................................................3 Authentication..................................................................................................................3 Authorization...................................................................................................................4 Role-based Security.....................................................................................................4 Principals .....................................................................................................................5 Securable......................................................................................................................6 Permissions..................................................................................................................6 Using Views as Security Mechanisms.........................................................................7 SQL Injection...................................................................................................................7

DATABASE SECURITY
Security is a major concern for the modern age systems, network, and database administrators. It is natural for an administrator to worry about hackers and external attacks while implementing security. But there is more to it. It is essential to first I implement security within the organization, to make sure the right people have access to the right data. Without these security measures in place, you might find someone destroying your valuable data, or selling your company's secrets to your competitors, or someone invading the privacy of others. Primarily, a security plan must identify which users in the organization can see which data and perform which activities in the database.

Authentication vs Authorization
Authentication is any process by which you verify that someone is who they claim they are. This usually involves a username and a password, but can include any other method of demonstrating identity, such as a smart card, retina scan, voice recognition, or fingerprints. Authentication is equivalent to showing your drivers license at the ticket counter at the airport. Authentication systems provide answers to the questions:

Who is the user? Is the user really who he/she represents himself to be?

Authorization, by contrast, is the mechanism by which a system determines what level of access a particular authenticated user should have to secure resources controlled by the system. For example, a database management system might be designed so as to provide certain specified individuals with the ability to retrieve information from a database but not the ability to change data stored in the database, while giving other individuals the ability to change data. Authorization systems provide answers to the questions:

Is user X authorized to access resource R? Is user X authorized to perform operation P? Is user X authorized to perform operation P on resource R?

Authentication and authorization are somewhat tightly-coupled mechanisms authorization systems depend on secure authentication systems to ensure that users are who they claim to be and thus prevent unauthorized users from gaining access to secured resources.

Authentication
SQL Server supports two authentication modes: Windows Authentication Mode: With Windows authentication, you do not have to specify a login name and password to connect to SQL Server.

Instead, your access to SQL Server is controlled by your Windows NT/2000 account (or the group to which your account belongs to), that you used to login to the Windows operating system on the client computer or workstation. A DBA must specify to SQL Server all the Microsoft Windows NT/2000 accounts or groups that can connect to SQL Server.

This authentication mode is used by default because of its inherent better security. When it is used, Windows NT is responsible for managing users connections to the SQL Server through the users account name or group membership.

When a user connects with a specified login name and password, SQL Server performs the authentication itself by checking to see if a SQL Server login account has been set up and if the specified password matches the one previously recorded. If SQL Server does not have a login account set, authentication fails and the user receives an error message.
SQL Server Authentication:

Windows authentication is the recommended security mode, as it is more secure and you don't have to send login names and passwords over the network. You should avoid mixed mode, unless you have a non-Windows NT/2000 environment, or when your SQL Server is installed on Windows 95/98, or for backward compatibility with your existing applications.

Authorization
Role-based Security
Role-based security is a form of user-level security where a server doesn't focus on the individual user's identity but rather on a logical role he is in.
A role is nothing but a group to which individual logins and users can be added, so that the permissions can be applied to a group, instead of applying the permissions to all the individual logins and users. There are three types of roles in SQL Server 7.0 and 2000: Fixed server roles Fixed database roles Application roles

Fixed Server Roles Fixed server roles are server-wide roles. Logins can be added to these roles to gain the associated administrative permissions of the role. Fixed server roles cannot be altered and new server roles cannot be created. Here are the fixed server roles and their associated permissions in SQL Server 2000: Fixed Server Role Descriptions

sysadmin: Can perform any activity in SQL Server serveradmin: Can set server-wide configuration options, shut down the server setupadmin: Can manage linked servers and startup procedures securityadmin: Can manage logins and CREATE DATABASE permissions, also read error logs and change passwords processadmin: Can manage processes running in SQL Server dbcreator: Can create, alter, and drop databases diskadmin: Can manage disk files bulkadmin: Can execute BULK INSERT statements

Fixed Database Roles Each database has a set of fixed database roles, to which database users can be added. These fixed database roles are unique within the database. While the permissions of fixed database roles cannot be altered, new database roles can be created. Here are the fixed database roles and their associated permissions in SQL Server 2000:

Fixed Database Role Description db_owner: Has all permissions in the database db_accessadmin: Can add or remove user IDs db_securityadmin: Can manage all permissions, object ownerships, roles and role memberships db_ddladmin: Can issue ALL DDL, but cannot issue GRANT, REVOKE, or DENY statements db_backupoperator: Can issue DBCC, CHECKPOINT, and BACKUP statements db_datareader: Can select all data from any user table in the database db_datawriter: Can modify any data in any user table in the database db_denydatareader: Cannot select any data from any user table in the database db_denydatawriter: Cannot modify any data in any user table in the database

Principals
These are objects (for example a user login, a role, or an application) that may be granted permission to access particular database objects. SQL Server divides principals into three classes: Windows principals: These represent authenticated using Windows security. Windows user accounts or groups,

SQL Server principals: These are server-level logins or groups that are authenticated using SQL Server security.

Database principals: These include database users, groups, and roles, as well as application Roles.

Securable
Securable are objects (a table or view, for example) to which access can be controlled. These are the resources to which the DBMS authorization system regulates access. Some securable can be contained within others, creating nested hierarchies called "scopes" that can themselves be secured. The securable scopes are server, database, and schema. Here are few examples: Server level securable Login Database Database level securable User Role Schema Schema level securable Tables Views Constraints Type Procedures

Permissions
These are individual rights, granted (or denied) to a principal, to access a securable object. The following T-SQL commands are used to manage permissions at the user and role level. GRANT: Grants the specific permission (SELECT, DELETE etc.) to the specified user or role in the current database REVOKE: Removes a previously granted or denied permission from a user or role in the current database DENY: Denies a specific permission to the specified user or role in the current database

Using the above commands, permissions can be granted, denied, or revoked to users and roles on all database objects.

There is no way to manage permissions at the row level. That is, in a given table, you can't grant SELECT permission on a specific row to User1 and deny SELECT permission on another row to User2. This kind of security can be implemented by creating user specific views and granting SELECT permission on these views to users.

Using Views as Security Mechanisms

Views can serve as security mechanisms by restricting the data available to users. Some data can be accessible to users for query and modification, while the rest of the table or database is invisible and inaccessible. Permission to access the subset of data in a view must be granted, denied, or revoked, regardless of the set of permissions in force on the underlying table(s). For example, the salary column in a table contains confidential employee information, but the rest of the columns contain information that should be available to all users. You can define a view that includes all of the columns in the table with the exception of the sensitive salary column. By defining different views and granting permissions selectively on them, users, groups, or roles can be restricted to different subsets of data. For example: Access can be restricted to a subset of the rows of a base table. For example, define a view that contains only rows for business and psychology books and keep information about other types of books hidden from users. Access can be restricted to a subset of the columns of a base table. For example, define a view that contains all the rows of the titles table but omits the royalty and advance columns because this information is sensitive. Access can be restricted to a row-and-column subset of a base table. Access can be restricted to the rows that qualify for a join of more than one base table. For example, define a view that joins the titles, authors, and titleauthor tables to display the names of authors and books they have written. This view hides personal data about the authors, and financial information about the books. Access can be restricted to a statistical summary of data in a base table. For example, define a view that contains only the average price of each type of book. Access can be restricted to a subset of another view or of some combination of views and base tables.

SQL Injection
SQL injection is a technique whereby an intruder enters data that causes your application to execute SQL statements you did not intend it to. SQL injection is possible as soon there is dynamic SQL which is handled carelessly, be that SQL statements sent from the client or dynamic SQL generated in T-SQL stored procedures. SQL injection may be possible if input is not filtered for escape characters and is then passed into a SQL statement. This result in the potential manipulation of the statements performed on the database by the end user of the application.

The following line of code illustrates this vulnerability: statement := "SELECT * FROM users WHERE name = '" + userName + "';" This SQL code is designed to pull up the records of a specified username from its table of users, however, if the "userName" variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended. For example, setting the "userName" variable as a' or 't'='t renders this SQL statement by the parent language: SELECT * FROM users WHERE name = 'a' OR 't'='t'; If this code were to be used in an authentication procedure then this example could be used to force the selection of a valid username because the evaluation of 't'='t' is always true. On some SQL servers such as MS SQL Server any valid SQL command may be injected via this method, including the execution of multiple statements. The following value of "userName" in the statement below would cause the deletion of the "users" table as well as the selection of all data from the "data" table (in essence revealing the information of every user): a';DROP TABLE users; SELECT * FROM data WHERE name LIKE '% This input renders the final SQL statement as follows: SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%';

Other SQL implementations won't execute multiple commands in the same SQL query as a security measure. This prevents crackers from injecting entirely separate queries, but doesn't stop them from modifying queries.