M.P. Johnson, DBMS, Stern/NYU, Spring C : Database Management Systems Lecture #19 M.P. Johnson Stern School of Business, NYU Spring, 2008

M.P. Johnson, DBMS, Stern/NYU, Spring Agenda Security  Web issues Transactions RAID? Stored procedures? Implementation?

M.P. Johnson, DBMS, Stern/NYU, Spring Review: hashes Hash tables Hash functions Secure hash functions Families of secure hash functions

M.P. Johnson, DBMS, Stern/NYU, Spring New topic: Security on the web Authentication  If the website user wants to pay with George’s credit card, how do we know it’s George?  If the website asks George for his credit card, how does he know it’s our site? Maybe it’s a phishing site… Secrecy  When George enters his credit card, will an eavesdropper be able to see it? Protecting against user input  Is it safe to run SQL queries based on user input?

M.P. Johnson, DBMS, Stern/NYU, Spring Security on the web Obvious soln: passwords  What’s the problem? Slightly less obvious soln: passwords + encryption Traditional encryption: “symmetric” / “private key”  DES, AES – fast – solves problem? “Newer” kind: “asymmetric” / “public key”  Public key is published somewhere  Private key is top secret  RSA – slow – solves problem?

M.P. Johnson, DBMS, Stern/NYU, Spring Hybrid protocols (SSH,SSL/HTTPS, etc.) Neither private- nor public-key alone suffices  They each only solve half of each problem But together they solve almost everything Recurring strategy:  We do private-key crypto  Where do we get the key?  You send it (encrypted) to me

M.P. Johnson, DBMS, Stern/NYU, Spring SSH-like authentication (intuition) sales has a public-key When you connect to sales, 1. You pick a random number 2. Encrypt it (with the cert) and send it to them 3. They decrypt it (with their private key) 4. Now, they send it back to you  Since they decrypted it, you trust they’re sales

M.P. Johnson, DBMS, Stern/NYU, Spring HTTPS-like authentication (intuition) Amazon has a public-key certificate  Encrypted with, say, Verisign’s private key When you log in to Amazon, 1. They send you the their Verisign-encrypted cert 2. You decrypt it (with Verisign’s public key), and check that it’s a cert for amazon.com  Since the decrypt worked, the cert must have been encrypted by Verisign  So this must really be Amazon

M.P. Johnson, DBMS, Stern/NYU, Spring Authentication on the web Now George trusts that it’s really Amazon  Assuming Amazon’s private key is secure  And excluding man-in-the-middle… But: What if, say, Dick guessed George’s password?  Another way: What if George claims Dick guessed his password? Soln: same process, but in reverse  But now you need to get your own cert…

M.P. Johnson, DBMS, Stern/NYU, Spring Hybrid protocol for encryption Amazon just sent you their public-key cert When you log in to Amazon, 1. You pick a random number (“session key”) 2. You encrypt it (with the cert) and send it to them 3. They decrypt it (with their private key)  Now, you both share a secret key  can now encrypt passwords, credit cards, etc.

M.P. Johnson, DBMS, Stern/NYU, Spring Query-related: Injection attacks Here’s a situation: Prompt for user/pass Do lookup: If found, user gets in  test.user table in MySQL  / txt  / txt Modulo the no hashing, is this a good idea? SELECT * FROM users WHERE user=u AND password=p; SELECT * FROM users WHERE user=u AND password=p;

M.P. Johnson, DBMS, Stern/NYU, Spring Injection attacks We expect to get input of something like:  user: mjohnson  pass: topsecret  SELECT * FROM users WHERE user = u AND password = p; SELECT * FROM users WHERE user = u AND password = p; SELECT * FROM users WHERE user= 'mjohnson' AND password = 'topsecret'; SELECT * FROM users WHERE user= 'mjohnson' AND password = 'topsecret';

