CSCI 6962: Server-side Design and 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=‘’ Query succeeds if database contains user named admin – If admin has administrative privileges, now control database! Commented out!

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 SELECT * FROM users WHERE id=‘’ OR 1=1--' AND password=‘’ Query matches all users in database Database probably uses first record matched – Probably administrator Commented out! Always true!

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=?”) p.setString(1, request.getParamter(“id”)); Form of query set in advance based on this 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: Server Bob’s SessionID: abc123 Bob’s browser Bob’s SessionID: abc123 Attacker Page request with 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 ValueDomain jsessionid=2093hffpqe32Widgets.com jsessionid=oirtg04hnwre4gtrAmazon.com jsessionid=ifnvp9rnpa234rf4ysu.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

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

Attacker site XSS and Session Hijacking Bob’s browser Cookies: Evil.js Trusted site ValueDomain jsessionid=2093hffpqe32Trusted.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 &#60

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)