Chapter 12 The Web and Security

1. Chapter 12 The Web and Security

2. Overview • The web is where it’s at • Simple web pages are simple • But things get complicated when a web application requires state to be maintained across pages and time • Privacy and security remain concerns

3. The Web • Now central to commerce and daily life • Still evolving • Standards • Code • Practices • Browser features

4. Web Pages • Alice requests a web page using her browser (URL) • Bob’s server returns a copy of the web page • Alice’s browser displays the web page

5. Browser’s Request • The URL (URI) protocol://hostname/path • An example http://cs.metrostate.edu/~fitzgesu/courses/

6. The Protocol • Most common – http • Hyptertext Transport Protocol • Stateless, request-reply protocol • Other common protocols • ftp • file • telnet • https

7. The Hostname • A domain name and host computer • Host + parent’s domain cs.metrostate.edu • Translates to an IP address

8. Path • Translates into a path in the web server’s directory structure ~fitzgesu/courses • Translates into /home/fitzgesu/public_html/courses/ • If no file name is given, the default file name is used – usually index.htm, index.html or index.php

9. Paths - Exceptions • URL’s can be redirected to another web page • A load balancer could forward the request to one of several servers

10. The Request • User types in URL • User cuts and pastes URL • User clicks link on page • User clicks link from email • User clicks link from pdf or other ‘non-web’ content

11. User Expectations • Phishing – a malicious entity invites a user to click on a bogus link in order to collect sensitive information • User pays insufficient attention to URL • User’s expectations are incorrect • Some browsers expand incomplete URL’s – users are sent somewhere unexpected

12. User Expectations (continued) • Typejacking – registering a hostname deceptively similarly to a real hostname • paypa1.com • whitehouse.gov vs. whitehouse.com

13. Interaction • Forms • input fields – have names • input fields can be ‘hidden’ • input fields can have default values • action – the script/page designated to handle the form input on the server side • method • get – inputs are appended to URL • put – inputs are sent to server separately

14. Web Form Processing • Data sent to the server is not encrypted by default • If data is appended to the URL, it can be stored in web logs and history lists or it can be passed along to third parties

15. Cross-Site Scripting • Bob’s site allows users to upload content (pictures, blogs), but does not check for malicious payloads • Bob’s site inadvertantly displays a link to malicious content, perhaps in the form of a link • Alice visits Bob’s site and clicks the link

16. Page Content • Browser incompatibilities • Platform/browser incompatibilities • Rendering is not always done by the browser • pdf’s • other applications • Opens these applications up to web-based attacks

17. Active (Executable) Content • ActiveX – small pieces of distributed programs downloaded and executed from browsers • Java applets (not so much) • JavaScript

18. One Page • User thinks they are accessing a single page • Pages commonly include images • Images may be located in a local cache • Or a separate http request may be issued for each image • Image may reside on a site other than the web page • Image may be too small to be visible

19. One Page (continued) • Page could include scripts (as well as images) • Framesets – page could be broken into several frames, each of which could be located on a different server

20. Sessions • http is stateless – information is not saved between request/responses • But applications need to save state • They do this by considering a series of related requests as a session

21. Cookies • Data is stored on the client machine • Cookie has an expiration date • Cookie has a domain and path • When the browser visits a server, it looks for client-side cookies whose domain and path match the server. • If such an unexpired cookie exists, it is passed to the server automatically

22. Saving State • Hidden fields in forms can be used to maintain state and pass information from page to page • Browsers use the REFERER field to inform the server about the current page when invoking a new one

23. Sessions – The Holes • Should a session accommodate a family of servers at the same site? • Alliances between domains? • Allow interruptions (go to other sites, return)? • Multiple windows? • Different browsers?

24. The Holes (continued) • What state is preserved? • Which servers see it? • What can adversaries with access to Alice’s machine learn? • How does the server know the user is still the same user? • How does the server know the client has not replaced the front end?

