notes/docs/lectures/security/14_database_security.md

Database Security

• OS security is quite data oriented
  • Usually isn’t concerned with file contents
• Database security is concerned with information
  • Can look at content
  • Can often be inferred even when stringent access policies are in place

SQL Security

• Three entities
  1. Users
  2. Actions
  3. Objects
• Users invoke actions on objects
• Newly created objects are owned by the creator
• Privileges can be granted
  • Granter, grantee, object, action, grant-able

View-Based Security

• Views are derived relations

CREATE VIEW pharm_order AS
SELECT DrugDB.Name, SUM(Total)
	FROM Patients, DrugDB
	GROUP BY (DrugDB.Name)
WITH CHECK OPTION

This view abstracts the drugs away from the patients, so that the admin can order the correct amount of drugs without violating doctor-patient privilege

Why use Views

• Views are a flexible way of creating policies closer to application requirements
• Views can implement controlled invocation
• Data can easily be reclassified
  • Deleting views instead of changing permissions is much easier
  • Never have a situation where an application has access to raw data

Why Not?

• INSERT / UPDATE actions depends on the CHECK options, else might be blind inserts
  • This is where someone can’t access the data, but can update it
• Completeness and consistency are not achieved automatically
• Can quickly become very inefficient
  • Views can be cached, if not can become very slow

Statistical Databases

• Where access to data is restricted access to aggregates is permitted
  • This means averages, sums can be looked at
  • However, individual records cannot be viewed

Inference

• Since individual items are sensitive, we cannot permit access
• Statistical queries are useful, but by definition refer to data
• Some queries can reveal information on the underlying data - Covert Channel

Example: Salaries

• S = The sum of all salaries in the department
• T = The sum of all salaries for the department except those who have “Department Head” as “Position”
• Boss’ salary = S - T

Solution: Do not allow sets of just one

• S = Sum of all salaries
• T = Sum of all salaries of women, and anyone whose first name is Albert
• U = The sum of all men’s department salaries
• Albert’s salary = T + U - S

Solution: Do not allow conditions that refer to just one

• S = Sum of all salaries
  • Number of department heads named Albert not allowed
• T = sum of all salaries for those named Albert
• U = The sum of all salaries for department heads
• V = The sum of all salaries for those who are not department heads, or named Albert

Salary = V + T + U - S

Further Defences

• Data swapping - swap records but keep stats the same
• Noise addition - alter aggregate output (a little bit)
• Table Splitting - Separate data completely
• User Tracking - Log queries

SQL Injections

• It’s common for user input to be read and then used within an SQL query
• Unexpected user input can completely rewrite the query
• Nears striking similarities to XSS attack
• An application or website is vulnerable to an injection if it doesn’t filter SQL control characters:
  • ‘ Represents the beginning or end of a string
  • ; represents end of a command
  • /*...*/ - comments
  • – - comment a line
• Login pages will request hashes from the database

Blind SQL Injection

• Most servers won’t directly output SQL errors to the screen
• A blind SQL injection performs database analysis without any actual output

Fingerprinting the DB

• Some commands are specific to an individual DBMS

http://shop.com/items.php?id=2; waitfor delay '0:0:10'--

This will work on MS SQL but not MySQL

• Once you know the DB, access the system tables

Union

• UNION appends (not joins) two tables together
  • They must have the same number of columns

Second Order SQL Injection

• Entry points may be checked for speical characters, but internal functions?
• Store the exploit in one pass, then have it executed later