Chapter 6 - Database Security
Post on 04-Jan-2016
66 Views
Preview:
DESCRIPTION
Transcript
04/20/23Prof. Ehud Gudes Security
Ch 6 1
Chapter 6 - Database Security
Stallings Chp. 5
04/20/23Prof. Ehud Gudes Security
Ch 6 2
Levels of a Database System
END USER
EXTERNAL VIEW
EXTERNAL VIEW
…
CONCEPTUAL SCHEMA
INTERNAL SCHEMA
STORED DATABASE
EXTERNAL LEVEL
External / conceptual mapping
CONCEPTUALLEVEL
Conceptual / internal mapping
INTERNALLEVEL
04/20/23Prof. Ehud Gudes Security
Ch 6 3
A Typical Architecture of a DBMS
A typical DBMS Architecture
04/20/23Prof. Ehud Gudes Security
Ch 6 5
Introduction to DB Security
Secrecy: Users should not be able to see things they are not supposed to.
e.g., a student cannot see other student’s grades.
Integrity: Users should not be able to modify things they are not supposed to.
e.g., only instructors can assign grades.
Also, the DBMS should protect the database from non-malicious integrity errors, i.e Concurrency & Recovery issues
Availability: users should be able to see and modify things they are allowed to.
04/20/23Prof. Ehud Gudes Security
Ch 6 6
Integrity Problems in Databases
Checks on values – single record checks, before and after update checks, etc.
Various integrity constraints – primary keys, unique checks, foreign keys, etc.
General integrity constraints – Constraints, Asserts, Triggers.
Consistency problems as a result of concurrent execution of transactions – CC protocols such as Two-Phase Locking
Integrity problems as results of system failure – Log and Recovery
Prof. Ehud Gudes Security Ch 6
Security - Policies and Mechanism - Reminder
Policies – general guidelines on authorization in the system, examples:
Students can see their gradesOnly instructors can change grades
Mechanisms – techniques to enforce the policies
Access controlEncryption
Prof. Ehud Gudes Security Ch 6
Categories of Security Policies - Reminder
Mandatory vs. Discretionary (Need to Know).Ownership vs. AdministrationCentralized vs. DistributedClose vs. OpenName, Content or Context dependent Individual, Group or Role based Information Flow Control based
Prof. Ehud Gudes Security Ch 6
DAC - The Access Matrix Model
Subjects - users, groups, applications, transactionsObjects - Files, programs, databases, relations, URLs Access-types - Read, write, create, copy, delete, execute, killAuthorization commands - enter, remove, transferAuthorizers - Owners, users, administrators
04/20/23Prof. Ehud Gudes Security
Ch 6 10
The Access Matrix Model
OBJECTS
SUBJECTS
SubjectsFilesDevices
S1S2F1F2D1D2
S1CallReadWrite
Seek
S2SendReadRewind
S3KillDelete
Compatibility Lists
Access Lists
04/20/23Prof. Ehud Gudes Security
Ch 6 11
Objective of the model: trying to keep secrets and avoid illegal flow
Both subjects and objects are assigned security levels:Public, Confidential, Secret, Top Secretdominance relationship between security levels: ‚ ‘
• Simple Security Property: Successful read access: Clearance (S) Class (O)
• *-Property: Successful write access: Class (O) Clearance (S)
Mandatory Policy - Bell and LaPadula Model
Prof. Ehud Gudes Security Ch 6
DBMS Security Policies
Usually DAC, sometimes Mandatory (BLP)Ownership, Usually (SQL) DistributedCloseName, Content dependent (using Views) Individual, or Role based Inference control policies
Note, assumes security at lower layers, i.e: OS, Hardware and User authentication
Database Access Control
DBMS provide access control for databaseassume have authenticated userDBMS provides specific access rights to
portions of the databasee.g. create, insert, delete, update, read, writeto entire database, tables, selected rows or
columnspossibly dependent on contents of a table entry
can support a range of policies:centralized administrationownership-based administrationdecentralized administration
04/20/23Prof. Ehud Gudes Security
Ch 6 14
DBMS Discretionary Access Control
Based on the concepts of access rights or privileges for objects (tables and view), and mechanisms for giving users privileges (and revoking privileges).
Creator of a table or a view automatically gets all privileges on it.DBMS keeps track of who subsequently gains and
loses privileges, and ensures that only requests from users who have the necessary privileges (at the time the request is issued) are allowed.
04/20/23Prof. Ehud Gudes Security
Ch 6 15
History of Relational Systems
Codd’s paper – early 70sTwo research systems: Berkeley Ingres and IBM
System R – late 70sSQL was developed based on System RAll relational systems today are SQL (92,99)
compatibleSecurity:
Ingres – DAC, centralized, Rule-basedSystem R – DAC, Distributed, View based
SQL security follows System R security
04/20/23Prof. Ehud Gudes Security
Ch 6 16
Security in INGRES
Centralized, DBA enters authorization rulesThe query predicate is combined with the relevant
rule predicates to derive a modified queryThe concept of query modification – partial results
are possibleDifficult to manage a large group of users and rules
.
04/20/23Prof. Ehud Gudes Security
Ch 6 17
Protection in IngresDBA
User
PROTECTION INTERACTIONS
CONVERT TO
INTERNAL FORM
CONVERT TO
INTERNAL FORM
QUEL
query
VALIDATE AND
MODIFY
PROTECTIONSHARED
RELATIONS
04/20/23Prof. Ehud Gudes Security
Ch 6 18
(Rule 1) range of E is employeepermit E to Jones forretrieve (E.name, E.mgr)
where E.dept = ‘D1’
(Rule 2) range of E is employeepermit E to Jones forretrieve (E.name, E.dept, E.mgr)
where E.dept = ‘D1’
(Rule 3) permit E to jones for retrieve (E.name, E.sal)where E.mgr = ‘jones’
(Rule 4) permit E to jones for retrieve (E.sal)where E.sal < 100000
Protection in Ingres, cont.
04/20/23Prof. Ehud Gudes Security
Ch 6 19
Query1 range of E is employeeretrieve (E.name, E.Sal)
Only Rule3 matches, query is modified to; range of E is employee
retrieve (E.name, E.Sal) where (E.mgr = ‘Jones’)
Query2 range of E is employeeretrieve (E.name)
Both Rules1,2 and 3 match (see Hovereth)
Protection in Ingres, cont.
04/20/23Prof. Ehud Gudes Security
Ch 6 20
+Query simplicity Multiple table-queries may be expressed simply against a view
+ Structural simplicity Views can give a user a 'personalized' interpretation of the database
Security – a user sees only the portion relevant to him
+ Performance Views may be precompiled and
optimized
Update restrictions Many views are 'read-only'
The concept of Views – A Window over the database
04/20/23Prof. Ehud Gudes Security
Ch 6 21
The example database scenario
Employee Project
ssn
name
dep
salary
subject
title
client
date
ssn title
function
N M
Assignment
1 N
manages
Example Database (1)
04/20/23Prof. Ehud Gudes Security
Ch 6 22
AssignmentSSN Title
123 Celsius
124 Alpha
124 Beta
125 Alpha
125 Beta
125 Celsius
126 Celsius
Employee SSN Name Department Salary
123 Bob Sales 4.0 K
124 Susan Research 4,9 K
125 Josef Data Proc. 3,9 K
126 Calvin Assembling 6,2 K
127 Josef Research 6,2 K
Title Subject Client Manager
Alpha Development A 124
Beta Research B 125
Celsius Production C 123
Project
Example Database (2)
23
CREATE VIEW view-name AS query
(-- column_name --)
,
SSN Name Department
123 Bob Sales
124 Susan Research
125 Josef Data Proc.
126 Calvin Assembling
127 Josef Research
Horizontal View
(1) CREATE VIEW earning_little AS SELECT * FROM Employee WHERE Salary 5K
Vertical View
(2) CREATE VIEW emp AS SELECT SSN, Name, Department FROM Employee
SSN Name Department Salary 123 Bob Sales 4.0 K 124 Susan Research 4.9 K 125 Josef Data Proc. 3.9 K
earning_little
emp
Horizontal / Vertical View
04/20/23Prof. Ehud Gudes Security
Ch 6 24
(3) CREATE VIEW emp_research AS
SELECT SSN, Name, Department FROM Employee
WHERE Department = ‚Research‘
(4) CREATE VIEW dep_involved AS SELECT Title, Subject, Department
FROM Project, Assignment, Employee
WHERE Employee.SSN = Assignment.SSN AND
Assignment.Title = Project.Title
dep_involved
Title Subject Department Alpha Development Research Alpha Development Data Proc. Beta Research Research Beta Research Data Proc.
Celsius Production Assembling Celsius Production Data Proc. Celsius Production Sales
emp_research
SSN Name Department 124 Susan Research 127 Josef Research
Mixed View (1)
04/20/23Prof. Ehud Gudes Security
Ch 6 25
(5) CREATE VIEW dep_avg_salary AS
SELECT Department, Avg (Salary)
FROM Employee
GROUP BY Department
(6) CREATE VIEW my_employees AS
SELECT SSN, Name, Department, Salary
FROM Project, Assignment, Employee
WHERE Employee.SSN = Assignment.SSN AND
Assignment.Title = Project.Title AND
Manager = USER
for User ‚123‘
SSN Name Department Salary 126 Calvin Assembling 6,2 K 125 Josef Data Proc. 6,2 K 123 Bob Sales 4,0 K
dep_avg_salary
Department Avg
(Salary) Sales 4,0 K
Research 5,6 K Data Proc. 3,9 K
Assembling 6,2 K
Mixed View (2)
04/20/23Prof. Ehud Gudes Security
Ch 6 26
Views are ideal for security...
Views are ideal for security…value independent controls )2(
value dependent controls )1) ,(3) ,(4(
statistical controls )5(
context dependent controls )6(
04/20/23Prof. Ehud Gudes Security
Ch 6 27
The View Update problem
How to translate update on a view to unambiguous update on the Base tables?
Examples:Add an employee with salary >5K into view 1Add an employee to View 2 (null values)Update Salary in View 5.Add a new row into View 4
Generally the solution is: allow updates only on single level views which
include the primary key and all non-null attributes
04/20/23Prof. Ehud Gudes Security
Ch 6 28
Views and Security
Enable convenient specification and enforcement of access to portions of the database, which include any horizontal, vertical or join on the Base tables using standard SQL
Once a view is defined, the access to it is binary, either yes or no
Access control is provided only if access is via the view
Distributed administration: users are owners of the views they define and can delegate access further
Views are problematic for update
04/20/23Prof. Ehud Gudes Security
Ch 6 29
Authorization in SQL based systems – The GRANT command
The following privileges can be specified: SELECT: Can read all columns (including those added later
via ALTER TABLE command). INSERT(col-name): Can insert tuples with non-null or non-
default values in this column.INSERT means same right with respect to all columns.
DELETE: Can delete tuples. REFERENCES (col-name): Can define foreign keys (in other
tables) that refer to this column. If a user has a privilege with the GRANT OPTION, can pass
privilege on to other users (with or without passing on the GRANT OPTION).
Only owner can execute CREATE, ALTER, and DROP.
GRANT privileges ON object TO users [WITH GRANT OPTION]
04/20/23Prof. Ehud Gudes Security
Ch 6 30
GRANT SELECT
INSERT
DELETE
UPDATE
(column-name )
,,
ALL PRIVILEGES
ON base relation
view relation
TO user-name
PUBLIC
WITHGRANTOPTION
GRANT-Statement
04/20/23Prof. Ehud Gudes Security
Ch 6 31
REVOKE SELECT
INSERT
DELETE UPDATE
( column-name
)
,
, ALL PRIVILEGES
ON table-name FROM
GRANT OPTION FOR
user-name view-name PUBLIC
RESTRICT CASCADE
,
REVOKE Statement
04/20/23Prof. Ehud Gudes Security
Ch 6 32
ANSI / ISO SQL Standard SELECT
INSERT
DELETE
UPDATE
GRANT
DB2, Oracle ALTER
CREATE INDEX
Sybase, Sql Server EXTENDED SELECT
EXECUTE
DB2 USE Tablespace
Access Privileges in different DBMSs
04/20/23Prof. Ehud Gudes Security
Ch 6 33
GRANT and REVOKE of Privileges
GRANT INSERT, SELECT ON Employees TO Horatio Horatio can query Employees or insert tuples
into it.
GRANT DELETE ON Employees TO Yuppy WITH GRANT OPTION Yuppy can delete tuples, and also authorize
others to do so.
GRANT UPDATE Salary ON Employees TO Dustin Dustin can update (only) the salary field of
Employees tuples.
04/20/23Prof. Ehud Gudes Security
Ch 6 34
Revoke options
Reject (SQL)
Non-recursive revocation (Fernandez)
Time based recursive revocation (System R)
System based recursive revocation (SQL)
04/20/23Prof. Ehud Gudes Security
Ch 6 35
Protection in System R
.A:GRANT READ ON EMP TO B WITH GRANT OPTIONA:GRANT READ ON EMP TO C WITH GRANT OPTIONB:GRANT READ ON EMP TO XC:GRANT READ ON EMP TO X
Protection in System R
ולכן שלילת הזכויות C ומ-B קיבל זכויות משני גורמים מ-Xבדוגמה זו רואים כי . אם לדוגמה נבצע את הפקודהX אינה גורמת בהכרח שלילת הזכויות מ-Bמ-
A: REVOKE READ ON EMP FROM Bנקבל את הגרף באיור ( SYSTEM Rאזי במקרה של קיום שלילה רקורסיבית (
-א' )FERNANDEZובמקרה של אי קיום שלילה רקורסיבית (לפי
נקבל את הגרף באיור - ב'.
04/20/23Prof. Ehud Gudes Security
Ch 6 37
a1(_SYSTEM, A, SELECT, T, yes, 10)
a2(A, B, SELECT, T, yes, 20) a3(A, C, SELECT, T, yes, 30)
a4(B, D, SELECT, T, yes, 40)
a5(D, E, SELECT, T, yes, 50)
a6(C, D, SELECT, T, yes, 60)
a7(D, F, SELECT, T, yes, 70)
a8(E, G, SELECT, T, yes, 80)
A
B
2
3
D
C
E
F
G4
5
6 7
8
The privilege dependency graph
04/20/23Prof. Ehud Gudes Security
Ch 6 38
A
B
2
3
D
C
E
F
G4
5
6 7
8
B
A
2
3
D
C F
6 7
REVOKE IN SYSTEM R
Revoking a4 (with CASCADE option) will succeed. Authorization a7will not be revoked, because it is supported by a6, but a5 and a8
Will be revoked. The privilege dependency graph will change.
04/20/23Prof. Ehud Gudes Security
Ch 6 39
REVOKE in System RREVOKE: procedure (grantee, privilege, table, grantor);
comment turn off the grantee’s authorization for privilege obtained from granter;set privilege = 0 in the (grantee, table, grantor) tuple in SYSAUTH;comment find the minimum timestamp for the grantee’s remaining grantable privilege on table;m current timestamp;for each granter u such that (grantee, privilege, table, u, grantable) is in
SYSAUTH do if privilege 0 and privilege < m then m privilege;
comment revoke grantee’s grants of privilege on table which were made before time m;
For each user u such that (u, privilege, table, grantee) is in SYSAUTH do if privilege < m
then REVOKE (u, privilege, table, grantee) ;returnend REVOKE
04/20/23Prof. Ehud Gudes Security
Ch 6 40
Suppose that at time t=35, B issues the command REVOKE ALL RIGHTS ON EMPLOYEE FROM X. Clearly the (X, EMPLOYEE, B) tuple must be deleted from SYSAUTH. In order to determine which of X’s grants of EMPLOYEE must be revoked, we form a list of X’s remaining incoming grants:
Protection in System R, cont.
As well as a list of X’s grants to others:
The grant of the DELETE privilege by X to Y at time t=25 must be revoked because his earliest remaining DELETE privilege was received at time t=30. But X’s grants of READ and INSERT are allowed to remain because they are still “supported” by incoming grants which occurred earlier in time.
USERIDTABLEGRANTORREADINSERTDELETE
XEMPLOYEEA15150
XEMPLOYEEB20020
YEMPLOYEEX252525
XEMPLOYEEC30030
TABLEREADINSERTDELETE
EMPLOYEE{15, 30}{15}{30}
04/20/23Prof. Ehud Gudes Security
Ch 6 41
GRANT/REVOKE on Views
If the creator of a view loses the SELECT privilege on an underlying table, the view is dropped!
If the creator of a view loses a privilege held with the grant option on an underlying table, (s)he loses the privilege on the view as well; so do users who were granted that privilege on the view!
04/20/23Prof. Ehud Gudes Security
Ch 6 42
Revoking Access on Views- System R
REVOKE : procedure (grantee, table, grantor) ;delete the (grantee, table, grantor) tuple in
SYSAUTH;for each u such that (u, table, grantee) is in
SYSAUTH do REVOKE (u, table, grantee) ;for each view such that (table, view, grantee) is
in SYSUSAGE do DROP (view) ;return ;end REVOKE ;
DROP :procedure (view) ;delete the view definition from the system ;for each u1 and u2 such that (u1, view, u2) is in
SYSAUTH do REVOKE (u1, view, u2) ;for each v and u such that (view, v, u) is in
SYSUSAGE do DROP (v) ;return ;end DROP ;
04/20/23Prof. Ehud Gudes Security
Ch 6 43
REVOKE in SQL
RESTRICT – accept only if there are no privileges resulted SOLELY from the revoked command, otherwise reject
CASCADE – remove privileges recursively as in System R, but do not consider time!, that is, if a privilege was granted to B by A, and A’s rights were revoked, but LATER A was given these rights independently, then don’t revoke B’s rights - this is equivalent to saying that there is a path from the “System” node
04/20/23Prof. Ehud Gudes Security
Ch 6 44
Protection in SQLGRANT SELECT ON Sailors TO Art WITH GRANT OPTION (executed by Joe)GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION (executed by Art)GRANT SELECT ON Sailors TO Art WITH GRANT OPTION (executed by Bob)GRANT SELECT ON Sailors TO Cal WITH GRANT OPTION (executed by Joe)GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION (executed by Cal)REVOKE SELECT ON Sailors FROM Art CASCADE (executed by Joe)
04/20/23Prof. Ehud Gudes Security
Ch 6 45
System
Joe
Cal
Art
Bob
(System, Joe, Select on Sailors, Yes)
Protection in SQL, cont.
04/20/23Prof. Ehud Gudes Security
Ch 6 46
Protection in SQL, cont.
What happens if Joe revokes access from Cal
04/20/23Prof. Ehud Gudes Security
Ch 6 47
a1(_SYSTEM, A, SELECT, T, yes, 10)
a2(A, B, SELECT, T, yes, 20) a3(A, C, SELECT, T, yes, 30)
a4(B, D, SELECT, T, yes, 40)
a5(D, E, SELECT, T, yes, 50)
a6(C, D, SELECT, T, yes, 60)
a7(D, F, SELECT, T, yes, 70)
a8(E, G, SELECT, T, yes, 80)
A
B
2
3
D
C
E
F
G4
5
6 7
8
The privilege dependency graph
04/20/23Prof. Ehud Gudes Security
Ch 6 48
A
B
2
3
D
C
E
F
G4
5
7
8
SQL - REVOKE with RESTRICT option
Revoke of a4 with RESTRICT option will fail! If we have added a6 ,then it would not have failed!
04/20/23Prof. Ehud Gudes Security
Ch 6 49
• Negative authorizations
• Non cascading revoke
A
B
2
3
D
C
E
F
G4
5
6 7
8A
B
2
3
D
C
E
F
G5
6 7
8
What may be useful and is not supported in SQL92?
04/20/23Prof. Ehud Gudes Security
Ch 6 50
Why needs SELECT right with Integrity constraints?
May infer values from non permitted table!
CREATE TABLE Sneaky (maxsalary INTEGER,CHECK ( maxsalary >=
( SELECT MAX (S.salary ) FROM Employees
S )))
Protection in SQL, cont.
04/20/23Prof. Ehud Gudes Security
Ch 6 51
Protection in SQL, cont.
Why SELECT right is not sufficient?Since owner rights may be restricted (cannot delete
rows)!Needs explicit REFERENCE right
CREATE TABLE Assignments (project CHAR (10) NOTNULL, SSN INTEGER,
day DATE, PRIMARY KEY (SSN, day),
FOREIGN KEY (SSN) REFERENCES Employees ON DELETE NO ACTION
04/20/23Prof. Ehud Gudes Security
Ch 6 52
Differences Between System R and SQL-92
New privileges – REFERENCE, USAGE
CASCADE or RESTRICT on Revoke
CASCADE different then System R – not time-stamp based
Precise definitions for Rights on viewsE.g. the impact of adding/removing a right to/from the base tables
Authorization-Ids (for programs), Groups and Roles
Role-Based Access Control
role-based access control work well for DBMSeases admin burden, improves security
categories of database users:application ownerend useradministrator
DB RBAC must manage roles and their userscf. RBAC on Microsoft’s SQL Server
Table 5.2 in [SB] lists a set of administrative roles for MS-SQL server
04/20/23Prof. Ehud Gudes Security
Ch 6 54
Role-Based Authorization
In SQL-92, privileges are actually assigned to authorization ids, which can denote a single user or a group of users.
In SQL:1999 (and in many current systems), privileges are assigned to roles. Roles can then be granted to users and to other
roles. Reflects how real organizations work. Illustrates how standards often catch up with “de
facto” standards embodied in popular systems.
04/20/23Prof. Ehud Gudes Security
Ch 6 55
Roles and PermissionsMedical_Staff: collectively, responsible for all aspects of direct
patient care.
Nurse: Direct involvement with patient care on a daily basis.
Physician: Handle the medical needs (diagnosis, treatment, etc.) for patients.
Pharmacists: Control the supply and distribution of all drugs throughout the hospital.
Technician: Provide a variety of medical testing support for Patients.
Therapist: Evaluate patients and develop treatment plans for therapy.
Staff_RN: Administer direct care to patients and implement the physician treatment plan.
04/20/23Prof. Ehud Gudes Security
Ch 6 56
Discharge_Plug: Link between patients and outside agencies for care after discharge.
Education: Educate both the nursing staff and patients regarding new treatment and self care.
Manager: Responsible for the day-to-day operation of a nursing unit
Director: (For Physician or Pharmacist) Responsible for the day-to-day operation of their respective
department/medical service.
Private: the physician within his/her office/private–practice setting.
Attending: A physician that hes privileges to admit and treat patients at a hospital.
Roles and Permissions, cont.
04/20/23Prof. Ehud Gudes Security
Ch 6 57
The User-Role Definition Hierarchy
User Types, User Classes and Selected User Roles
Medical StaffUsers
Nurse Physician Pharmacist Technician Therapist
Support Staff
Support
Prepare room Volunteer Security
Other
Patient Spouce
04/20/23Prof. Ehud Gudes Security
Ch 6 58
Role-Based Models
RBAC0 – Users, Roles, Permissions, Sessions
RBAC1 – RBAC0 + Role-hierarchies
RBAC2 – RBAC0 + Constraints
RBAC3 – RBAC0 + Role-hierarchies + Constraints
04/20/23Prof. Ehud Gudes Security
Ch 6
RBAC0
.המודל הבסיסי עליו מתבססים שאר המודלים
Users(U)
Roles(R)
Userassignment
(UA)
Permissionassignment
(PA) Permissions(P)
Sessions(S)
04/20/23Prof. Ehud Gudes Security
Ch 6
RBAC1
היררכייתRole.ים-
Users(U)
Roles(R)
Userassignment
(UA)
Permissionassignment
(PA) Permissions(P)
Sessions(S)
Role hierarchy(RH)
04/20/23Prof. Ehud Gudes Security
Ch 6
RBAC1
היררכיה שלRoleים-:.קשר אב ובן.הרשאות אפקטיביות וישירות
Employee[Read]
Developer[Read,Develop]
QA[Read,Test]
Admin[Read,Test,Develop]
04/20/23Prof. Ehud Gudes Security
Ch 6
RBAC1
הגבלת ירושה.
Employee[Read]
Developer[Read,Develop]
QA[Read,Test]
Admin[Read,Test,Develop]
Developer'[Read,Develop,Build]
04/20/23Prof. Ehud Gudes Security
Ch 6
RBAC2
מודל האילוציםRole.ים מנוגדים-
Users(U)
Roles(R)
Userassignment
(UA)
Permissionassignment
(PA) Permissions(P)
Sessions(S)
Constranits
04/20/23Prof. Ehud Gudes Security
Ch 6
RBAC3
המודל המשולב: אילוצים והיררכייתRoles .
Users(U)
Roles(R)
Userassignment
(UA)
Permissionassignment
(PA) Permissions(P)
Sessions(S)
Role hierarchy(RH)
Constranits
04/20/23Prof. Ehud Gudes Security
Ch 6 65
Constraints in RBAC – Separation of duties
Conflicts between Permissions – conflicting permissions cannot be in the same Role or in two roles with a common ancestor
Conflicts between Roles – the same user cannot be in two conflicting roles
Conflicting usersStatic constraints – max. number of roles per
user, permissions per role, etcDynamic constraints – session dependent
04/20/23Prof. Ehud Gudes Security
Ch 6 66
Roles in SQL99New in SQL99; benefits:
Simplifies definition of complex sets of privileges
Roles are created
CREATE ROLE AuditorCREATE ROLE AuditorGeneral
Roles may be assigned to users & rolesGRANT Auditor TO AuditorGeneralWITH ADMIN OPTIONGRANTED BY CURRENT ROLE
GRANT Auditor TO Smith
Controllable whether to grant as user or role
04/20/23Prof. Ehud Gudes Security
Ch 6 67
Roles in SQL99, cont.
Roles (like users) may own objects
As to users, privileges may be granted to roles Grant INSERT ON TABLE Budget TO AuditorThis privilege also among privileges of AuditorGeneral
A role R identifies a set of privileges:Those directly granted to RThose of the roles granted to R
04/20/23Prof. Ehud Gudes Security
Ch 6 68
At any time there is at least a valid current user or a valid current role.
Current user can be set
SET SESSION AUTHORIZATION ‘JDOE’Current role can be set or invalidates
SET ROLE AuditorOperations (e.g. INSERT) determine the kind of required
privilegesOften: union of user’s and role’s privileges
Session context maintains stack of user and role identifier pairsNew pair is pushed when externally invoked procedure is executedTemporarily makes client module identifier the current userEnables invoker’s rights in a limited fashion
Roles in SQL99, cont.
04/20/23Prof. Ehud Gudes Security
Ch 6 69
Advantages of RBACConvenient representation and mapping of the
organization structureConvenient distribution of the administration of
RolesEasier definition and understanding of the security
policy of the organizationRole-hierarchy and inheritance of permissions
eases administrator jobChanges in user roles are simple and controllableSessions allow the same user different roles in
different contextsGrouping multiple users to roles allow easier
control of their permissions
04/20/23Prof. Ehud Gudes Security
Ch 6 70
Security in Object-Oriented Databases
Composition hierarchy [K]Generalization hierarchy [K]Explicit and implicit authorization [K]Strong and weak authorization [K]Inheritance – which authorizations are inherited?
[G]Algorithm for evaluation [G]Negative authorization [G]
04/20/23Prof. Ehud Gudes Security
Ch 6 71
Database Granularity HierarchySystem [MCC]
database [Inventory] database [CAD] Database…
class [vehicle] class [automobile] class [4-wheel-vehicle] class [Motor-Vehicle]
instance [1] instance [2] Instance… instance [100]
Attribute-value [Weight] Attribute-value…
Database Granularity Hierarchy
04/20/23Prof. Ehud Gudes Security
Ch 6 72
Class Hierarchy
Vehicle
Automobile
4-Wheel-Vehicle Motor-Vehicle
IS-A
IS-A
IS-A
IS-A
04/20/23Prof. Ehud Gudes Security
Ch 6 73
Implicit Weak Authorization with Weak Exceptions
04/20/23Prof. Ehud Gudes Security
Ch 7 74
Implicit Weak Authorization with Strong Exceptions
04/20/23Prof. Ehud Gudes Security
Ch 6 75
Security in OO Databases
04/20/23Prof. Ehud Gudes Security
Ch 6 76
Mandatory Access Control
Based on system-wide policies that cannot be changed by individual users. Each DB object is assigned a security class. Each subject (user or user program) is assigned a
clearance for a security class. Rules based on security classes and clearances
govern who can read/write which objects.
Most commercial systems do not support mandatory access control. Versions of some DBMSs do support it; used for specialized (e.g., military) applications.
04/20/23Prof. Ehud Gudes Security
Ch 6 77
Why Mandatory Control?
Discretionary control has some flaws, e.g., the Trojan horse problem: Dick creates Horsie and gives INSERT privileges to
Justin (who doesn’t know about this). Dick modifes the code of an application program
used by Justin to additionally write some secret data to table Horsie.
Now, Dick can see the secret info.
The modification of the code is beyond the DBMSs control, but it can try and prevent the use of the database as a channel for secret information.
04/20/23Prof. Ehud Gudes Security
Ch 7 78
Bell-LaPadula Model
Objects (e.g., tables, views, tuples)
Subjects (e.g., users, user programs)
Security classes: Top secret (TS), secret (S), confidential (C),
unclassified (U): TS > S> C > U
Each object and subject is assigned a class. Subject S can read object O only if class(S) >=
class(O) (Simple Security Property) Subject S can write object O only if class(S) <=
class(O) (*-Property6
04/20/23Prof. Ehud Gudes Security
Ch 6 79
Intuition
Idea is to ensure that information can never flow from a higher to a lower security level.
E.g., If Dick has security class C, Justin has class S, and the secret table has class S: Dick’s table, Horsie, has Dick’s clearance, C. Justin’s application has his clearance, S. So, the program cannot write into table Horsie.
The mandatory access control rules are applied in addition to any discretionary controls that are in effect.
04/20/23Prof. Ehud Gudes Security
Ch 6 80
Multilevel Relations
Users with S and TS clearance will see both rows; a user with C will only see the 2nd row; a user with U will see no rows.
If user with C tries to insert <101,Pasta,Blue,C>: Allowing insertion violates key constraint Disallowing insertion tells user that there is another
object with key 101 that has a class > C! Problem resolved by treating class field as part of key.
CBrownPinto102
SRedSalsa101
classcolorbname
bid
04/20/23Prof. Ehud Gudes Security
Ch 6 81
Sea View(SRI International, Oracle, Gemsos)MLS relational datamodel, supports polinstentiation on db-, relation- , tupel- and attribute levels.
LDV (LOCK Data Views)(Honeywell SCTC, MITRE)Extended relational data model, polyinstatiation on tuple level. Supports application dependent and non application dependent integrity rules.
MLS-Prototype systems
04/20/23Prof. Ehud Gudes Security
Ch 6 82
A Database D;A relation R within the database D;The primary key for a tuple r within the relation R;
The attribute i, identifying the element ri within the tuple r.
To get through to the element ri, the following must hold:
lab(D)lab(R) lab(ri)
Otherwise, you could be barred access to an element you are entitled to see. In convention, a user who has access to an element of r must have access to its primary key.Therefore: lab(rk) lab(ri)
Jajodia - Formal Integrity Rules
04/20/23Prof. Ehud Gudes Security
Ch 6 83
Jajodia - Formal Integrity Rules, cont.
Rule Multi-level entity integrity: no component of a primary key of a base relation may be null. All components of a primary key of a base relation have the same access class. In a base relation, the access class of all other data values in a tuple dominates the access class of the primary key of that tuple.
04/20/23Prof. Ehud Gudes Security
Ch 6 84
Rule Multi-level reference integrity: a tuple referenced by a foreign key has to exist. The access class of the foreign key dominates the access class of the corresponding primary key.
Rule The access class of a view dominates the access classes of all relations used in the definition of the view.
Rule The access class of a tuple dominates the access classes of all attributes in the tuple.
Formal Integrity Rules, cont.
04/20/23Prof. Ehud Gudes Security
Ch 6 85
Multi-level Relation
Flight [Fl_Class]Dest.
[De_Class]Seats
[Se_Class][Tuple_Class]
CA909 [C]H.K. [C]7 [C][C]
AX301 [U]K.L. [U]2 [U][U]
GR555 [U]L.A. [C]11 [C][C]
Figure 15.1 The Relation Bookings with Primary Key Flight
04/20/23Prof. Ehud Gudes Security
Ch 6 86
Multi-level Relation – view of C user
Flight [Fl_Class]Dest.
[De_Class]Seats
[Se_Class]
CA909 [C]H.K. [C]7 [C]
AX301 [U]K.L. [U]2 [U]
GR555 [U]L.A. [C]11 [C]
Figure 15.1 The Relation Bookings with Primary Key Flight
04/20/23Prof. Ehud Gudes Security
Ch 6 87
Multi-level relation – view of U user
Figure 15.2 List of Non-Confidential Data from fig. 15.1 Accessible to Unclassified User
FlightDestSeats
AX301K.L.2
GR555----
04/20/23Prof. Ehud Gudes Security
Ch 6 88
if the DBMS should not inform a lower trusted user that tries to insert data that the data is already in the system,
if a higher trusted user wishes to change lower classified data, to avoid (covert) signalling channels,
if the understanding of the reality is different among users with differing security labels (i. e., cover stories should be supported).
Polyinstatiation is necessary
04/20/23Prof. Ehud Gudes Security
Ch 6 89
Why Poly-instantiation?A low user tries to add information on flight CA909.
If refused – inference, if accepted - violation of primary key constraint
A low user tries to update information on flight GR555.If refused – inference, if accepted - violation of
functional dependencyA high user attempt to change destination of flight
AX301 If refused – restricts access, if accepted - violation
of functional dependencySolution: accept and include tuple class as part of the
primary key!.
04/20/23Prof. Ehud Gudes Security
Ch 6 90
Polyinstatiated table after User U update
Flight [Fl_Class]Dest.
[De_Class]Seats
[Se_Class][Tuple_Class]
CA909 [C]H.K. [C]7 [C][C]
AX301 [U]K.L. [U]2 [U][U]
GR555 [U]L.A. [C]11 [C][C]
GR555 [U]N.Y. [U]0 [U][U]
Figure 15.4 Updated Version of Table Data Given in Figure 15.1.
04/20/23Prof. Ehud Gudes Security
Ch 6 91
Polyinstatiation Cont.
FlightDestSeats
CA909H.K.7
AX301K.L.2
GR555L.A.11
GR555N.Y.0
Figure 15.5 Data Accessible to Confidential User
04/20/23Prof. Ehud Gudes Security
Ch 6 92
Subsumption
If user view has a null in U attribute and User C update it with non-null value, the C tuple subsumes the U tuple and only one tuple is visible to C
04/20/23Prof. Ehud Gudes Security
Ch 6 93
Polyinstantiation integrity
Polyinstantiation integrity If two tuples in a base relation have the same primary key and the respective entries for some attribute have the same access class, then also the data values for this attribute are the same. If two tuples of a base relation have the same primary key and if there are some attributes where the respective entries have different access classes, then the values for those attributes may differ and any combination of these values (and access classes) gives again a tuple in the relation.
04/20/23Prof. Ehud Gudes Security
Ch 6 94
Polyinstantiation Integrity
Flight [Fl_Class]Dest.
[De_Class]Seats
[Se_Class][Tuple_Class]
CA909 [C]H.K. [C]7 [C][C]
AX301 [U]K.L. [U]2 [U][U]
GR555 [U]L.A. [C]11 [C][C]
GR555 [U]L.A. [C]0 [U][C]
GR555 [U]N.Y. [U]11 [C][C]
GR555 [U]N.Y. [U]0 [U][U]
Assume query: Dest = NY and Seats = 11 by C user – need to add two rows over table from p. 105
04/20/23Prof. Ehud Gudes Security
Ch 6 95
Implementation Options
1. Rely only on ML-OS There is a separate single-level DBMS process running
at each access class. Multi-level relations are stored as a collection of single- level operating systems. The DBMS has to use a partial ordering of access classes supported by the operating system.
2. DBMS is a Trusted Subject Proceed with the update and polyinstantiate the data, or Deny the update and record this event in an audit log.
04/20/23Prof. Ehud Gudes Security
Ch 6 96
MLS Concurrecy Control
Assume user S locked a record for write and now user U tries to read it. The existence of this lock is already secret information!
If lock is at level S, user U (or U scheduler) should be unaware of it and will try to read the record.
If lock is at level U then user S violated BLP!
SOLUTION? Read papers!
Inference
Inference Example
04/20/23Prof. Ehud Gudes Security
Ch 6 99
Statistical DB Security
Statistical DB: Contains information about individuals, but allows only aggregate queries (e.g., average age, rather than Joe’s age).
New problem: It may be possible to infer some secret information! E.g., If I know Joe is the oldest sailor, I can ask
“How many sailors are older than X?” for different values of X until I get the answer 1; this allows me to infer Joe’s age.
Idea: Insist that each query must involve at least N rows, for some N. Will this work? (No!)
04/20/23Prof. Ehud Gudes Security
Ch 6 100
Why Minimum N is Not Enough
By asking “How many sailors older than X?” until the system rejects the query, can identify a set of N sailors, including Joe, that are older than X; let X=55 at this point.
Next, ask “What is the sum of ages of sailors older than X?” Let result be S1.
Next, ask “What is sum of ages of sailors other than Joe who are older than X, plus my age?” Let result be S2.
S1-S2 is Joe’s age!
04/20/23Prof. Ehud Gudes Security
Ch 6 101
Types of Sensitive Data
Exact data – e.g. salary of John Doe
Bounds
Negative results – e.g. 0 is not the total number of felonies
Existence – e.g. of AIDS virus
Probable values
04/20/23Prof. Ehud Gudes Security
Ch 6 102
Example Database
NAME(Not
stored)
SEXLEV(job level)
LOC(Work location)
SAL(Salary)
0.10.20.3
DIAZM60SF36122
SMITHF58SF24321
JONESM56LA26423
KATZM57LA30332
CLARKF58LA28514
WONDF60LA34111
WEBBM58SF32555
103
Stat. DB security – size restriction
הגנה אפשרית מפני שתי שאילתות אלו היא הגבלה כי גודל !1התשובה לכל שאילתא יהיה גדול מ-
אולם אז ניתן לשאול את השאילתות הבאות:
Q1=COUNT(LOC=‘SF’LOC=‘SF’)
Q2=COUNT(LOC =‘SF’SEX=‘F’)
– מס' הרשומות בטבלה.7התשובה לשאילתא הראשונה תהיה Q1-Q2=1 וההפרש ביניהן אחד 6התשובה לשאילתא השנייה תהיה
מכאן ניתן לבצע את שתי השאילתות הבאות:
Q3=SUM(LOC=‘SF’LOC=‘SF’;SAL)
Q4=SUM(LOC=‘SF’SEX=‘F’;SAL)
!Q4-Q3והמשכורת הרצויה היא כמובן
04/20/23Prof. Ehud Gudes Security
Ch 6 104
Stat. DB security – size restriction רואים טבלה ובה מידע על עובדים ומשכורותיהם (שים לב 7.5בטבלה
ששדה השם אינו מופיע בבסיס הנתונים). אחד הדברים שאיננו מעונינים לחשוף הוא משכורתו של עובד מסוים. אולם קל מאוד כן
לחשוף זאת ע"י שאילתא חוקית לחלוטין (ע"י תהליך הסקה). שאילתא חוקית היא מהצורה:
function (Predicate; Attribute) הוא Attribute, ו-SUM או COUNT היא פונקציה כמו functionכאשר
השדה שעליו פועלת הפונקציה. גרה בעיר Smithלדוגמא, נניח שאנו יודעים כי הפרט שאנו מעונינים בו
SF.(סן פרנסיסקו)והיא אשה אזי ביצוע השאילתות הבאות
COUNT (LOC=‘SF’ . SEX=‘F’) SUM (LOC=‘SF’ . SEX=‘F’;SAL)וכן
!Smithייתן את משכורתה של
04/20/23Prof. Ehud Gudes Security
Ch 6 105
The individual Tracker
Assume C characterize the individual uniquely – then Q(C) or Q(C*S) is unanswerable, S is the searched field.
Assume C=AB where both Q(A) and Q(AB^) are answerable.
Then Q(C)=Q(A)-Q(AB^) orQ(C*S)=Q(A*S)-Q(AB^*S)
04/20/23Prof. Ehud Gudes Security
Ch 6 106
The Individual Tracker - Example
C=F*CS*Prof, A=F, B=CS*Prof
Unique Identifier
SexDeptPositionSalary ($K)Political Contribution ($)
AdamsMCSProf.2050
BakerMMathProf.15100
CookFMathProf.25200
DoddFCSProf.1550
EngelMStatProf.180
FlynnFStatProf.22150
GradyMCSAdm.1020
HayesMMathProf.18500
IronsFCSStu.310
JonesMStatAdm.2015
KnappFMathProf.25100
LordMCSStu.30
04/20/23Prof. Ehud Gudes Security
Ch 6 107
The General Tracker
Assume threshold is K.Find T such that
2k <= count(T) <= n-2k
Then, k <= count(T+C) <= n-k andk <= count(T^+C) <= n-k
So, both are answerable!And Q(C) = Q(T+C) + Q(T^+C) –n !
04/20/23Prof. Ehud Gudes Security
Ch 6 108
Some Defenses
Replacing precise values with range values
Use samples from the original database
Perturb data randomly
Perturb results randomly
Partition the database
Audit trail and query analysis
Protecting Against Inference
Other Query Restrictions
query set overlap control limit overlap between new & previous querieshas problems and overheads
partitioningcluster records into exclusive groupsonly allow queries on entire groups
query denial and information leakagedenials can leak information to counter must track queries from user
Perturbation
add noise to statistics generated from datawill result in differences in statistics
data perturbation techniquesdata swappinggenerate statistics from probability distribution
output perturbation techniquesrandom-sample querystatistic adjustment
must minimize loss of accuracy in results
04/20/23Prof. Ehud Gudes Security
Ch 6 112
The Inference Problem, cont.
To show that a refusal to answer may reveal a secret, we now consider a system that only refuses if the answer would reveal a secret. Suppose the following integrity constraints apply to a database containing the fact that Mediocrates is an Athenian:
Every man is an Athenian, a Boeotian, a Corinthian, or a Dorian;
All Athenians and Corinthians are peaceable;All Boeotians and Dorians are violent;
04/20/23Prof. Ehud Gudes Security
Ch 6 113
The Inference Problem, cont.
Mediocrates does not wish it to be known that he is peaceable. Rhinologus, a public nuisance, tries to find out about Mediocrates:
Rhinologus: Is Mediocrates an Athenian?System: I will not tell you.Rhinologus: Is he a Boeotian?System: No.Rhinologus: Is he a Corinthian?System: No.Rhinologus: Is he a Dorian, then?System: I will not tell you.
04/20/23Prof. Ehud Gudes Security
Ch 6 114
The Inference Problem – Answering Queries Without Revealing Secrets
k
k
k
k
“is Mediocrates an Athenian”?
“is Mediocrates a Boeotian”?
“is Mediocrates a Corinthian”?
“is Mediocrates a Dorian”?
k
mum
mum
mum
mum
yes
yes
yes
yes
no
no
no
no
K ‘M is peaceable’
04/20/23Prof. Ehud Gudes Security
Ch 6 115
Database Encryption
116
DBMS Data - The Attackers
Intruder Tries to attack the confidentiality or integrity
of the database. Tries to take over the identity of a regular user (or
DBA). Most attacks are targeted at web applications.
The database service provider \ Administrator Tries to obtain information beyond his
own access rights. Tries to change the content of the database for his
own benefit (e.g., change account balance). Most attacks are targeted at outsourced databases.
The data owner \ Client Has sufficient privileges to tamper with the access
right definition – possibly unlimited privileges.
Database Encryption
databases typical a valuable info resourceprotected by multiple layers of security:
firewalls, authentication, O/S access control systems, DB access control systems, and database encryption
can encryptentire database - very inflexible and inefficientindividual fields - simple but inflexible records (rows) or columns (attributes) - best
also need attribute indexes to help data retrieval
varying trade-offs
Database Encryption
04/20/23Prof. Ehud Gudes Security
Ch 6 119
Database Encryption at the Table Level
Encrypting the entire table after every change.
Substitution and statistical attacks on the table values are eliminated.
Weakness: In order to execute a query the whole table needs to be decrypted.
Client DBMS Encrypted Database
Encryption
DecryptionSecured
Communication
Intruder
Insider
Admin
#$*#@#$%^#$@!@#$%%$@!@#&$&^*%$%^&$
04/20/23Prof. Ehud Gudes Security
Ch 6 120
Database Encryption at the Cell Level
Encrypting each cell separately.Only the data of interest needs to be
decrypted while performing a query.
Weakness: Substitution and statistical attacks are possible.
Client DBMS Encrypted Database
Encryption
DecryptionSecured
Communication
Intruder
Insider
Admin
RowVal
0%$
1!@
2%$
%$16
04/20/23Prof. Ehud Gudes Security
Ch 6 121
Database Encryption at the Row Level
The database encryption scheme described by Davida(81) is based on the Chinese-Reminder theorem.
Each row is encrypted using different sub-keys for different cells. Enables: encryption at the level of rows and decryption at the
level of cells.
Weakness: Requires re-encrypting the entire row when a cell value is modified.
Weakness: The basic element in the database is a row and not a cell, thus the structure of the database needs to be changed.
04/20/23Prof. Ehud Gudes Security
Ch 6 122
SPDE - A New Database Encryption Scheme
Each cell is encrypted with its uniquecell coordinates.
Only the data of interest needs to bedecrypted while performing a query.
Substitution and statistical attacksare eliminated.
Client DBMS Encrypted Database
Encryption
DecryptionSecured
Communication
Intruder
Insider
Admin
RowVal
0&$
1@#
2*^
&$16
04/20/23Prof. Ehud Gudes Security
Ch 7 123
Cell Coordinates Characteristics
Stable cell coordinates: Insert, update and delete operations do not change
the coordinates of existing cells. For example, this is the case in the Oracle
database.
If a database reorganization process changes cell coordinates, all affected cells are to be re-encrypted with their new coordinates.
04/20/23Prof. Ehud Gudes Security
Ch 7 124
IndexingEncrypted Data
04/20/23Prof. Ehud Gudes Security
Ch 6 125
Building an Index on the Encrypted Data
Indexing the encrypted data using a hash index.Equality queries are possible.
Weakness: Statistical attacks are possible by usingthe index.
Weakness: No range queries.
Row-idVal
AAA&$
AAB@#
AAC&$
@#
&$
Encrypted Table Index
Row-idVal
AAA16
AAB26
AAC16
Decrypted Table
04/20/23Prof. Ehud Gudes Security
Ch 6 126
Encrypting Each Index Value Separately
Building the index on the plaintext values and encrypting each index value separately.
Range queries are possible.
Weakness: Statistical attacks are possible by using the index. Weakness: The order of the ciphertext values is exposed.
Row-idVal
AAA&$
AAB@#
AAC&$
Encrypted Table Index
&$
&$
Maximum@#
Row-idVal
AAA16
AAB26
AAC16
Decrypted Table
04/20/23Prof. Ehud Gudes Security
Ch 6 127
Encrypting Each Index Node Separately
The indexing scheme provided by Damiani(03) suggests encrypting each node of the B+-Tree as a whole.
References between the B+-Tree nodes are encrypted together with the index values.
The index does not reveal the statistics or order of the database values
Weakness: The index structure is concealed.
Row-idVal
AAA#!
AAB^&
AAC*#
Encrypted Table
Index
@#
Row-idVal
AAA16
AAB26
AAC16
Decrypted Table
*!
&$
04/20/23Prof. Ehud Gudes Security
Ch 6 128
A New Database Indexing Scheme
Each index value is the result of encrypting a plaintext value in the database with its row-id.
This ensures that the index does not reveal the statistics or order of the database values.
The new database indexing scheme preserves the index structure.
Row-idVal
AAA#!
AAB^&
AAC*#
Encrypted Table Index
@#
&$*!
Row-idVal
AAA16
AAB26
AAC16
Decrypted Table
04/20/23Prof. Ehud Gudes Security
Ch 6 129
SPDE - Conclusions
A new structure preserving scheme for database encryption has been presented.
In the new scheme, patterns matching and substitution attacks cannot succeed, thus guaranteeing information confidentiality and data integrity.
The new schemes do not impose any changes on the database structure. A DBA is able to manage the encrypted database as
any other non-encrypted database. Implementing the new scheme in existing applications
does not entail modifying the queries.
SQL Injection
Traditional DB
• Two-tier architecture• Users are fixed and known• Users’ number is limited• All transactions are passed via the same
connection and users connect directly to the DB
Traditional DB Access Control
• DB can identify and authenticate its users
• DB can authorize users by traditional user/role-based access control
• It is quite easy to follow up single user transactions to seek signs of intrusion
• Views can be used to determine for a user the only part of the database that interests her
Web Databases
•Three-tier architecture
•Users are casual and unknown
•Users’ number is not limited
•Users do not connect directly to the DB
Connection Pooling
Different web users can run their SQL statements on the same DB connection and one user can run her SQL statements on different connectionsThis technique contributes to application
efficiency since the time to open and close the connection is saved per each request
It has serious implications on the database’s access control mechanism
Web DB Access Control
Web DB does not identify the real application user who accesses it
The only user accessing the database is the user of the web application server – most often with full access privileges (administrator or “super-user”)
No user-based access control can be appliedOnly limited RBAC can be appliedThe principle of minimal privilege is violatedNo more fine-grained access control to the
web DB exists
Web DB is vulnerableThere is no way to limit the web user privileges
at the database level of the web databases.There are still many secured web applications,
but their security can be achieved only by application means (writing lines of code that implement security policies) and not by database access control means (GRANT/REVOKE and VIEWS)
This situation is very problematic: Implementing access control by writing code is a time
consuming task Enterprise may have one DB but many applications,
then access control is distributed and in many cases not consistent
Programmers must be security specialists
As a result: "70% of websites are at immediate risk of being hacked!" (http://www.acunetix.com)
Attack example: SQL Injection
strSQL= "SELECT Salary FROM Salary_Table WHERE Employee_No = 123 AND Salary_Date = '" + dateParam + "'"
SELECT Salary FROM Salary_Table WHERE Employee_No = 123 AND Salary_Date = '01/2007' OR '1' = '1'
• In many Web application the SQL sentence is structured as a string and the user’s parameter is concatenated to this string:
• But the intruder can type `01.2007' or '1' = '1` and retrieve the entire table:
SQL Injection
SQL uses single and double quotes to switch between data and code.Semi-colons separate SQL statementsExample query:
"UPDATE users SET prefcolor='red' WHERE uid='joe';"
This command could be sent from a web front-end to a database engine. The database engine then interprets the command
Dynamic SQL Generation
Web applications dynamically generate the necessary database commands by manipulating strings Example query generation:
$q = "UPDATE users SET prefcolor='$INPUT[color]' WHERE uid='$auth_user'";
Where the value of "$INPUT[color]" would be originating from the client web browser, through the web server. And where the value for "$auth_user" would have been stored on the server and verified through some authentication scheme
Client Web Browser
Forms in client browsers return values to the web server through either the POST or GET methods
"GET" results in a url with a "?" before the values of the form variables are specified:
http://www.example.com/script?color=redThe value of "$INPUT[color]" is set to "red" in the
script
"GET" urls are convenient to hack, but there isn't any significant difference in the security of either "GET" or "POST" methods because the data comes from the client web browser regardless and is under the control of the remote attacker
The SQL Table
Tables are used to store information in fields (columns) in relation to a key (e.g., "uid")What other fields could be of interest?CREATE TABLE users ( prefcolor varchar(20), uid VARCHAR(20) NOT NULL, privilege ENUM('normal', 'administrator'), PRIMARY KEY (uid));
A Malicious SQL Query
What if we could make the web server generate a query like:
"UPDATE users SET prefcolor='red', privilege='administrator'
WHERE uid='joe';"
Can we engineer the value of "color" given to the web server so it generates this query?
Note how code and data are mixed in the same channel
Better database interfaces provide separate channels
Malicious HTTP Request
http://www.example.com/script?color=red',privilege='administratorThe "color" input is then substituted to generate SQL:
$q = "UPDATE users SET prefcolor='$INPUT[color]' WHERE uid='$auth_user'";
It gives the query we wanted!
Results
Joe now has administrator privileges.
Adding Another SQL Query
Let's say Joe wants to run a completely different query:
"DELETE * FROM users"This will delete all entries in the table!
How can the value of "color" be engineered?
Malicious HTTP Request
http://www.example.com/script?color=red'%3Bdelete+from+users%3B
%3B is the url encoding for ";"
What happens when the "color" input is used to generate SQL?
$q = "UPDATE users SET prefcolor='$INPUT[color]' WHERE uid='$auth_user'";
Result
UPDATE users SET prefcolor='red';delete from users;WHERE uid='$auth_user'";The last line generates an error, but it's already too late; all entries have been deleted.The middle query could have been anything
FAQs
Couldn't the database have a separate account for "Joe" with only the privileges he needs (e.g., no delete privilege)?
In theory yes, but in practice the management of such accounts and privileges, and connecting to the database with the correct IDs, adds significant complexity
Most often a database account is created for the entire web application, with appropriate limitations (e.g., without privileges to create and drop tables)A good compromise is to create database accounts for
each class of user or class of operation, so:• if Joe is a regular user he wouldn't have delete privileges for the user table•Changing user preferences, as an operation type, doesn't require delete privileges
FAQs
Doesn't SSL protect against this sort of attack?No
But what if you authenticate users with a username/password over SSL? Then, if the user does SQL injection, the server admins will know who perpetrated the crime, right?
Not necessarily; only if you have sufficient auditlogging.
What to do?
Careful writing of Web applications including strong input validation
More reliance on Database security including the use of Views and Roles
Our method of Prevention and Detection using Parameterized Views
04/20/23Prof. Ehud Gudes Security
Ch 6 150
Summary
Three main security objectives: secrecy, integrity, availability.
DB admin is responsible for overall security. Designs security policy, maintains an audit trail,
or history of users’ accesses to DB.
Two main approaches to DBMS security: discretionary and mandatory access control. Discretionary control based on notion of
privileges. Mandatory control based on notion of security
classes.
Statistical DBs try to protect individual data by supporting only aggregate queries, but often, individual information can be inferred.
top related