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

  • Published on
    27-Dec-2015

  • View
    213

  • Download
    1

Embed Size (px)

Transcript

  • Slide 1
  • CSCI 6962: Server-side Design and Programming Secure Web Programming
  • Slide 2
  • 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
  • Slide 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
  • Slide 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 form SELECT * FROM users WHERE id=homer AND password=donut Fields passed from form elements on web page
  • Slide 5
  • 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!
  • Slide 6
  • SQL Injection Methods Disjunction with inherently true statement OR 1=1 always true Can use to get all records Example: Dont know administrator account called admin Do know administrator account often first in database
  • Slide 7
  • 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!
  • Slide 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,
  • Slide 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 OReilly Smith-Jones Difficult to create more complex rules for filtering without missing cases Hackers always looking for new ways to exploit
  • Slide 10
  • 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
  • Slide 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 true hasLoggedIn = true; Any subsequent page request checks this value Redirects to login page if not true if (!hasLoggedIn) return login.xhtml
  • Slide 12
  • Session Hijacking Problem: Assumes SessionID can be uniquely associated with person who actually logged in! Attack: Server Bobs SessionID: abc123 Bobs browser Bobs SessionID: abc123 Attacker Page request with SessionID = abc123 Server has no way of knowing request does not come from Bob!
  • Slide 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
  • Slide 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 Bobs browser ValueDomain jsessionid=2093hffpqe32Widgets.com jsessionid=oirtg04hnwre4gtrAmazon.com jsessionid=ifnvp9rnpa234rf4ysu.edu
  • Slide 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 Bobs browser Trusted.html Evil.js
  • Slide 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)
  • Slide 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
  • Slide 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
  • Slide 19
  • Attacker site XSS and Session Hijacking Bobs browser Cookies: Evil.js Trusted site ValueDomain jsessionid=2093hffpqe32Trusted.com Evil.js
  • Slide 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 <
  • Slide 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.HTMLEncode in ASP.NET

Recommended

View more >