Database and Application Security

Database Security
 Database Security
• Database Security - protection from malicious
attempts to steal (view) or modify data.

Database Security
 Importance of Data

• Bank/Demat accounts
• Credit card, Salary, Income tax data
• University admissions, marks/grades
• Land records, licenses
• Data = crown jewels for organizations
• Recent headlines:
– Personal information of millions of credit card users stolen
• Laws on privacy in the US
• Theft of US data in India
– Criminal gangs get into identity theft
– Earlier this year in Mumbai
• Hackers steal credit card data using card reader and make fraudulent purchases
• Hacker creates fake Web site to phish for credit card information
– Auto-rickshaw license fraud in New Delhi

Database Security
 Identity Theft

• Pretend to be someone else and get credit cards/loans in their

name
– Identification based on “private” information that is not hard to obtain
online
• More lucrative than blue-collar crime,
– harder to catch criminals
• Hurts victims even more than regular theft
– Onus goes on innocent people to prove they didn’t get loans or make
credit card payment
– Credit history gets spoilt, making it harder to get future loans
– And you may have been robbed without ever knowing about it.
• Increasing risk in India
– PAN numbers, names available online

Database Security
 What me worry?
• “Bad things only happen to other people.”??
– SQL/Slammer
• Attacked SQLServer, brought networks down all over the
world (including IITB)
• Luckily no data lost/stolen
– Flaw in registration script at database security
workshop at IIT Bombay
• Careless coding exposed database password to outside world
• Most Web applications vulnerable to SQL
injection attacks

Database Security
 Overview
Levels of data security
Authorization in databases
Application Vulnerabilities
Summary and References

Database Security
 Levels of Data Security
• Human level: Corrupt/careless User
• Network/User Interface
• Database application program
• Database system
• Operating System
• Physical level

Database Security
 Physical/OS Security
• Physical level
– Traditional lock-and-key security
– Protection from floods, fire, etc.
• E.g. WTC (9/11), fires in IITM, WWW conf website, etc.
– Protection from administrator error
• E.g. delete critical files
– Solution
• Remote backup for disaster recovery
• Plus archival backup (e.g. DVDs/tapes)
• Operating system level
– Protection from virus/worm attacks critical
Database Security
 Database Encryption
• E.g. What if a laptop/disk/USB key with critical data is lost?
• Partial solution: encrypt the database at storage level,
transparent to application
• Whole database/file/relation
– Unit of encryption: page
• Column encryption
– Main issue: key management
• E.g. user provides decryption key (password) when database is started up
– Supported by many database systems
• Standard practice now to encrypt credit card information, and other
sensitive information

Database Security
 Security (Cont.)

• Network level: must use encryption to

prevent
– Eavesdropping: unauthorized reading of
messages
– Masquerading:
• pretending to be an authorized
user or legitimate site, or
• sending messages supposedly
from authorized users

Database Security
 Network Security
• All information must be encrypted to prevent
eavesdropping
– Public/private key encryption widely used
– Handled by secure http - https://
• Must prevent person-in-the-middle attacks
– E.g. someone impersonates seller or bank/credit card
company and fools buyer into revealing information
• Encrypting messages alone doesn’t solve this problem
• More on this in next slide

Database Security
 Site Authentication
• Digital certificates are used in https to prevent
impersonation/man-in-the middle attack
– Certification agency creates digital certificate by
encrypting, e.g., site’s public key using its own private
key
• Verifies site identity by external means first!
– Site sends certificate to buyer
– Customer uses public key of certification agency to
decrypt certificate and find sites public key
• Man-in-the-middle cannot send fake public key
– Sites public key used for setting up secure
communication
Database Security
Security at the Database/Application
Program
• Authentication and
authorization
mechanisms to allow
specific users access
only to required data
• Authentication: who are
you? Prove it!
• Authorization: what
you are allowed to do

Database Security
 Database vs. Application
• Application authenticates/authorizes users
• Application itself authenticates itself to
database
– Database password

Application Database
Program

Database Security
 User Authentication

