Mariam Badr Bank Accounts Credit Cards Information Applications - - PowerPoint PPT Presentation

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

• nly 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‘

• r 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