UNIT V DATABASE SECURITY 9

Database Security: Security issues -SQL Injection –SQLi Attack Avenues

and Types- DBMS Access control based on privileges – Role Based access
control –Cascading authorization–Statistical Database security – Flow
control – Encryption and Public Key infrastructures – Challenges.
TEXT BOOKS:

1. Alfred Basta,Melisaa Zgola,Dana Bullaboy,Thomas L WhitLock Sr,

“Database Security”,Course Technology,Cenage Learning 2012.

1.Database Security : Security issues

Database security refers to the measures and protocols used to protect databases from
unauthorized access, misuse, corruption, or theft. Securing a database is critical because
databases often contain sensitive information, including personal data, financial information,
trade secrets, and more. Below are some of the major database security issues:

1. Unauthorized Access

 Description: Unauthorized access happens when individuals who do not have

permission are able to view, edit, or manipulate database content.
 Risks: This can lead to data theft, loss of privacy, data manipulation, or leakage of
sensitive information.
 Prevention: Implement strong authentication methods (e.g., multi-factor
authentication), role-based access control (RBAC), and least privilege access.

2. SQL Injection

 Description: SQL injection is a common attack where malicious SQL code is inserted
into queries via input fields. Attackers can manipulate SQL commands to retrieve or
modify sensitive data.
 Risks: SQL injection can result in data breaches, data deletion, or even complete
database control.
 Prevention: Input validation, parameterized queries, and the use of stored procedures
can prevent SQL injections.

3. Weak Authentication and Password Management

 Description: If users use weak passwords, or if the database has inadequate

authentication mechanisms, attackers can easily gain access.
 Risks: Attackers can impersonate legitimate users or escalate privileges to perform
harmful actions.
 Prevention: Enforce strong password policies, regularly update passwords, and use
encryption for password storage.

4. Unpatched Software Vulnerabilities

  Description: Databases, like all software, may have vulnerabilities. If these are not
patched in time, attackers can exploit them to gain unauthorized access.
 Risks: Exploiting software bugs can result in full database compromise, data leakage,
or system crashes.
 Prevention: Regularly apply patches and updates to the database management system
(DBMS).

5. Insider Threats

 Description: Insider threats refer to employees, contractors, or partners who misuse

their legitimate access to the database.
 Risks: Insiders can steal or modify data for personal gain, corporate espionage, or
simply by accident.
 Prevention: Use role-based access control (RBAC), monitor user activities, and
implement data loss prevention (DLP) solutions.

6. Data Encryption Issues

 Description: If data is not encrypted at rest or in transit, attackers can intercept or

access it easily.
 Risks: Sensitive information, such as credit card numbers or personal data, can be
stolen during transmission or from the database.
 Prevention: Use encryption for data at rest (AES encryption, for example) and during
transmission (SSL/TLS).

7. Backup Data Vulnerabilities

 Description: If backups are not adequately protected, they may become a target for
attackers.
 Risks: Unencrypted or poorly secured backups can lead to data theft, especially if
they are stored in insecure locations.
 Prevention: Encrypt backups and store them securely in a location with access
controls.

8. Denial of Service (DoS) Attacks

 Description: A DoS attack floods the database or server with an overwhelming

amount of requests, causing it to crash or become unavailable.
 Risks: This can lead to service disruptions, data inaccessibility, and loss of revenue or
productivity.
 Prevention: Use rate limiting, firewall rules, and traffic monitoring to detect and
mitigate DoS attacks.

9. Misconfiguration of Database Security Settings

 Description: Misconfigurations, such as leaving default settings (e.g., default admin

passwords or open ports), can expose the database to risks.
 Risks: Attackers can take advantage of these misconfigurations to access sensitive
data or disrupt services.
  Prevention: Regularly audit database configurations and follow best security
practices to harden the database environment.

10. Poor Auditing and Monitoring

 Description: Without proper monitoring and auditing, database breaches may go

unnoticed for a long time, increasing the damage caused by attackers.
 Risks: Failure to detect an attack early can lead to prolonged data theft, tampering, or
disruptions.
 Prevention: Implement logging, auditing, and continuous monitoring
tools to detect suspicious activity in real time.

11. Inadequate Physical Security

 Description: Physical access to database servers can be a risk if data centers or server
rooms are not properly secured.
 Risks: If someone gains physical access, they can steal hard drives or tamper with the
system directly.
 Prevention: Use physical security measures such as locked server rooms, access
control, surveillance, and biometric security.

12. Data Leakage through APIs

 Description: Modern databases often interact with other systems through APIs
(Application Programming Interfaces). Poorly secured APIs can be exploited to gain
unauthorized access to data.
 Risks: Data leakage via APIs can expose sensitive information, especially if APIs are
not secured or monitored.
 Prevention: Secure APIs using strong authentication, encryption, and access controls.

2. DBMS Access Control

 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. 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. 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.
