1. M.P. Johnson, DBMS, Stern/NYU, Spring 20051 C20.0046: Database Management Systems Lecture #23 M.P. Johnson Stern School of Business, NYU Spring, 2005

2. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 2 Homework Project part 5  Topic: web interface + any remaining loose ends  Up now  Due: end of semester  Run, don’t walk  Important: if you use data you from someone else (e.g., from the web), this should be visibly cited on your site Will return proj4 today  Remind me!

3. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 3 Agenda Security  Secrecy  Integrity  Availability  Web issues XML

4. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 4 Goals: after today After Today:  Know how to make your Perl/PHP sites (more) secure

5. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 5 New topic: Security issues Secrecy  E.g.: You can see only your own grades Integrity  E.g.: Only an instructor can assign grades, and only to his students Web issues  E.g.: injection attacks

6. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 6 Why security is hard It’s a “negative deliverable” It’s an asymmetric threat It’s open-ended Tolstoy: “Happy families are all alike; every unhappy family is unhappy in its own way.” Analogs: “homeland” security, jails, debugging, proofreading, Popperian science, fishing, MC algs

7. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 7 DB users have privileges SELECT : read access to all columns INSERT(col-name) : can insert rows with non- default values in this column INSERT : can insert rows with non-default values in all columns DELETE REFERENCES(col-name) : can define foreign keys that refer to (or other constraints that mention) this column TRIGGER : triggers can reference table EXECUTE : can run function/SP

8. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 8 Granting privileges (Oracle) One method of setting access levels Creator of object automatically gets all privileges to it  Possible objects: tables, whole databases, stored functions/procedures, etc. .* - all tables in DB A privileged user can grant privileges to other users or groups GRANT privileges ON object TO user GRANT SELECT ON mytable TO someone WITH GRANT OPTION;

9. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 9 Granting and revoking Privileged user has privileges Privileged-WGO user can grant them, w/wo GO Granter can revoke privileges or GO Revocation cascades by default  To prevent, use RESTRICT (at end of cmd)  If would cascade, command fails Can change owner: ALTER TABLE my-tbl OWNER TO new-owner; ALTER TABLE my-tbl OWNER TO new-owner;

10. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 10 Granting and revoking What we giveth, we may taketh away mjohnson: (effects?) george: (effects?) mjohnson: (effects?) GRANT SELECT, INSERT ON my-table TO george WITH GRANT OPTION; GRANT SELECT ON my-table TO laura; REVOKE SELECT ON my-table FROM laura;

11. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 11 Role-based authorization In SQL-1999, privileges assigned with roles  Not yet supported in MySql For example:  Student role  Instructor role  Admin role Each role gets to do same (sorts of) things Privileges assigned by assigning role to users GRANT SELECT ON my-table TO employee; GRANT employee TO billg;

12. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 12 Passwords DBMS recognizes your privileges because it recognizes you  how?  Storing passwords in the DB is a bad idea

13. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 13 Hashed or digested passwords One-way hash function: 1. computing f(x) is easy; 2. Computing f -1 (y) is hard/impossible; 3. Finding some x2 s.t. f(x2) = f(x) is hard/imposs “collisions” Intuitively: seeing f(x) gives little (useful) info on x  x “looks random”  PRNGs MD5, SHA-1 RFID for cars: http://www.rfidanalysis.org/http://www.rfidanalysis.org/

14. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 14 Built-in accounts Many DBMSs (and OSs) have built-in demo accounts by default  In some versions, must “opt out” MySQL: root/(blank) (closed on sales)  http://lists.seifried.org/pipermail/security/2004-February/001782.html http://lists.seifried.org/pipermail/security/2004-February/001782.html Oracle: scott/tiger (was open on sales last year) SQLServer: sa/(blank/null)  http://support.microsoft.com/default.aspx?scid=kb;EN-US;313418 http://support.microsoft.com/default.aspx?scid=kb;EN-US;313418

15. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 15 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? “man in the middle” attack 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?

16. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 16 Security on the web Obvious soln: passwords  What’s the problem? Slightly 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?

17. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 17 Authentication on the web Neither private- nor public-key suffices But together they do !  “hybrid” protocol“ for authentication SSL(HTTPS)-style algorithm:  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

18. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 18 Authentication on the web Now George trusts that it’s really Amazon  Assuming Amazon’s private key is secure 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…

19. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 19 Encryption on the web What about secrecy? Again, a (related) hybrid protocol:  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.

20. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 20 More authentication Neither private- nor public-key suffices But together they do !  “hybrid” protocol“ for authentication  “phishing” ssh-style algorithm:  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

21. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 21 Security and CGI CGI has two parameter methods:  GET  POST For secret information, GET is obviously insecure  Displays in browser  Written into server log Either way, data can still be sniffed Soln: encryption

22. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 22 CGI & security Imagine scenario:  You’re Amazon  Users can search for books  Users can put books in the cart  A couple pages to pay You need to  Charge P (the book’s price) at the end  Display P on each page Don’t want to query of price for every single page One bad idea: each page after first takes P as a (hidden) get var from prior

23. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 23 CGI & security Attack: type in false data in GET request Very insecure! Soln 1: Use POST, not GET http://amazon.com/cart.cgi?title=Dat abase+Systems&price=.01

24. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 24 Send price, etc., by POST This is more secure  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://amazon.com/cart.cgi 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://amazon.com/cart.cgi HTTP/1.0 Content-Type:application/x-www-form- urlencoded Content-Length: 32 title=Database+Systems&price=.01

25. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 25 Handed-written POST example POST version of my input page:  http://pages.stern.nyu.edu/~mjohnson/dbms/php/post.php http://pages.stern.nyu.edu/~mjohnson/dbms/php/post.php  Not obvious to web user how to hand submit  And get around any client-side validation But possible:  http://pages.stern.nyu.edu/~mjohnson/dbms/eg/postbyhand.txt http://pages.stern.nyu.edu/~mjohnson/dbms/eg/postbyhand.txt sales% telnet pages.stern.nyu.edu 80 POST http://pages.stern.nyu.edu/~mjohnson/dbms/php/post.php 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://pages.stern.nyu.edu/~mjohnson/dbms/php/post.php HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 15 val=6&submit=OK

26. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 26 Query-related: Injection attacks Here’s a situation:  Prompt for user/pass  Do lookup:  If found, user gets in test.user table in MySQL http://pages.stern.nyu.edu/~mjohnson/dbms/php/loginph p.txt http://pages.stern.nyu.edu/~mjohnson/dbms/php/loginph p.txt http://pages.stern.nyu.edu/~mjohnson/dbms/php/login.php  Apart from no hashing, is this safe? SELECT * FROM users WHERE user=u AND password=p; SELECT * FROM users WHERE user=u AND password=p;

27. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 27 Injection attacks We expect to get input of something like:  user: mjohnson  pass: top secret  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';

28. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 28 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 = ' '; http://pages.stern.nyu.edu/~mjohnson/dbms/php/login.php http://pages.stern.nyu.edu/~mjohnson/dbms/eg/injection.txt 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 = '';

29. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 29 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'; http://pages.stern.nyu.edu/~mjohnson/dbms/php/login.php 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';

30. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 30 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 = ' '; http://pages.stern.nyu.edu/~mjohnson/dbms/php/login.php 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 = '';

31. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 31 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';

32. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 32 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)

33. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 33 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)

34. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 34 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'; http://pages.stern.nyu.edu/~mjohnson/dbms/php/users.php 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';

35. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 35 http://pages.stern.nyu.edu/~mjohnson/dbms/php/users.php 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 = '';

36. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 36 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

37. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 37 Preventing injection attacks Soln 3: use prepare parameter-based queries  Supported in JDBC, Perl DBI, PHP ext/mysqli  http://pages.stern.nyu.edu/~mjohnson/dbms/perl/loginsafe.cgi http://pages.stern.nyu.edu/~mjohnson/dbms/perl/loginsafe.cgi  http://pages.stern.nyu.edu/~mjohnson/dbms/perl/userssafe.cgi http://pages.stern.nyu.edu/~mjohnson/dbms/perl/userssafe.cgi Very 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

38. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 38 Preventing injection attacks When to do security checking for quotes, etc.? Natural choice: in client-side data validation But not enough!  As saw earlier: can submit GET and POST params manually  Must do security checking on server

39. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 39 More Info phpGB MySQL Injection Vulnerability  http://www.securiteam.com/unixfocus/6X00O1P5PY.html http://www.securiteam.com/unixfocus/6X00O1P5PY.html "How I hacked PacketStorm“  http://www.wiretrip.net/rfp/txt/rfp2k01.txt http://www.wiretrip.net/rfp/txt/rfp2k01.txt

40. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 40 Security Conclusion Not an exhaustive list of issues Big, serious, difficult problems… Each DBMS/product/tech has its own issues Do your hw, or you/your company can look ridiculous or worse

41. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 41 Now there’s “Google hacking”… inurl:"ViewerFrame?Mode=" intitle:"Live View / - AXIS" | inurl:view/view.sht intitle:"toshiba network camera - User Login" http://200.71.42.48/ViewerFrame?Mode=Moti on&Language=0 http://200.71.42.48/ViewerFrame?Mode=Moti on&Language=0 http://141.211.44.254/view/index.shtml http://66.186.226.189/view/index.shtml