Transcript Document
CSCI 6962: Server-side Design and Programming Secure Web Programming 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 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… SQL Injection Methods • Comments: Anything after -- is ignored • Quotes: Can confuse SQL parser about where strings start and end • Example: – Normal login query of form SELECT * FROM users WHERE id=‘homer’ AND password=‘donut’ Fields passed from form elements on web page SQL Injection Methods • Attack: Comment out password check • Enter admin’-- for username • Query now of form SELECT * FROM users WHERE id=‘admin’--' AND password=‘’ Commented out! • Query succeeds if database contains user named admin – If admin has administrative privileges, now control database! 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 SQL Injection Methods • Query now resolves to Always true! SELECT * FROM users WHERE id=‘’ OR 1=1--' AND password=‘’ Commented out! • Query matches all users in database • Database probably uses first record matched – Probably administrator 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, … 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 Preventing SQL Injection • Best/simpler way: Use prepared statements Prepared Statement p = connection.prepareStatement( “SELECT * FROM users WHERE id=? AND password=?”) Form of query set in advance based on this p.setString(1, request.getParamter(“id”)); Value of this treated as string rather than command 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 true hasLoggedIn = true; – Any subsequent page request checks this value • Redirects to login page if not true if (!hasLoggedIn) return “login.xhtml” Session Hijacking • Problem: Assumes SessionID can be uniquely associated with person who actually logged in! • Attack: Bob’s browser Bob’s SessionID: abc123 Attacker Page request with SessionID = abc123 Server Bob’s SessionID: abc123 Server has no way of knowing request does not come from Bob! 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 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 Value Domain jsessionid=2093hffpqe32 Widgets.com jsessionid=oirtg04hnwre4gtr Amazon.com jsessionid=ifnvp9rnpa234rf4 ysu.edu 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 Cross-site Scripting • Can happen on any page where user can post text – – – – User comments Product reviews Discussion pages (MySpace was first major victim) … 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 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 XSS and Session Hijacking Trusted site Bob’s browser Evil.js Attacker site Cookies: Value Domain jsessionid=2093hffpqe32 Trusted.com Evil.js 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 < 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.HTMLEncode in ASP.NET – <h:outputLabel automatically converts all characters output (unless escape=false attribute added)