• Password
– Most users abuse passwords. For e.g.
• Easy to guess password
• Share passwords with others
• Smartcards
– Need smartcard Bill Gates
– + a PIN or password

Database Security
 User Authentication
• Central authentication systems allow users to be
authenticated centrally
– LDAP or MS Active Directory often used for central
authentication and user management in organizations
• Single sign-on: authenticate once, and access
multiple applications without fresh authentication
– Microsoft passport, PubCookie etc
– Avoids plethora of passwords
– Password only given to central site, not to applications

Database Security
 Overview
Levels of security
Authorization in databases
Application Vulnerabilities
References

Database Security
 Authorization

• Different authorizations
for different users
– Accounts clerk vs.
– Accounts manager vs.
– End users

Database Security
 Database/Application Security
• Ensure that only authenticated users can
access the system
• And can access (read/update) only
data/interfaces that they are authorized to
access

Database Security
Limitations of SQL Authorization
• SQL does not support authorization at a tuple
level
– E.g. we cannot restrict students to see only (the tuples
storing) their own grades
• Web applications are dominant users of
databases
– Application end users don't have database user ids,
they are all mapped to the same database user id
– Database access control provides only a very coarse
application-level access control

Database Security
 Access Control in Application Layer
• Applications authenticate end users and decide what
interfaces to give to whom
– Screen level authorization: which users are allowed to
access which screens
– Parameter checking: users only authorized to execute
forms with certain parameter values
• E.g. CSE faculty can see only CSE grades

Database Security
 Access Control in Application Layer
• Authorization in application layer vs. database layer
– Benefits
• fine grained authorizations, such as to individual tuples, can be
implemented by the application.
• authorizations based on business logic easier to code at
application level
– Drawback:
• Authorization must be done in application code, and may be
dispersed all over an application
• Hard to check or modify authorizations
• Checking for absence of authorization loopholes becomes very
difficult since it requires reading large amounts of application code
– Need a good via-media

Database Security
 Oracle Virtual Private Database
• Oracle VPD
– Provides ability to automatically add predicates to where clause of
SQL queries, to enforce fine-grained access control
• E.g. select * from grades becomes
select * from grades where rollno=userId()
– Mechanism:
• DBA creates an authorization function. When invoked with a relation
name and mode of access, function returns a string containing
authorization predicate
• Strings for each relation and-ed together and added to user’s query
– Application domain: hosted applications, where applications of
different organizations share a database (down to relation level)
• Added predicates ensures each organization sees only its own data

Database Security
 Privacy
• Aggregate information about private information can be very valuable
– E.g. identification of epidemics, mining for patterns (e.g. disease causes) etc.
• Privacy preserving data release
– E.g. in US, many organizations released “anonymized” medical data, with
names removed, but zipcode (= pincode), sex and date of birth retained
• Turns out above (zipcode,sex,date of birth) uniquely identify most people!
– Correlate anonymized data with (say) electoral data with same information
– Recent problems at America Online
• Released search history, apparently anonymized, but users could be easily
identified in several cases
– Several top officials were fired
– Earlier problems revealed medical history of
Massachusetts state governer.
• Not yet a criminal issue, but lawsuits have happened
• Conflict with Right To Information Act
– Many issues still to be resolved

Database Security
 Overview
Levels of security
Authorization in databases
Application Vulnerabilities
References

Database Security
 Application Security
• Applications are often the biggest source of
insecurity
– Poor coding of application may allow
unauthorized access
– Application code may be very big, easy to make
mistakes and leave security holes
– Very large surface area
• Used in fewer places
– Some security by obfuscation
– Lots of holes due to poor/hasty programming

Database Security
 OWASP Top 10 Web Security
Vulnerabilities
1. Unvalidated input
2. Broken access control
3. Broken account/session management
4. Cross-site scripting (XSS) flaws
5. Buffer overflows
6. (SQL) Injection flaws
7. Improper error handling
8. Insecure storage
9. Denial-of-service
10. Insecure configuration management
Database Security
 SQL Injection
