Database and Application Security

Database and Application Security, Nov 2006

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

Database and Application Security, Nov 2006

Importance of Data

Bank/Demat accounts Credit card, Salary, Income tax data University admissions, marks/grades Land records, licenses Data = crown jewels for organizations

Database and Application Security, Nov 2006

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

Database and Application Security, Nov 2006

Levels of Data Security

Human level: Corrupt/careless User Network/User Interface Database application program Database system Operating System Physical level

Database and Application Security, Nov 2006

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 and Application Security, Nov 2006 6

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 and Application Security, Nov 2006

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 and Application Security, Nov 2006

Network Security
All information must be encrypted to prevent eavesdropping

Public/private key encryption widely used Handled by secure http - https:// E.g. someone impersonates seller or bank/credit card company and fools buyer into revealing information
Encrypting messages alone doesnt solve this problem More on this in next slide

Must prevent person-in-the-middle attacks

Database and Application Security, Nov 2006

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., sites 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 and Application Security, Nov 2006 10

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 and Application Security, Nov 2006

11

Database vs. Application

Application authenticates/authorizes users Application itself authenticates itself to database

Database password

Application Program
Database and Application Security, Nov 2006

Database

12

User Authentication
Password

Most users abuse passwords. For e.g.

Easy to guess password Share passwords with others

Smartcards

Need smartcard + a PIN or password

Mosaab Daoud

Database and Application Security, Nov 2006

13

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 and Application Security, Nov 2006 14

Overview
Levels of security Authorization in databases Application Vulnerabilities References

Database and Application Security, Nov 2006

15

Authorization
Different authorizations for different users

Accounts clerk vs. Accounts manager vs. End users

Database and Application Security, Nov 2006

16

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 and Application Security, Nov 2006

17

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 and Application Security, Nov 2006 18

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 and Application Security, Nov 2006

19

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 and Application Security, Nov 2006 20

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 users 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 and Application Security, Nov 2006

21

Privacy
Aggregate information about private information can be very valuable

E.g. identification of epidemics, mining for patterns (e.g. disease causes) etc. 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!

Privacy preserving data release

Correlate anonymized data with (say) electoral data with same information

Recent problems at America Online

identified in several cases

Released search history, apparently anonymized, but users could be easily

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 and Application Security, Nov 2006

22

Overview
Levels of security Authorization in databases Application Vulnerabilities References

Database and Application Security, Nov 2006

23

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 and Application Security, Nov 2006 24

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 and Application Security, Nov 2006 25

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 and Application Security, Nov 2006

26

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 and Application Security, Nov 2006 27

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 and Application Security, Nov 2006

28

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 and Application Security, Nov 2006

29

Protecting from Users

Multi-person approval:

Standard practice in banks, accounts departments Encoded as part of application workflow External paper trail Smart cards

Strong authentication of users

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 and Application Security, Nov 2006 30

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:
only a few system administrators

Dont give database password to development team keep password in a configuration file on live server, accessible to

Ongoing research on trusted applications

E.g. OS computes checksum on application to verify corruption Allows file-system access only to trusted applications
31

Database and Application Security, Nov 2006

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 Encrypt entire database (and/or file system) Supported, e.g. in SQL Server 2005 Authentication (password/smart card) when database is started up
Database and Application Security, Nov 2006 32

What if a laptop with critical data is lost?

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 cant 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 and Application Security, Nov 2006 33

Information Leakage
So you thought only the query result matters?

Database and Application Security, Nov 2006

34

Information Leakage via UDFs

Auth view myemployee: only those employee whose dept_id is in A1 myudf(E.salary) Query:
select * from employee where myudf(salary)

myudf(E.salary)
myemployees

myudf(E.salary)
employees

A1

employees A1

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 and Application Security, Nov 2006 35

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 36

Database and Application Security, Nov 2006

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)
employees

A1

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 and Application Security, Nov 2006

37

Overview
Levels of security Authorization in databases Application Vulnerabilities Summary

Database and Application Security, Nov 2006

38

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

Database and Application Security, Nov 2006

39

Acknowledgments
Pictures in this talk taken from various web sources!

Database and Application Security, Nov 2006

40

References
(Shameless advertisement!) Chapter 8 of Database System Concepts 5th Edition, Silberschatz, Korth and Sudarshan, McGraw-Hill The Open Web Application Security Project

http://www.owasp.org

Web application security scanners

e.g. WebInspect (SPI Dynamics) http://www.windowsecurity.com/software/Web-Application-Security/ http://www.cgisecurity.com/development/sql.shtml http://developers.sun.com/learning/javaoneonline/2005/webtier/TS-5935.pdf Kabra, Ramamurthy and Sudarshan, Redundancy and Information Leakage in Fine-Grained Access Control, SIGMOD 2006 Rizvi, Mendelzon, Sudarshan and Roy, Extending Query Rewriting Techniques for Fine-Grained Access Control, SIGMOD 2004

SQL Injection

9 ways to hack a web app

Related research papers

Database and Application Security, Nov 2006

41

Extra Slides

Database and Application Security, Nov 2006

42

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 and Application Security, Nov 2006 43

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 and Application Security, Nov 2006 44

Privileges in SQL
select: allows read access to relation,or the ability to query using the view

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

Example: grant users U1, U2, and U3 select authorization on the branch relation:

Database and Application Security, Nov 2006

45

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 and Application Security, Nov 2006 46

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 and Application Security, Nov 2006

47

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: With restrict, the revoke command fails if cascading revokes are required.
48

revoke select on branch from U1, U2, U3 restrict

Database and Application Security, Nov 2006

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 and Application Security, Nov 2006 49

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 buyers bank through physical/electronic

check payment

Several secure payment protocols

E.g. Secure Electronic Transaction (SET)

Database and Application Security, Nov 2006

50