M.P. Johnson, DBMS, Stern/NYU, Spring Injection attacks – MySQL/Perl/PHP Consider another input:  user: ' OR 1=1 OR user = '  pass: ' OR 1=1 OR pass = '  SELECT * FROM users WHERE user = u AND password = p; SELECT * FROM users WHERE user = u AND password = p; SELECT * FROM users WHERE user = ' ' OR 1=1 OR user = ' ' AND password = ' ' OR 1=1 OR pass = ' '; SELECT * FROM users WHERE user = ' ' OR 1=1 OR user = ' ' AND password = ' ' OR 1=1 OR pass = ' '; SELECT * FROM users WHERE user = '' OR 1=1 OR user = '' AND password = '' OR 1=1 OR pass = ''; SELECT * FROM users WHERE user = '' OR 1=1 OR user = '' AND password = '' OR 1=1 OR pass = '';

M.P. Johnson, DBMS, Stern/NYU, Spring Injection attacks – MySQL/Perl/PHP Consider this one:  user: your-boss ' OR 1=1 #  pass: abc  SELECT * FROM users WHERE user = u AND password = p; SELECT * FROM users WHERE user = u AND password = p; SELECT * FROM users WHERE user = 'your-boss ' OR 1=1 #' AND password = 'abc'; SELECT * FROM users WHERE user = 'your-boss ' OR 1=1 #' AND password = 'abc'; SELECT * FROM users WHERE user = 'your-boss' OR 1=1 #' AND password = 'abc'; SELECT * FROM users WHERE user = 'your-boss' OR 1=1 #' AND password = 'abc';

M.P. Johnson, DBMS, Stern/NYU, Spring Injection attacks – MySQL/Perl/PHP Consider another input:  user: your-boss  pass: ' OR 1=1 OR pass = '  SELECT * FROM users WHERE user = u AND password = p; SELECT * FROM users WHERE user = u AND password = p; SELECT * FROM users WHERE user = 'your-boss' AND password = ' ' OR 1=1 OR pass = ' '; SELECT * FROM users WHERE user = 'your-boss' AND password = ' ' OR 1=1 OR pass = ' '; SELECT * FROM users WHERE user = 'your-boss' AND password = '' OR 1=1 OR pass = ''; SELECT * FROM users WHERE user = 'your-boss' AND password = '' OR 1=1 OR pass = '';

M.P. Johnson, DBMS, Stern/NYU, Spring Multi-command inj. attacks (other DBs) Consider another input:  user: ' ; DELETE FROM users WHERE user = ' abc ' ; SELECT FROM users WHERE password = '  pass: abc  SELECT * FROM users WHERE user = u AND password = p; SELECT * FROM users WHERE user = u AND password = p; SELECT * FROM users WHERE user = ' ' ; DELETE FROM users WHERE user = 'abc'; SELECT FROM users WHERE password = ' ' AND password = 'abc'; SELECT * FROM users WHERE user = ' ' ; DELETE FROM users WHERE user = 'abc'; SELECT FROM users WHERE password = ' ' AND password = 'abc'; SELECT * FROM users WHERE user = ''; DELETE FROM users WHERE user = 'abc'; SELECT FROM users WHERE password = '' AND password = 'abc'; SELECT * FROM users WHERE user = ''; DELETE FROM users WHERE user = 'abc'; SELECT FROM users WHERE password = '' AND password = 'abc';

M.P. Johnson, DBMS, Stern/NYU, Spring Consider another input:  user: ' ; DROP TABLE users; SELECT FROM users WHERE password = '  pass: abc  SELECT * FROM users WHERE user = u AND password = p; SELECT * FROM users WHERE user = u AND password = p; SELECT * FROM users WHERE user = ' ' ; DROP TABLE users; SELECT FROM users WHERE password = ' ' AND password = 'abc'; SELECT * FROM users WHERE user = ' ' ; DROP TABLE users; SELECT FROM users WHERE password = ' ' AND password = 'abc'; SELECT * FROM users WHERE user = ''; DROP TABLE users; SELECT FROM users WHERE password = '' AND password = 'abc'; SELECT * FROM users WHERE user = ''; DROP TABLE users; SELECT FROM users WHERE password = '' AND password = 'abc'; Multi-command inj. attacks (other DBs)

