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 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 &#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)