SQL Based Access Definition

 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: (The following syntax definition
conventions are used. Elements separated by a vertical line are alternatives. A list
of alternatives is grouped in curly brackets. Square brackets enclose optional
elements. That is, the elements inside the square brackets may or may not be
present.)
 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
icflair

3. SQL Injection (SQLi) is a type of attack in which an attacker manipulates a database

query by injecting malicious SQL code through an application's input fields. This type of
vulnerability arises when user inputs are not properly sanitized before being included in SQL
statements. SQL injection can lead to unauthorized access, data theft, or even full control
over the database.

Types of SQL Injection Methods

Here are some common types of SQL injection attacks, along with an example:

1. Classic SQL Injection (In-Band SQL Injection)

This is the most common type of SQL injection, where the attacker retrieves data from the
database by manipulating the SQL query directly via an input field.

Example Scenario: Consider a login page where the user inputs a username and password.
The query may look like this:

SELECT * FROM users WHERE username = 'admin' AND password = 'password123';

If the application does not properly sanitize the input, an attacker could input the following:

 Username: admin' --
 Password: (leave blank)
The query becomes:

ELECT * FROM users WHERE username = 'admin' --' AND password = '';

The -- is an SQL comment symbol, so the part after it is ignored. This effectively turns the
query into:

SELECT * FROM users WHERE username = 'admin';

Since there's no password check anymore, the attacker can log in as the "admin" user.

2. Blind SQL Injection

In blind SQL injection, attackers cannot see the results of the queries directly. Instead, they
infer information based on true/false conditions. This is often done using time delays or error
messages.

Example Scenario: Suppose the application checks if a user ID exists with the following
query:

SELECT * FROM users WHERE id = 1;

An attacker may inject a query like this:

SELECT * FROM users WHERE id = 1 AND SLEEP(5);

If the database server takes 5 seconds to respond, the attacker knows that the injection was
successful. They can use this technique to retrieve data bit by bit by manipulating the query
to check specific conditions.

3. Union-Based SQL Injection

In this method, the attacker uses the UNION SQL operator to combine the results of a
legitimate query with data selected by the attacker. This can allow the attacker to retrieve
information from other tables in the database.

Example Scenario: A vulnerable query might look like this:

SELECT name, email FROM users WHERE id = 1;

An attacker could inject:

1 UNION SELECT username, password FROM admin_users;

The new query becomes:

SELECT name, email FROM users WHERE id = 1 UNION SELECT username, password
FROM admin_users;

This would combine the result of the first query with the second query, potentially exposing
sensitive data like administrator usernames and passwords.
4. Error-Based SQL Injection

In this type of SQL injection, the attacker deliberately causes the database to return error
messages that contain useful information about the database structure. These error messages
can be used to craft more sophisticated attacks.

Example Scenario: An attacker may inject:

sql
Copy code
1' AND 1=CONVERT(int, (SELECT @@version))--

If the database returns an error containing the database version (due to the @@version query),
the attacker can gather information about the system and use it to plan further attacks.

5. Boolean-Based Blind SQL Injection

This form of blind SQL injection uses conditional responses to determine whether certain
statements are true or false. Based on how the application behaves (whether an error is
returned, whether a page loads correctly, etc.), the attacker can infer information.

Example Scenario: An attacker could inject:

1' AND 1=1 --

If this returns the normal result (indicating true), the attacker knows the injection was
successful. Then, they might try:

1' AND 1=0 --

If this does not return any results (indicating false), the attacker can confirm that the query
is being processed, and from there, start extracting data by asking true/false questions.

6. Time-Based Blind SQL Injection

In time-based blind SQL injection, the attacker uses SQL functions that cause time delays to
infer whether a query condition is true or false, even if no data is returned.

Example Scenario: The attacker may inject:

1' AND IF(1=1, SLEEP(5), 0)--

If the application takes 5 seconds to respond, the attacker knows that the condition 1=1
(which is true) caused the delay, confirming that SQL injection is possible. By changing the
condition (e.g., 1=0), they can determine whether their injected queries are being processed.
4.(i) Role-Based Access Control (RBAC)

It is a method of regulating access to a system or its resources (like databases) based on the roles
assigned to individual users. In the context of database security, RBAC ensures that users can only
perform actions (e.g., read, write, update, delete) that are necessary for their roles, limiting the risk
of unauthorized access or data breaches.

Key Concepts of RBAC

1. Role: A role is a collection of permissions that define what actions a user can
perform. Roles are usually defined based on job functions (e.g., "admin," "developer,"
"auditor").
2. Permissions: These are the rights that define what actions (such as SELECT,
INSERT, DELETE) can be performed on database objects like tables, views, or stored
procedures.
3. User: A user is an individual or system entity that interacts with the database. Users
are assigned roles that determine their access level.
4. Role Assignment: Users are assigned to one or more roles, and each role has a set of
permissions that define what the user can do.

Benefits of RBAC in Database Security

 Principle of Least Privilege: Users are granted only the permissions necessary for their role,