M.P. Johnson, DBMS, Stern/NYU, Spring Consider another input:  user: ' ; SHUTDOWN WITH NOWAIT; SELECT FROM users WHERE password = '  pass: abc  SELECT * FROM users WHERE user = u AND password = p; SELECT * FROM users WHERE user = u AND password = p; SELECT * FROM users WHERE user = ' ' ; SHUTDOWN WITH NOWAIT; SELECT FROM users WHERE password = ' ' AND password = 'abc'; SELECT * FROM users WHERE user = ' ' ; SHUTDOWN WITH NOWAIT; SELECT FROM users WHERE password = ' ' AND password = 'abc'; SELECT * FROM users WHERE user = ''; SHUTDOWN WITH NOWAIT; SELECT FROM users WHERE password = '' AND password = 'abc'; SELECT * FROM users WHERE user = ''; SHUTDOWN WITH NOWAIT; SELECT FROM users WHERE password = '' AND password = 'abc'; Multi-command inj. attacks (other DBs)

M.P. Johnson, DBMS, Stern/NYU, Spring Injection attacks – MySQL/Perl/PHP Consider another input:  user: your-boss  pass: ' OR 1=1 AND user = 'your-boss  Delete your boss! DELETE FROM users WHERE user = u AND password = p; DELETE FROM users WHERE user = u AND password = p; DELETE FROM users WHERE user = 'your-boss' AND pass = ' ' OR 1=1 AND user = ' your-boss'; DELETE FROM users WHERE user = 'your-boss' AND pass = ' ' OR 1=1 AND user = ' your-boss'; DELETE FROM users WHERE user = 'your-boss' AND pass = '' OR 1=1 AND user = 'your-boss'; DELETE FROM users WHERE user = 'your-boss' AND pass = '' OR 1=1 AND user = 'your-boss';

M.P. Johnson, DBMS, Stern/NYU, Spring Injection attacks – MySQL/Perl/PHP Consider another input:  user: ' OR 1=1 OR user = '  pass: ' OR 1=1 OR user = '  Delete everyone! DELETE FROM users WHERE user = u AND pass = p; DELETE FROM users WHERE user = u AND pass = p; DELETE FROM users WHERE user = ' ' OR 1=1 OR user = ' ' AND pass = ' ' OR 1=1 OR user = ' '; DELETE FROM users WHERE user = ' ' OR 1=1 OR user = ' ' AND pass = ' ' OR 1=1 OR user = ' '; DELETE FROM users WHERE user = '' OR 1=1 OR user = '' AND pass = '' OR 1=1 OR user = ''; DELETE FROM users WHERE user = '' OR 1=1 OR user = '' AND pass = '' OR 1=1 OR user = '';

M.P. Johnson, DBMS, Stern/NYU, Spring Preventing injection attacks Ultimate source of problem: quotes Soln 1: don’t allow quotes!  Reject any entered data containing single quotes Q: Is this satisfactory?  Does Amazon need to sell O’Reilly books? Soln 2: escape any single quotes  Replace any ' with a '' or \'  In Perl, use taint mode – won’t show  In PHP, turn on magic_quotes_gpc flag in.htaccess show both PHP versions

M.P. Johnson, DBMS, Stern/NYU, Spring Preventing injection attacks Soln 3: use prepare parameter-based queries  Supported in JDBC, Perl DBI, PHP ext/mysqli   Even more dangerous: using tainted data to run commands at the Unix command prompt  Semi-colons, prime char, etc.  Safest: define set if legal chars, not illegal ones

M.P. Johnson, DBMS, Stern/NYU, Spring Preventing injection attacks When to do security-checking for quotes, etc.? Temping choice: in client-side data validation But not enough!  can submit GET and POST params manually  Must do security checking on server  Even if you do it on client-side too  Same with data-validation  Example of constraints

