1. Lecture 19 Page 1 CS 136, Spring 2009 Web Security and Privacy CS 136 Computer Security Peter Reiher June 4, 2009

2. Lecture 19 Page 2 CS 136, Spring 2009 Outline Web security Privacy issues in modern computer systems

3. Lecture 19 Page 3 CS 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 Aspects of the Web Problem

6. Lecture 19 Page 6 CS 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 Types of Downloaded Code Java –Full programming language Scripting languages –Java Script –VB Script –ECMAScript –XSLT

21. Lecture 19 Page 21 CS 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 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 136, Spring 2009 The Core Problem 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

33. Lecture 19 Page 33 CS 136, Spring 2009 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

34. Lecture 19 Page 34 CS 136, Spring 2009 Conclusion Web security problems not inherently different than general software security But generality, power, ubiquity of the web make them especially important Like many other security problems, constrained by legacy issues

35. Lecture 19 Page 35 CS 136, Spring 2009 Privacy Data privacy issues Network privacy issues Some privacy solutions

36. Lecture 19 Page 36 CS 136, Spring 2009 What Is Privacy? The ability to keep certain information secret Usually one’s own information But also information that is “in your custody” Includes ongoing information about what you’re doing

37. Lecture 19 Page 37 CS 136, Spring 2009 Privacy and Computers Much sensitive information currently kept on computers –Which are increasingly networked Often stored in large databases –Huge repositories of privacy time bombs We don’t know where our information is

38. Lecture 19 Page 38 CS 136, Spring 2009 Privacy and Our Network Operations Lots of stuff goes on over the Internet –Banking and other commerce –Health care –Romance and sex –Family issues –Personal identity information We used to regard this stuff as private –Is it private any more?

39. Lecture 19 Page 39 CS 136, Spring 2009 Threat to Computer Privacy Cleartext transmission of data Poor security allows remote users to access our data Sites we visit can save information on us –Multiple sites can combine information Governmental snooping Location privacy Insider threats in various places

40. Lecture 19 Page 40 CS 136, Spring 2009 Some Specific Privacy Problems Poorly secured databases that are remotely accessible –Or are stored on hackable computers Data mining by companies we interact with Eavesdropping on network communications by governments Insiders improperly accessing information Cell phone/mobile computer-based location tracking

41. Lecture 19 Page 41 CS 136, Spring 2009 Data Privacy Issues My data is stored somewhere –Can I control who can use it/see it? Can I even know who’s got it? How do I protect a set of private data? –While still allowing some use? Will data mining divulge data “through the back door”?

42. Lecture 19 Page 42 CS 136, Spring 2009 Personal Data Who owns data about you? What if it’s really personal data? –Social security number, DoB, your DNA record? What if it’s data someone gathered about you? –Your Google history or shopping records –Does it matter how they got it?

43. Lecture 19 Page 43 CS 136, Spring 2009 Protecting Data Sets If my company has (legitimately) a bunch of personal data, What can I/should I do to protect it? –Given that I probably also need to use it? If I fail, how do I know that? –And what remedies do I have?

44. Lecture 19 Page 44 CS 136, Spring 2009 Options for Protecting Data Careful system design Limited access to the database –Networked or otherwise Full logging and careful auditing Using only encrypted data –Must it be decrypted? –If so, how to protect the data and the keys?

45. Lecture 19 Page 45 CS 136, Spring 2009 Data Mining and Privacy Data mining allows users to extract models from databases –Based on aggregated information Often data mining allowed when direct extraction isn’t Unless handled carefully, attackers can use mining to deduce record values

46. Lecture 19 Page 46 CS 136, Spring 2009 Insider Threats and Privacy Often insiders need access to private data –Under some circumstances But they might abuse that access How can we determine when they misbehave? What can we do?

47. Lecture 19 Page 47 CS 136, Spring 2009 Network Privacy Mostly issues of preserving privacy of data flowing through network Start with encryption –With good encryption, data values not readable So what’s the problem?

48. Lecture 19 Page 48 CS 136, Spring 2009 Traffic Analysis Problems Sometimes desirable to hide that you’re talking to someone else That can be deduced even if the data itself cannot How can you hide that? –In the Internet of today?