reducing the potential damage from compromised accounts.
 Simplified Access Management: Administrators manage permissions by role instead of
individual users, making it easier to manage access control for many users.
 Security: Reduces the chance of unauthorized access to sensitive data by enforcing clear
access control policies.

RBAC Example in Database Security

Scenario:

Consider a company with an online retail platform. They use a database to store customer
data, order information, and product inventory. Different employees in the company need
different levels of access to the database based on their job roles.

The company has three types of users:

1. Admin
2. Sales Representative
3. Data Analyst

Step-by-Step Example:

1. Define Roles and Permissions

o Admin Role: Full access to all database operations (CRUD - Create, Read, Update,
Delete) across all tables.
 Permissions: SELECT, INSERT, UPDATE, DELETE on all tables.
 o Sales Representative Role: Can view customer and order details but cannot modify
them.
 Permissions: SELECT on customers and orders tables.
o Data Analyst Role: Can only access anonymized sales data but cannot view or
modify customer information.
 Permissions: SELECT on sales_summary_view.

2. Create the Roles in SQL (Example for a PostgreSQL database):

sql
Copy code
-- Create roles for each user type
CREATE ROLE admin_role;
CREATE ROLE sales_rep_role;
CREATE ROLE data_analyst_role;

-- Define permissions for each role

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public
TO admin_role;
GRANT SELECT ON customers, orders TO sales_rep_role;
GRANT SELECT ON sales_summary_view TO data_analyst_role;

3. Assign Users to Roles Users are assigned roles based on their job responsibilities.

sql
Copy code
-- Create users and assign roles
CREATE USER alice WITH PASSWORD 'password123';
CREATE USER bob WITH PASSWORD 'password123';
CREATE USER charlie WITH PASSWORD 'password123';

-- Assign roles to users

GRANT admin_role TO alice; -- Alice is an Admin
GRANT sales_rep_role TO bob; -- Bob is a Sales Representative
GRANT data_analyst_role TO charlie; -- Charlie is a Data Analyst

4. User Access Example

o Alice (Admin): Alice has full access to the database. She can view, add,
update, or delete records in any table.

sql
Copy code
SELECT * FROM customers; -- Alice can execute this
INSERT INTO products (name, price) VALUES ('New Product',
99.99); -- Alice can also add data

o Bob (Sales Representative): Bob can only view customer and order details,
but he cannot modify the data or access other tables like products.

sql
Copy code
SELECT * FROM customers; -- Bob can execute this
DELETE FROM customers WHERE id = 1; -- Bob cannot execute this
(no DELETE permission)
 o Charlie (Data Analyst): Charlie can view summarized sales data, but he
cannot access detailed customer or order information.

sql
Copy code
SELECT * FROM sales_summary_view; -- Charlie can execute this
SELECT * FROM customers; -- Charlie cannot execute this (no
SELECT permission on customers)

Access Control Example Breakdown:

 Alice (Admin) has all permissions (SELECT, INSERT, UPDATE, DELETE) and can perform any
action across the database.
 Bob (Sales Rep) is restricted to viewing customer and order data but cannot modify it.
 Charlie (Data Analyst) can only view anonymized sales summary data and has no access to
sensitive customer information.

(ii)Cascading Authorizations
The grant option enables an access right to cascade through a number of users.We
consider a specific access right and illustrate the cascade phenomenon in Figure 5.5. The
figure indicates that Ann grants the access right to Bob at time t = 10 and to Chris at
time t = 20. Assume that the grant option is always used. Thus, Bob is able to grant the
access right to David at t = 30. Chris redundantly grants the access right to David at t =
50. Meanwhile, David grants the right to Ellen, who in turn grants it to Jim; and
subsequently David grants the right to Frank.
Just as the granting of privileges cascades from one user to another using the grant
option, the revocation of privileges also cascaded. Thus, if Ann revokes the access right
to Bob and Chris, then the access right is also revoked to David, Ellen, Jim, and Frank.
A complication arises when a user receives the same access right multiple times, as
happens in the case of David. Suppose that Bob revokes the privilege from David. David
still has the access right because it was granted by Chris at t = 50. However, David
granted the access right to Ellen after receiving the right, with grant option, from Bob
but prior to receiving it from Chris. Most implementations dictate that in this
circumstance, the access right to Ellen and therefore Jim is revoked when Bob revokes
the access right to David. This is because at t = 40, when David granted the access right
to Ellen, David only had the grant option to do this from Bob. When Bob revokes the
right, this causes all subsequent cascaded grants that are traceable solely to Bob via
David to be revoked. Because David granted the access right to Frank after David was
granted the access right with grant option.
from Chris, the access right to Frank remains. These effects are shown in the lower
portion of Figure 5.6.

To generalize, the convention followed by most implementations is as follows.

When user A revokes an access right, any cascaded access right is also revoked,
unless that access right would exist even if the original grant from A had never
occurred.