CSCI 6962: Server-side Design and Programming

1. CSCI 6962: Server-side Design and Programming Secure Web Programming

2. Secure Web Programming • Web server most vulnerable resource in organization • Must be accessible to anyone • Users can enter anything into text elements • Users can modify query string to send any value • Users can bypass any client-side security • Goal: prevent malicious users from sending “dangerous” values • Attacks on your data • Attacks on other users who visit your site

3. SQL Injection • Form inputs contain values used in database query • Hacker enters values that modify SQL used in query • Access unauthorized privileges • Modify database in destructive ways • Access operating system…

4. SQL Injection Methods • Comments: Anything after -- is ignored • Quotes: Can confuse SQL parser about where strings start and end • Example: • Normal login query of formSELECT * FROM users WHERE id=‘homer’ AND password=‘donut’ Fields passed from form elements on web page

5. SQL Injection Methods • Attack: Comment out password check • Enter admin’--for username • Query now of formSELECT * FROM users WHERE id=‘admin’--' AND password=‘’ • Query succeeds if database contains user named admin • If admin has administrative privileges, now control database! Commented out!

6. SQL Injection Methods • Disjunction with inherently true statement • … OR 1=1 always true • Can use to get all records • Example: • Don’t know administrator account called admin • Do know administrator account often first in database

7. SQL Injection Methods • Query now resolves toSELECT * FROM users WHERE id=‘’ OR 1=1--' AND password=‘’ • Query matches all users in database • Database probably uses first record matched • Probably administrator Always true! Commented out!

8. SQL Injection Methods • Can use ; to end query and insert commands • Some database servers even allow direct access to operating system • xp_cmdshell,xp_regwrite, …

9. Preventing SQL Injection • Hard/unreliable way: Filter out all “dangerous” string values before use in SQL query • Problem: Many such characters often part of legitimate input and should be accepted • O’Reilly • Smith-Jones… • Difficult to create more complex rules for filtering without missing cases • Hackers always looking for new ways to exploit

10. Preventing SQL Injection • Best/simpler way: Use prepared statementsPrepared Statement p = connection.prepareStatement( “SELECT * FROM users WHERE id=? AND password=?”) p.setString(1, request.getParamter(“id”)); Form of query set in advance based on this Value of this treated as string rather than command

11. Session Hijacking • Sessions commonly used for access control so user only has to log in once during session • Usual structure: • User successfully logs in  value in bean set to truehasLoggedIn = true; • Any subsequent page request checks this value • Redirects to login page if not true if (!hasLoggedIn) return “login.xhtml”

12. Session Hijacking • Problem: Assumes SessionID can be uniquely associated with person who actually logged in! • Attack: Bob’s browser Bob’s SessionID: abc123 Server Bob’s SessionID: abc123 Server has no way of knowing request does not come from Bob! Attacker Page request with SessionID = abc123

13. Preventing Session Hijacking Server side: • Make session identifiers difficult to guess • Random numbers • Very long • Limit time attackers have to find session ID • Session timeout • Logout button destroys session • Mostly built into modern web containers

14. Preventing Session Hijacking Client side: Same origin policy in browsers • Cookies only accessible by same site that set them • Domain of web site is property of each cookie in browser • Otherwise malicious web site could steal session ID set by other sites Bob’s browser

15. Cross-site Scripting (XSS) • Inserting malicious JavaScript onto trusted web site • User visits trusted site and goes to page containing malicious JavaScript • Malicious JavaScript downloaded to and run on user browser Server Bob’s browser Trusted.html Evil.js Evil.js

16. Cross-site Scripting • Can happen on any page where user can post text • User comments • Product reviews • Discussion pages (MySpace was first major victim) • …

17. Cross-site scripting • Attacker can insert reference to JavaScript file on another site • Symbols such as <, >, :, “, etc. escaped • Any browser that loads this comment downloads and executes JavaScript from that site

18. XSS and Session Hijacking • Key idea: JavaScript downloaded from trusted site • Has access to any cookies set by trusted site under same origin policy • JavaScript has commands for manipulating cookies • Can be used for session hijacking

19. XSS and Session Hijacking Bob’s browser Cookies: Trusted site Evil.js Attacker site Evil.js

20. Preventing Cross-site Scripting • Use html encoding to convert potentially executable symbols into non-executable symbols • All characters have numbers in html • Can force browser to render character instead of executing it by using &#number instead of actual character • Example: To display < in html must use &#60

21. Preventing Cross-site Scripting • Safest to encode all characters posted by user • Not just those obviously dangerous (<, >, etc.) • Most web languages have tools for doing this • Server.HTMLEncodein ASP.NET • <h:outputLabelautomatically converts all characters output (unless escape=false attribute added)