49. Lecture 19 Page 49 CS 136, Spring 2009 Location Privacy Mobile devices often communicate while on the move Often providing information about their location –Perhaps detailed information –Maybe just hints This can be used to track our movements

50. Lecture 19 Page 50 CS 136, Spring 2009 Implications of Location Privacy Problems Anyone with access to location data can know where we go Allowing government surveillance Or a private detective following your moves Or a maniac stalker figuring out where to ambush you...

51. Lecture 19 Page 51 CS 136, Spring 2009 Some Privacy Solutions The Scott McNealy solution –“Get over it.” Anonymizers Onion routing Privacy-preserving data mining Preserving location privacy Handling insider threats via optimistic security

52. Lecture 19 Page 52 CS 136, Spring 2009 Anonymizers Network sites that accept requests of various kinds from outsiders Then submit those requests –Under their own or fake identity Responses returned to the original requestor A NAT box is a poor man’s anonymizer

53. Lecture 19 Page 53 CS 136, Spring 2009 The Problem With Anonymizers The entity running knows who’s who Either can use that information himself Or can be fooled/compelled/hacked to divulge it to others Generally not a reliable source of real anonymity

54. Lecture 19 Page 54 CS 136, Spring 2009 Onion Routing Meant to handle issue of people knowing who you’re talking to Basic idea is to conceal sources and destinations By sending lots of crypo-protected packets between lots of places Each packet goes through multiple hops

55. Lecture 19 Page 55 CS 136, Spring 2009 A Little More Detail A group of nodes agree to be onion routers Users obtain crypto keys for those nodes Plan is that many users send many packets through the onion routers –Concealing who’s really talking

56. Lecture 19 Page 56 CS 136, Spring 2009 Sending an Onion-Routed Packet Encrypt the packet using the destination’s key Wrap that with another packet to another router –Encrypted with that router’s key Iterate a bunch of times

57. Lecture 19 Page 57 CS 136, Spring 2009 In Diagram Form SourceDestination Onion routers

58. Lecture 19 Page 58 CS 136, Spring 2009 What’s Really in the Packet

59. Lecture 19 Page 59 CS 136, Spring 2009 Delivering the Message

60. Lecture 19 Page 60 CS 136, Spring 2009 What’s Been Achieved? Nobody improper read the message Nobody knows who sent the message –Except the receiver Nobody knows who received the message –Except the sender Assuming you got it all right

61. Lecture 19 Page 61 CS 136, Spring 2009 Issues for Onion Routing Proper use of keys Traffic analysis Overheads –Multiple hops –Multiple encryptions

62. Lecture 19 Page 62 CS 136, Spring 2009 Privacy-Preserving Data Mining Allow users access to aggregate statistics But don’t allow them to deduce individual statistics How to stop that?

63. Lecture 19 Page 63 CS 136, Spring 2009 Approaches to Privacy for Data Mining Perturbation –Add noise to sensitive value Blocking –Don’t let aggregate query see sensitive value Sampling –Randomly sample only part of data

64. Lecture 19 Page 64 CS 136, Spring 2009 Preserving Location Privacy Can we prevent people from knowing where we are? Given that we carry mobile communications devices And that we might want location- specific services ourselves

65. Lecture 19 Page 65 CS 136, Spring 2009 Location-Tracking Services Services that get reports on our mobile device’s position –Probably sent from that device Often useful –But sometimes we don’t want them turned on So, turn them off then

66. Lecture 19 Page 66 CS 136, Spring 2009 But... What if we turn it off just before entering a “sensitive area”? And turn it back on right after we leave? Might someone deduce that we spent the time in that area? Very probably

67. Lecture 19 Page 67 CS 136, Spring 2009 Handling Location Inferencing Need to obscure that a user probably entered a particular area Can reduce update rate –Reducing certainty of travel Or bundle together areas –Increasing uncertainty of which was entered

68. Lecture 19 Page 68 CS 136, Spring 2009 Conclusion Privacy is a difficult problem in computer systems Good tools are lacking –Or are expensive/cumbersome Hard to get cooperation of others Probably an area where legal assistance is required