25. The Network • Plaintext traffic can be eavesdropped • DNS and BGP attacks can send browser to wrong website

26. Security Techniques for Web Apps • Basic access control • .htaccess • restricts access to specific directories by IP address or domain name • can be used to password protect specific directories • Not a significant barrier • IP addresses can be forged • username and password are sent in plaintext • username and password do not change • contents are sent in plaintext

27. Server-Side SSL • Secure Sockets Layer (SSL) – part of Netscape • Ubiquitous • See ladder diagram, p. 319 • Specify https as link protocol • Browser and server choose a crypto algorithm • symmetric cipher • integrity checking method • Server has public/private key pair and X.509 certificate

28. Server-Side SSL (continued) • Server sends certificate to browser • Browser decides whether or not to trust certificate • Browser generates random bits – the pre_master_secret, encrypts with server’s public key and sends to server • Both browser and server now privately know the pre_master_secret

29. Server-Side SSL (continued) • Both browser and server use pre_master_secret to generate • encryption key for browser-to-server communications • different encryption key for server-to-browser communications • two keys for integrity checking function (one for sending, one for receiving) • All subsequent communication is encrypted

30. Server-Side SSL (continued) • SSL is now standardized and known as Transport Layer Security (TLS) • Also called server-side SSL since the server presents the PKI certificate

31. SSL Protections • Confidentiality – encrypted communications • Integrity – traffic is hashed • Authentication – server has certificate • No reflection attacks – keys are different for each direction of traffic • No reordering – messages have sequence numbers • No replay attacks – keys are fresh for each session

32. SSL Problems • User interface problems • user may send via https • but server may respond via http • PKI • Can user trust the server’s certificate? • Pre-installed trust root CA’s may be outdated • Users may click OK on warnings

33. SSL Problems (continued) • Bugs • Bad PRNG led to bad shared keys • Post-SSL privacy spills • Servers are hacked, information is stolen from servers, not eavesdropped

34. Client-Side SSL • Server also asks browser to present its certificate • See Fig 12.3, p. 325

35. Privacy • Browsing leaves traces on client side • browsing history • back/forward • cookies • cache images • visited links • autofill • saved login information

36. Privacy (continued) • Server-side • URL information • responses to forms input • cookies • REFERER field • user’s IP address and hostname • connection speed • browser, version • operating system

37. Third-Party Servers • Bob’s site may include images or frames loaded from Edna’s site • When Alice visits Bob’s site, Edna will see • the URL of the page at Bob’s site (REFERER) • GET data • Edna’s cookies

38. DoubleClick • An advertising agency, DoubleClick, convinced many commercial sites to include a DoubleClick image • DoubleClick was then able to plant and retrieve cookies from many users across many web pages and track user browsing behavior • DoubleClick then displayed demographically tailored ads

39. Private Browsing • Onion routing – each node on a packet’s route knows only about its direct predecessor and successor • CROWDS • web requests are randomly passed around a crowd • the request is sent to a server by a random member of the crowd • The potential for abuse where there is no accountability is high

40. P3P • Platform for Privacy Preferences • Web sites encode their privacy policies • A privacy tool reads the privacy policy and compares it against the user’s preferences • A good idea which has not caught on

41. Web Services • Calling a procedure over the web • Data is exchanged in Extensible Markup Language (XML) format • XML is wrapped up in SOAP envelopes and transported using HTTP • New security mechanisms are needed (XML-signatures, XML-encryption, XML Key Management Specification, Security Assertion Markup Language, Extensible Access Control Markup Language)

42. Summary • Web applications are at the core of commerce today • Standards, code and practices are still evolving • Users’ mental models are too simple • Data inputs open the door to security problems • Sessions are used to maintain state • SSL is the most common web app security mechanism • There is no privacy

43. References • Smith and Marchesini, The Craft of System Security, Addison-Wesley, 2008 • http://browserspy.dk/