1. Lecture 19 Page 1 CS 236 Online Advanced Research Issues in Security: Web Security and Privacy CS 236 On-Line MS Program Networks and Systems Security Peter Reiher

2. Lecture 19 Page 2 CS 236 Online Outline Web security Privacy issues in modern computer systems

3. Lecture 19 Page 3 CS 236 Online Web Security Lots of Internet traffic is related to the web Much of it is financial in nature Also lots of private information flow around web applications An obvious target for attackers

4. Lecture 19 Page 4 CS 236 Online The Web Security Problem Many users interact with many servers Most parties have little other relationship Increasingly complex things are moved via the web No central authority Many developers with little security experience Many critical elements originally designed with no thought to security Sort of a microcosm of the overall security problem

5. Lecture 19 Page 5 CS 236 Online Aspects of the Web Problem

6. Lecture 19 Page 6 CS 236 Online Who Are We Protecting? The server From the client The client From the server The clients From each other

7. Lecture 19 Page 7 CS 236 Online What Are We Protecting? The client’s private data The server’s private data The integrity (maybe secrecy) of their transactions The client and server’s machines Possibly server availability –For particular clients?

8. Lecture 19 Page 8 CS 236 Online Some Real Threats Buffer overflows and other compromises –Client attacks server SQL injection –Client attacks server Malicious downloaded code –Server attacks client

9. Lecture 19 Page 9 CS 236 Online More Threats Cross-site scripting –Clients attack each other Threats based on non-transactional nature of communication –Client attacks server Denial of service attacks –Threats on server availability (usually)

10. Lecture 19 Page 10 CS 236 Online Compromise Threats Much the same as for any other network application Web server might have buffer overflow –Or other remotely usable flaw Not different in character from any other application’s problem

11. Lecture 19 Page 11 CS 236 Online What Makes It Worse Web servers are complex They often also run supporting code –Which is often user-visible Large, complex code base is likely to contain such flaws Nature of application demands allowing remote use

12. Lecture 19 Page 12 CS 236 Online Solution Approaches Patching Use good code base Minimize code that the server executes Maybe restrict server access –When that makes sense Lots of testing and evaluation

13. Lecture 19 Page 13 CS 236 Online SQL Injection Attacks Many web servers have backing databases –Much of their information stored in database Web pages are built (in part) based on queries to database –Possibly using some client input...

14. Lecture 19 Page 14 CS 236 Online SQL Injection Mechanics Server plans to build a SQL query Needs some data from client to build it –E.g., client’s user name Server asks client for data Client, instead, provides a SQL fragment Server inserts it into planned query –Leading to a “somewhat different” query

15. Lecture 19 Page 15 CS 236 Online An Example “select * from mysql.user where username = ‘ “. $uid. “ ‘ and password=password(‘ “. $pwd “ ‘);” Intent is that user fills in his ID and password What if he fills in something else? ‘or 1=1; -- ‘

16. Lecture 19 Page 16 CS 236 Online What Happens Then? $uid has the string substituted, yielding “select * from mysql.user where username = ‘ ‘ or 1=1; -- ‘ ‘ and password=password(‘ “. $pwd “ ‘);” This evaluates to true –Since 1 does indeed equal 1 –And -- comments out rest of line If script uses truth of statement to determine valid login, attacker has logged in

17. Lecture 19 Page 17 CS 236 Online Basis of SQL Injection Problem Unvalidated input Server expected plain data Got back SQL commands Didn’t recognize the difference and went ahead Resulting in arbitrary SQL query being sent to its database –With its privileges

18. Lecture 19 Page 18 CS 236 Online Solution Approaches Carefully examine all input –To filter out injected SQL Use database access controls –Of limited value Randomization of SQL keywords –Making injected SQL meaningless

19. Lecture 19 Page 19 CS 236 Online Malicious Downloaded Code Modern web relies heavily on downloaded code –Full language and scripting language Instructions downloaded from server to client –Run by client on his machine –Using his privileges Without defense, script could do anything