M.P. Johnson, DBMS, Stern/NYU, Spring POST vars Because of hand-coded HTTP requests, can’t rely on post vars being either safe or “true” Actual past websites: send price by post (why?) More secure than GET  Fewer users will know how to break POST than GET  But some do! Attack: hand-code the POST request sales% telnet amazon.com 80 POST HTTP/1.0 Content-Type:application/x-www-form-urlencoded Content-Length: 32 title=Database+Systems&price=.01 sales% telnet amazon.com 80 POST HTTP/1.0 Content-Type:application/x-www-form-urlencoded Content-Length: 32 title=Database+Systems&price=.01

M.P. Johnson, DBMS, Stern/NYU, Spring Hand-written POST example POST version of my input page:   Not obvious to web user how to hand submit  And get around any client-side validation But possible:  sales% telnet pages.stern.nyu.edu 80 POST HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 15 val=6&submit=OK sales% telnet pages.stern.nyu.edu 80 POST HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 15 val=6&submit=OK

M.P. Johnson, DBMS, Stern/NYU, Spring More info phpGB MySQL Injection Vulnerability  "How I hacked PacketStorm“  Google hacking…  inurl:"ViewerFrame?Mode="  intitle:"Live View / - AXIS" | inurl:view/view.sht  intitle:"toshiba network camera - User Login"   

M.P. Johnson, DBMS, Stern/NYU, Spring New-old topic: Transactions So far, have simply issued commands  Ignored xacts Recall, though: an xact is an operation/set of ops executed atomically  In one instant ACID test:  Xacts are atomic  Each xact (not each statement) must leave the DB consistent

M.P. Johnson, DBMS, Stern/NYU, Spring Default xact behavior (in Oracle) An xact begins upon login By default, xact lasts until logoff  Except for DDL statements  They automatically commit Examples with two views of tbl…  But with TYPE=innodb !  mysql> set autocommit = 0

M.P. Johnson, DBMS, Stern/NYU, Spring Direct xact instructions At any point, may explicitly COMMIT:  SQL> COMMIT;  Saves all statements entered up to now  Begins new xact Conversely, can ROLLBACK  SQL> ROLLBACK;  Cancels all statements entered since start of xact Example: delete from emp; or delete junk;

M.P. Johnson, DBMS, Stern/NYU, Spring Direct xact instructions Remember, DDL statements are auto- committed  They cannot be rollbacked Examples: Q: Why doesn’t rollback “work”? drop table junk; rollback; drop table junk; rollback; truncate table junk; rollback; truncate table junk; rollback;

M.P. Johnson, DBMS, Stern/NYU, Spring Savepoints (in Oracle?) Xacts are atomic Can rollback to beginning of current xact But might want to rollback only part way Make 10 changes, make one bad change Want to: roll back to before last change Don’t have Word-like multiple undo  But do have savepoints

M.P. Johnson, DBMS, Stern/NYU, Spring Savepoints Create a savepoint: emp example: --changes SAVEPOINT sp1; --changes SAVEPOINT sp2; --changes SAVEPOINT sp3 --changes ROLLBACK TO SAVEPOINT sp2; ROLLBACK TO SAVEPOINT sp1; --changes SAVEPOINT sp1; --changes SAVEPOINT sp2; --changes SAVEPOINT sp3 --changes ROLLBACK TO SAVEPOINT sp2; ROLLBACK TO SAVEPOINT sp1; SAVEPOINT savept_name; Can skip savepoints But can ROLLBACK only backwards Can ROLLBACK only to last COMMIT

M.P. Johnson, DBMS, Stern/NYU, Spring AUTOCOMMIT (in Oracle?) Finally, can turn AUTOCOMMIT on:  SQL> SET AUTOCOMMIT ON;  Can put this in your config file  Can specify through JDBC, etc. Then each statement is auto-committed as its own xact  Not just DDL statements

M.P. Johnson, DBMS, Stern/NYU, Spring RAID levels RAID level 1: each disk gets a mirror RAID level 4: one disk is xor of all others  Each bit is sum mod 2 of corresponding bits E.g.:  Disk 1:  Disk 2:  Disk 3:  Disk 4: How to recover? What’s the disadvantage of R4?  Various other RAID levels in text…