• E.g. application takes accnt_number as input from user and
creates an SQL query as follows:
– string query = "select balance from account where account_number
=‘" + accnt_number +"‘"
– Suppose instead of a valid account number, user types in
• ‘; delete from r;
then (oops!) the query becomes
select balance from account where account_number =‘ ‘; delete from r;
• Hackers can probe for SQL injection vulnerability by typing,
e.g. ‘*** in an input box
– Tools can probe for vulnerability
– Error messages can reveal information to hacker

Database Security
 Preventing SQL Injection
• To prevent SQL injection attacks use prepared
statements (instead of creating query strings from
input parameters)
– PreparedStatement pstmt= conn.prepareStatement(
"select balance from account where account_number =?“);
pstmt.setString(1,accnt_number);
pstmt.execute();
• (assume that conn is an already open connection to the database)
• Alternatives:
– use stored procedures
– use a function that removes special characters (such as
quotes) from strings

Database Security
 Passwords in Scripts
• E.g.: file1.jsp (or java or other source file) located in publicly
accessible area of web server
– Intruder looks for http://<urlpath>/file1.jsp~
• or .jsp.swp, etc
– If jsp has database userid/password in clear text, big trouble
• Happened at IITB
• Morals
– Never store scripts (java/jsp) in an area accessible to http
– Never store passwords in scripts, keep them in config files
– Never store config files in any web-accessible areas
– Restrict database access to only trusted clients
• At port level, or using database provided functionality

Database Security
 Outsider vs. Insider Attack

• Most security schemes address outsider attack

• Have password to database? Can update anything
– Bypassing all application level security measures
• More people with access  more danger
• Application program has database password
• Great deal of trust in people who manage
databases
– Risk of compromise greater with value of data
– Happened with auto-rickshaw registration in New Delhi

Database Security
 Protecting from Users
• Multi-person approval:
– Standard practice in banks, accounts departments
– Encoded as part of application workflow
– External paper trail
• Strong authentication of users
– Smart cards
• Careful allocation of authorizations on a need to use
basis
– Practical problem: absence of a user should not prevent
organization from functioning
– Many organizations therefore grant overly generous
authorizations

Database Security
 Protecting from
Programmers/DBA
• Have password to database, can update anything!
– Digital signatures by end users can help in some situations
• E.g. low update rate data such as land records, birth/death data
• Application program has database password
– Seize control of the application program  can do anything to
the database
– Solution:
• Don’t give database password to development team
• keep password in a configuration file on live server, accessible to
only a few system administrators
• Ongoing research on trusted applications
– E.g. OS computes checksum on application to verify corruption
– Allows file-system access only to trusted applications

Database Security
 Protection from admin/super-users
• Operating system administrators (also known
as super-users) can do anything they want to
the database.
– Small number of trusted administrators
• What if a laptop with critical data is lost?
– Encrypt entire database (and/or file system)
– Supported, e.g. in SQL Server 2005
– Authentication (password/smart card) when
database is started up
Database Security
 Detecting Corruption
• Audit trails: record of all (update) activity on the database:
who did what, when
– Application level audit trail
• Helps detect fraudulent activities by users
• Independent audit section to check all updates
• BUT: DBAs can bypass this level
– E.g. audit trail apparently deleted in New Delhi auto-rickshaw license
case by malicious users with DBA access
– Database level audit trail
• Database needs to ensure these can’t be turned off, and turned on again
after doing damage
• Supported by most commercial database systems
• But required DBAs with knowledge of application to monitor at this level
– Keep archival copies and cross check periodically

Database Security
 Information Leakage

So you thought only the query result

matters?

Database Security
 Information Leakage via UDFs
• Auth view myemployee: only those employee whose
dept_id is in A1 σmyudf(E.salary)
Query:
σmyudf(E.salary) σmyudf(E.salary) A1
select * from employee
where myudf(salary)
myemployees employees A1 employees

• Final query plan is not safe

– UDF may be pushed down in plan, and executed on
unauthorized intermediate result
– As a side-effect, UDF may expose values passed to it [Litchfield]
– Can be partly solved using sandboxing

Database Security
 Other channels of information
leakage
• Exceptions, Error Messages
– Query: select * from employee
where 1/(salary-100K) = 0.23
– Query plan: Selection condition in query gets pushed below
authorization semi-join
– Divide by zero exception if salary = 100K
– Reveals that employee has salary = 100K

• Timing Analysis
– Sub-query can perform an expensive computation only if certain
tuples are present in its input
• To prevent leakage, treat all channels as unsafe operations
Database Security
 Preventing Information Leakage via
UDFs
• UDF on Top: Keep UDFs at the top of query plan
– Definitely safe, no information leakage
– Better plans possible if UDF is selective
σmyudf(E.salary)

σmyudf(E.salary) A1

employees employees A1

• Optimal Safe plan

– When is a plan safe?
– How to search for optimal safe plan?
– For details, see: Kabra et al., SIGMOD 2006

Database Security
 Overview
Levels of security
Authorization in databases
Application Vulnerabilities
Summary

Database Security
 Summary
• Data security is critical
• Requires security at different levels
• Several technical solutions
• But human training is essential

Database Security
 Authorization
Forms of authorization on (parts of) the database:
• Read authorization - allows reading, but
not modification of data.
• Insert authorization - allows insertion of new data,
but not modification of existing data.
• Update authorization - allows modification, but not
deletion of data.
• Delete authorization - allows deletion of data

Database Security
 Security Specification in SQL
• The grant statement is used to confer authorization
grant <privilege list>
on <relation name or view name> to <user list>
• <user list> is:
– a user-id
– public, which allows all valid users the privilege granted
– A role (more on this later)
• Granting a privilege on a view does not imply granting any
privileges on the underlying relations.
• The grantor of the privilege must already hold the privilege on
the specified item (or be the database administrator).

Database Security
 Privileges in SQL
• select: allows read access to relation,or the ability to query using the view
– Example: grant users U1, U2, and U3 select authorization on the branch
relation:
grant select on branch to U1, U2, U3
• insert: the ability to insert tuples
• update: the ability to update using the SQL update statement
• delete: the ability to delete tuples.
• references: ability to declare foreign keys when creating relations.
• usage: In SQL-92; authorizes a user to use a specified domain
• all privileges: used as a short form for all the allowable privileges

Database Security
Privilege To Grant Privileges
• with grant option: allows a user who is
granted a privilege to pass the privilege on
to other users.
– Example:
grant select on branch to U1 with grant option
gives U1 the select privileges on branch and allows U1
to grant this
privilege to others

Database Security
 Roles
• Roles permit common privileges for a class of users can be
specified just once by creating a corresponding “role”
• Privileges can be granted to or revoked from roles
• Roles can be assigned to users, and even to other roles
• SQL:1999 supports roles
create role teller
create role manager

grant select on branch to teller

grant update (balance) on account to teller
grant all privileges on account to manager
grant teller to manager
grant teller to alice, bob
grant manager to avi

Database Security
 Revoking Authorization in SQL
• The revoke statement is used to revoke authorization.
revoke<privilege list>
on <relation name or view name> from <user list> [restrict|cascade]
• Example:
revoke select on branch from U1, U2, U3 cascade
• Revocation of a privilege from a user may cause other users
also to lose that privilege; referred to as cascading of the
revoke.
• We can prevent cascading by specifying restrict:
revoke select on branch from U1, U2, U3 restrict
With restrict, the revoke command fails if cascading revokes
are required.

Database Security
 Revoking Authorization in SQL (Cont.)
• <privilege-list> may be all to revoke all privileges the
revokee may hold.
• If <revokee-list> includes public all users lose the
privilege except those granted it explicitly.
• If the same privilege was granted twice to the same
user by different grantees, the user may retain the
privilege after the revocation.
• All privileges that depend on the privilege being
revoked are also revoked.

Database Security
 Secure Payment
• Three-way communication between seller, buyer and
credit-card company to make payment
– Credit card company credits amount to seller
– Credit card company consolidates all payments from a
buyer and collects them together
• E.g. via buyer’s bank through physical/electronic
check payment
• Several secure payment protocols
– E.g. Secure Electronic Transaction (SET)

Database Security