20. Lecture 19 Page 20 CS 236 Online Types of Downloaded Code Java –Full programming language Scripting languages –Java Script –VB Script –ECMAScript –XSLT

21. Lecture 19 Page 21 CS 236 Online Solution Approaches Disable scripts –Not very popular Use secure scripting languages –Also not popular –Particularly with code writers Isolation mechanisms –VM or application-based Vista mandatory access control

22. Lecture 19 Page 22 CS 236 Online Cross-Site Scripting XSS Many sites allow users to upload information –Blogs, photo sharing, Facebook, etc. –Which gets permanently stored –And displayed Attack based on uploading a script Other users inadvertently download it –And run it...

23. Lecture 19 Page 23 CS 236 Online The Effect of XSS Arbitrary malicious script executes on user’s machine In context of his web browser –At best, runs with privileges of the site storing the script –Often likely to run at full user privileges

24. Lecture 19 Page 24 CS 236 Online Why Is XSS Common? Use of scripting languages widespread –For legitimate purposes Most users leave them enabled in browser Only a question of getting user to run your script –Often only requires fetching URL

25. Lecture 19 Page 25 CS 236 Online Typical Effects of XSS Attack Most commonly used to steal personal information –That is available to legit web site –User IDs, passwords, credit card numbers, etc. Such information often stored in cookies at client side

26. Lecture 19 Page 26 CS 236 Online Solution Approaches Don’t allow uploading of scripts –Usually by carefully analyzing uploaded data Provide some form of protection in browser

27. Lecture 19 Page 27 CS 236 Online Exploiting Statelessness HTTP is designed to be stateless But many useful web interactions are stateful Various tricks used to achieve statefulness –Usually requiring programmers to provide the state –Often trying to minimize work for the server

28. Lecture 19 Page 28 CS 236 Online A Simple Example Web sites are set up as graphs of links You start at some predefined point –A top level page, e.g. And you traverse links to get to other pages But HTTP doesn’t “keep track” of where you’ve been –Each request is simply the name of a link

29. Lecture 19 Page 29 CS 236 Online Why Is That a Problem? What if there are unlinked pages on the server? Should a user be able to reach those merely by naming them? Is that what the site designers intended?

30. Lecture 19 Page 30 CS 236 Online A Concrete Example The ApplyYourself system Used by colleges to handle student applications For example, by Harvard Business School in 2005 Once all admissions decisions made, results available to students

31. Lecture 19 Page 31 CS 236 Online What Went Wrong? Pages representing results were created as decisions were made Stored on the web server –But not linked to anything, since results not yet released Some appliers figured out how to craft URLs to access their pages –Finding out early if they were admitted

32. Lecture 19 Page 32 CS 236 Online Another Example A e-commerce site that uses a shopping cart paradigm –Users collect things they plan to buy in a shopping cart HTTP won’t help maintain state So Cartman software stored shopping cart state in a cookie –Which wasn’t encrypted...

33. Lecture 19 Page 33 CS 236 Online What Went Wrong? The cookie held the names of the products –And the offered prices Cookies were kept by users –Presented on each web request Users could alter cookies to set their own prices

34. Lecture 19 Page 34 CS 236 Online Another Example Airlines offer on-line choice of seats to users buying tickets Different seats offered to different people –Depending on price, frequent flyer status, etc. Users consult map to choose seat –Choice represented in HTTP message

35. Lecture 19 Page 35 CS 236 Online What Went Wrong? Since HTTP is stateless, no memory of seat map that was sent to a user If user crafts URL asking for seat he wasn’t offered, System doesn’t know it wasn’t offered Allowed users to request seats the airline didn’t want to offer to them

36. Lecture 19 Page 36 CS 236 Online The Common Thread No protocol memory of what came before So no protocol way to determine that response matches request Could be built into the application that handles requests But frequently isn’t –Or is wrong

37. Lecture 19 Page 37 CS 236 Online Solution Approaches Get better programmers –Or better programming tools Back end system that maintains and compares state Front end program that observes requests and responses –Producing state as a result