Ahmed Khaled Hossam Alaa Mariam Badr

Bank Accounts Credit Cards Information Applications users Licenses and certificates

Identity thefts Systems hacking Illegal transactions Most web and network applications are

vulnerable

Database itself Application Programs Database Management Server (DBMS) Network connected to Database Web Server connected to Database

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

To 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

Encrypting at Application Layer Must do it at multiple locations from within app.

Data can only be used from within application

Encrypting at File System/Operating System

Layer less flexible. Requires you to encrypt everything. Performance degrades Weak for handling Disk Theft problem.

Encrypting within Database Usually, most practical option

Application Developers use a cryptographic library to encrypt such as Java Cryptographic Extensions (JCE) – set of APIs in the java.security and java.crypto packages

SQL Server 2005 you can access Windows CryptoAPI through DB_ENCRYPT and

DB_DECRYPT within T-SQL (similar to PL/SQL)

Can use DES, Triple DES and AES (symmetric keys)

In ORACLE, you can access DBMS_OBFUSCATION_TOOLKIT package that

implements DES and Triple DES

DB Encryption can be divided into Data-in-transit and Data-at-rest

Encryption is useful as a last layer of defense (defense in depth). Should never be used as an alternative solution

Encryption should be used only when needed

Key Management is Key

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

All information must be encrypted to prevent eavesdropping Public/private key encryption widely used

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

One mechanism to allow specific users access only to required data

Password

Smartcards

Central authentication systems Allow users to be authenticated centrally

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

Different authorizations for different users

Ensure that only authenticated users can

access the system And can access (read/update) only

data/interfaces that they are authorized to access

Application authenticates/authorizes users Application itself authenticates itself to

database

Database password

Database Application Program

Applications are the biggest source of insecurity

Poor coding of application may allow unauthorized access

The applications may be very big.

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 +"‘ “

select balance

from account

where account_number =‘123’

What if I entered 022572636‘ or 1=1

Now its select balance

from account

where account_number =‘ 022572636‘

or 1=1

http://www.example.com/index.php?id=123

Just add ‘

http://www.example.com/index.php?id=123’

To prevent SQL injection attacks use prepared statements (instead of creating query strings from input parameters)

• use stored procedures

• use a function that removes special characters (such as quotes) from strings

Most security schemes address outsider attack Have password to DB? Okay, you can update

anything

Bypassing all security levels ▪ The more people have access, the more danger

The application program has the DB password Great deal of trust in people who manage databases

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/

SQL Injection http://www.cgisecurity.com/development/sql.shtml

9 ways to hack a web app http://developers.sun.com/learning/javaoneonline/2005/webtier/TS-5935.pdf

Related research papers 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