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 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 Application Database 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 5 th 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