Download database security - S2010

DATABASE SECURITY
DATABASE SECURITY ................................................................................................... 3
Authentication vs Authorization ..................................................................................... 3
Authentication ................................................................................................................. 3
Authorization .................................................................................................................. 4
Role-based Security .................................................................................................... 4
Principals..................................................................................................................... 6
Securable ..................................................................................................................... 6
Permissions ................................................................................................................. 6
Using Views as Security Mechanisms ........................................................................ 7
SQL Injection .................................................................................................................. 8
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 user’s account name or group
membership.

SQL Server Authentication:
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.
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:
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
Can
issue
DBCC,
CHECKPOINT,
and
BACKUP
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.