Upload
randolph-morris
View
229
Download
2
Embed Size (px)
Citation preview
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 formSELECT * 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 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!
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 toSELECT * 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 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
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 trueif (!hasLoggedIn) return “login.xhtml”
Session Hijacking
• Problem: Assumes SessionID can be uniquely associated with person who actually logged in!
• Attack:
ServerBob’s SessionID:
abc123
Bob’s browserBob’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 browserValue 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.jsEvil.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
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)