1. Cosc 5/4765 Database security

2. Database Databases have moved from internal use only to externally accessible. –Organizations store vast quantities of data that normally is not “released” to the public Or private information that only the owner can access. –Salaries, medical, purchases, credit card information, etc. –At first glance protecting databases should be very easy. 10+ years of web accessible databases have proved otherwise.

3. Database Integrity Data corruption due to failure –A series are updates are being applied to the database and the database fails Loss of power, or other reasons. –Now the “data” is in a unknown state. How far in the updates did it get. Worse: Did it finish the update to current value?

4. Database Integrity (2)‏ Methods to correct the problem: –Regularly back up the database. Lost of maybe a day or several hours –For Banks and on-line businesses, this not normally acceptable –“Roll over” to a redundant Database Introduces concurrency control. Every change to the database must be replicated to the Backup.

5. Database Integrity (3)‏ Roll back and redo logs –Database keeps “restore points” –All updates are logged after a restore point –If there is a failure, then DB is returned a restore point and the “redo logs” run. –Roll back logs allow the database to “rewind” to a point removing transactions and returning original data.

6. In the beginning Before the web, we protected DB from “employees”. –People who had access to the DBs, especially employee databases, had limited access –They also knew a lot about the database to begin with. Normally structure and records. They had Username & passwords And used “Views” –Could only see/updates parts of the database.

7. Now We have to protect more generally. –Exaction of data: data stored in the DB. –Bounds: lower or upper bounds on a numerical value Such as salary –Negative result: Such as if the DB holds information on X, then a query resulting in no results can be useful. –Existence: the existence of data my be sensitive as well. Medical information for example –Probable value: guessing some information from other results of queries. –Statistical data: a statistical query can result very useful information Mean salary, sum of all salaries, count records, etc…

8. Access control We need access control for the following three groups –Users –Actions: SELECT, UPDATE, DELETE, INSERT, CREATE, DROP –Objects: tables, views, columns or attributes. –Example: A user1 grants access to table X for user2. User2 could also then grant access to User3. –Should User1 revoke access for user2, User3 would still have access. »Fixed with cascades, user1 revokes user2, which cascades and also revokes any access user2 has granted.

9. Access control (2)‏ Views –Allow users to only access certain tables, or only certain columns in a table. –Example: –Table: Name, social #, DOB, sex, salary A view could be setup so only Name and date of birth are viewable by most users. This can also prevent many of the statistical queries.

10. Access control (3)‏ Restriction sql commands –Basically access control always an admin set privileges on create, drop, insert, update, and select. –Also on count, sum, avg, max, and min Some DB allow this, not all of them. Some DB don’t have all of these implemented either. –Mysql for example.

11. Web and DBs Very common to have web pages linked to a database. –Provides the ability to “customize” the pages for users. Preferences, etc. –Hold information so they don’t have retype it every time. –Almost any website that sells items has a database. –On-line banking, and any pages that allows you pay your bills on-line.

12. SQL Injection attacks Amazing easy to overlook, when writing web pages. Same problem as Buffer Overflow attacks. –If the input is not checked or “sanitized”, then an injection attack is possible. We going to look at what are known as “blind attacks”

13. Example Page requests the users name –They type: Jim’  Note the single quote –The data added into a sql query –Select * from tablename where username=‘Jim’’;  Note the double single quote -Now when the sql statement is executed, it fails on a syntax error. -This is how crackers find out if your backend scripts are vulnerable. -Depending on the system, it will show you the sql statement and error, so you will also know the tablename as well.

14. Example (2)‏ Now the user enters the following: –anything’ OR ‘x’=‘x The sql queries will now look like: –Select * where username=‘anything’ OR ‘x’=‘x’; –Since x=x is always true, return EVERYTHING!

15. Example 2 User now enters –Whatever’; DROP TABLE tablename; -- The SQL query issued to the database Select * where user=‘Whatever’; DROP TABLE tablename; --’; –So we select whatever –Drop the table, if the table view is not read only –The -- allows us to dump the last ‘ and ignore it.

16. Other approaches If it turns out to be Microsoft SQL server –Use the xp_cmdshell Allows arbitrary command execution. –Normally only allowed by the administrative accounts, but can be granted to “lesser” users. –If you can use it, then you can not only comprise the database, but the entire machine as well.

17. Other approaches (2)‏ Map the database structure –Once you can access the data and can run “other” queries, it’s easy to map for more information –Show tables; in mysql –Or x’ and salary IS NULL; -- If it doesn’t return a syntax error, you know there is a field called salary. NOTE and is better in this case, since we only want to know if a field exists! –OR x’ and 1=(select * from tablename); -- OR x’ and tablename.field; --

18. Protection Sanitize the input –MYSQL function mysql_real_escape_string()‏ –Perl: $dbh->quote($input)‏ –Most languages has some time of sanitize function. You could miss something, if you do it on your own.

19. Protection (2)‏ Bound parameters –Use the prepare statement –In perl looks like this: (php is similar)‏ $sth = $dbh->prepare(“select * from table where x= ?;”); $sth = execute($x); –Now this is nothing to “subvert”, because the ? takes only data.

20. Protection (3)‏ Limit access –An app that need to update the database should only have access to the fields it needs and nothing else –Have a read-only account for everything else. Used stored procedures –Don’t allow dynamically queries, otherwise is no protection.

21. Protection (4)‏ Configure error reporting –Make sure that it doesn’t report errors on the production web server. Prevents “hackers” from gathering information quickly. Isolate the webserver

22. Q A &