Internet & Web Security Case Study 3: Web application security

1. Internet & Web SecurityCase Study 3: Web application security Dieter Gollmann Hamburg University of Technology diego@tu-harburg.de

2. Web Security – Introduction • Web designed to share scientific documents; originally little concern for security. • Many components involved: • Servers (Apache, IIS, etc.) • Applications (written in Java, C, Perl, etc.) • Browsers (IE, Netscape, etc.) • Protocols, languages, data formats (HTTP, XML, SQL, SSL) • Operating systems (Windows, Linux, Unix, Mac OS) • Application level vulnerabilities account today for an increasing number of security problems. • Cross site scripting (XSS) first in 2005 CVE list and in the 2007 OWASP Top Ten vulnerabilities.

3. Introduction • Web applications typically accept inputs from remote sites. • Web applications may use addresses (IP addresses, DNS names) as the basis for authorisation decisions. • Web applications may establish common state between participants and refer to this common state when authorising requests. • All these points can become vulnerabilities.

4. Agenda • Web processing model (simplified) • Sessions • Same Origin Policy • Cross-site scripting • Cross-site request forgery • JavaScript hijacking • DNS Rebinding attack

5. Web processing model

6. Web processing model browser client HTML + CSS data HTTP request web server backend systems server

7. Web applications – infrastructure • Logic of a web application implemented at web server and back-end server. • Web server known by its domain name. • Transport protocol specifies data formats and encoding & decoding of application payloads. • Transport: HTTP; data format: HTML (and Cascading Style Sheets (CSS)). • Processing at client side managed by browser. • Client has no name other than its IP address.

8. Web applications – processing • Client sends HTTP request to web server. • Client’s browser has to resolve server’s domain name to an IP address. • Script at web server extracts input from client request; constructs a request to backend application server. • Web server gets result from backend server, returns a HTML result page to client. • Client’s browser displays result page. • DOM (Domain Object Model) internal representation of HTML page.

9. Sessions • HTTP is stateless; Web applications can create sessions on top of HTTP or use SSL sessions established in the network layer. • To create a session on top of HTTP, the server generates a session identifier and sends it to client. • Client includes session identifier in subsequent requests to server. • Requests are authenticated as belonging to a session if they contain the correct session identifier. • Sessions could be established for a particular user.

10. Creating HTTP sessions • Cookies: Sent by server in an HTTP response using the Set-Cookie header field; the client’s browser stores it in document.cookie and includes it in all requests with a domain matching the cookie’s origin. • URL query strings: SID (session identifier as defined in HTTP) included in every URL that points to a resource of the web application. • POST parameters: SID stored in a hidden field in an HTML form. • Cookie contains common state; SID is a reference to common state maintained at server.

11. New Threat Model • Cookie poisoning: Outside attacker or malicious client spoofs or changes common state by forging cookie. • The attacker can be a malicious end system. • Attacker only sees messages addressed to him and data obtained from compromised end systems. • The attacker can guess predictable fields in unseen messages. • Imposes two requirements on session identifiers: must be unpredictabile and stored in a safe place. • This is not the ‘old’ secret services threat model!

12. Same Origin Policy

13. Same Origin Policy (SOP) • Enforced by web browsers to protect application payloads and session identifiers from third parties. • Web application identified by domain of its hosting web server. • An applet may only connect back to the domain it came from. • A cookie is only included in requests to the domain that had placed it. • Two pages “have the same origin” if they share protocol, host name and port number.

14. SOP for http://www.my.org/dir1/hello.html

15. Relaxing the Same Origin Policy • If you do not want to distinguish between hosts in the same domain, SOP is too restrictive. • Parent domain traversal shortens domain name held in document.domain in the DOM to its .domain.tld (Top Level Domain) portion; wwww.my.org can be shortened to my.org but not to org. • Problem: Domain names where the last two fields define a domain, e.g. .co.uk for UK companies. • With parent domain traversal, all co.uk domains can be accessed if you have access to one company. • Browsers keep lists of exceptions to parent domain traversal.

16. Cross Site Scripting

17. Cross-site scripting (XSS) • Parties involved: Attacker, client (victim), server (‘trusted’ by the client). • Attacker places malware on a page at the server (stored XSS) or gets the victim to include the malware in a request to the server (reflected XSS). • The code is contained in the page returned by the server to the client. • The code is executed at the client with the permissions of the trusted server. • Evades client’s origin based security policy.

18. Reflected XSS • User gets malicious input from attacker, e.g. by visiting attacker’s web site, which is then included in a request to the trusted server. • Data provided by client used by server-side scripts to generate results page for user. • If unvalidated user data is included in results page (e.g. no HTML encoding), client-side code can be injected into this page. • Code will execute with permissions of trusted server. • Typical examples where client input is reflected: Search forms, custom 404 pages.

19. applet with malicious instructions Reflected XSS ‘Field:’ ‘text’ instr. Field: text [instr.] trusted zone Field: … [instr.] firewall Malicious instructions encoded as data attacker.com untrusted zone

20. Stored XSS • Stored, persistent, or second-order XSS. • Data provided to a web application is stored persistently on server (in database, file system, …) and later displayed to users in a web page. • E.g., bulletin board type applications. • Every time the vulnerable web page is visited, the malicious code gets executed; attacker needs to inject script just once.

21. Threats • Execution of code on the victim’s machine. • Cookie stealing & cookie poisoning: Read or modify victim’s cookies. • Execute code in another security zone. • Execute transactions on another web site (on behalf of a user). • Compromise a domain by using malicious code to refer to internal web pages.

22. Defences • Ultimate cause of attack: Client only authenticates ‘the last hop’ of the entire page, but not the true origin of all parts of the page. • Defence 1: Do not rely on the same origin policy; try to differentiate between code and data instead. • Filter client inputs, sanitize server outputs, escape dangerous characters.

23. Escaping – a ‘counterexample’ • Addslashes (defence against SQL injection) and the GBK character set (Simplified Chinese). • 0xbf27 is not a valid multi-byte GBK character; as single-byte characters: 0xbf followed by 0x27 ('). • Add a slash in front of the single quote: 0xbf5c27. • This is the valid multi-byte GBK character 0xbf5c followed by a single quote … • Source: Chris Shiflett http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

24. DOM-based XSS • Objects like document.URL in the DOM are not retrieved from the HTML received from the server but represent the browser’s view of the current URL. • Attacker creates page with malicious code in the URL and a request for a frame on a trusted site; the result page returned from the trusted site references document.URLin the DOM. • When the user clicks on link to the attacker’s page, the client’s browser stores the bad URL in document.URL and request the frame from the trusted site. • Script in results page references document.URL; in this way the attacker's code will also be executed.

25. Dome-based XSS applet that refers to URL malicious code bypasses checks filter inputs sanitize outputs trusted zone malicious code in URL firewall Request for ‘innocent’ web page attacker.com untrusted zone

26. Cookie Stealing • Web cookies stored at client in document.cookie. • Should only be included in requests to the domain that had set the cookie. • In a reflected XSS attack, the attacker’s script executing on the client may read the client’s cookie from document.cookie and send its value back to the attacker. • No violation of same origin policy; the script is executed in the context of the attacker’s web page.

27. Stealing More … • Web page vulnerable to XSS can be used to capture data from ‘secure’ pages in the same domain. • Script in XSS attack opens (almost) invisible window linked to target page in the client’s browser. • E.g. page that takes over the entire browser window and opens an inline frame to display target page, • E.g. pop under window with link to target page that sends itself to the background. • Rogue window has access to DOM of target page and can monitor the user’s input. • Endpoint of channels at the client: DOM in browser. • DOMs of linked pages can connect channels.

28. Defences • Defence 2 – Authentication: Server sends unpredictable one-time URLs to client during session establishment. • Server can then recognize these URLs as ‘its own’ and authenticate requests as originating directly from the client. • One-time URLs have to be stored in a safe place at client (e.g. private variables of a JavaScript object.) • Source: Martin Johns: SessionSafe • End points of channel at client: Application.

29. Cross site request forgery(XSRF)

30. Cross-site request forgery • XSRF exploits ‘trust’ a website has in a user to execute malware at a target website with the user’s privileges. • Parties involved: Attacker, user, target website (victim). • User is authenticated at target website (cookie, authenticated session,…). • The user has to visit the attacker’s webpage, which contains hidden malware, e.g. in an HTML form.

31. XSRF attack • When the user browses this page, the page automatically submits the form data using to a target site where the user has access. • Target authenticates request as coming from user; form data accepted by server since it comes from a legitimate user. • Evades target’s origin based security policy.

32. XSRF authenticated tunnel user target system Form … <instr.> firewall Malicious instructions in web form attacker.com untrusted zone

33. XSRF defences • Ultimate cause of attack: The server only authenticates ‘the last hop’ of the entire page, but not the true origin of all parts of the page. • Server initiated defence: Authenticate requests at the level of the Web application (‘above’ the browser). • Server sends secret (in the clear) when session is being established. • Application sends authenticators with each action: • XSRFPreventionToken, e.g. HMAC(Action_Name+Secret, SessionID); • Random XSRFPreventionToken or random session cookie.

34. XSRF defences • Client-side only defence for HTTP layer sessions: • Proxy between browser and network marks all URLs in incoming web pages with an unpredictable token; keeps a database associating tokens with domains. • Proxy checks all outgoing requests: • If a token is found, the request did not originate in the client. • Proxy then checks whether its origin matches the domain the request is sent to. • Otherwise, all authenticators (SIDs, cookies) added by the browser are stripped from the URL. • Source: Martin Johns, RequestRodeo.

35. JavaScript hijacking

36. Web 1.0 & Web 2.0 browser browser Javascript HTML+CSS data Ajax engine HTML + CSS data HTTP request HTTP request XML data, JSON web server web server backend systems backend systems

37. JavaScript hijacking (Web 2.0) • Related to XSRF, but discloses confidential data to attacker; bypasses same origin policy. • Features exploited: • Ajax engine at client side sitting between browser and web server; performs many actions automatically. • Web 2.0 applications may use JavaScript (JSON) for data transport; the main issue is not the data format but the decoding of application payloads.

38. JavaScript hijacking – phase 1 • User has visits attacker’s web page that contains malware. • Attacker’s page includes data from the target application in its web page (in a script tag). • Client browser will get this data using the user’s current cookies/session (assuming that a session is open.) • So far same attack pattern as in XSRF.

39. JavaScript hijacking – phase 2 • Attacker’s malware written to override the object constructor in the client’s AJAX engine. • When the server’s JSON result page is processed at the client, the modified object constructor is invoked and sends the secret data to attacker. • This execution is performed in the context of the attacker’s web page; thus it is permitted to send the captured data back to attacker.

40. JavaScript hijacking – defence • Defences against phase one: Same as for XSRF. • To defend against phase two, change execution flow at client. • Server modifies the JSON in its response so that it will not be directly executed by the browser: • Prefix message with while(1); to cause an infinite loop. • Put message between comment characters. • Prefix/comment removed by application; secret is thereby processed in the context of the application. • The malicious web page cannot remove the block. • Client side end point of channel: Application.

41. DNS Rebinding Attacks

42. DNS rebinding • Web browsers enforce same origin policy: Applet can only connect back to the server it was downloaded from. • To make a connection, the client’s browser needs the IP address of the server. • Authoritative DNS server resolves ‘abstract’ DNS names in its domain to ‘concrete’ IP addresses. • The client’s browser ‘trusts’ the DNS server when enforcing the same origin policy.

43. Trust is Bad for Security!

44. DNS rebinding attack • “Abuse trust”: Attacker creates attacker.com domain; binds this name to two IP addresses, to its own and to the target’s address. • Client downloads applet from attacker.com; applet connects to target’s IP address; permitted by same origin policy. • Defence: Same origin policy with IP address. • D. Dean, E.W. Felten, D.S. Wallach: Java security: from HotJava to Netscape and beyond, 1996 IEEE Symposium on Security & Privacy.

45. DNS rebinding attack • Next round: Javascript, 2001. • Client visits attacker.com; attacker’s DNS server resolves this name to attacker’s IP address with short time-to-live. • Attacker rebinds attacker.com to target’s address. • Malicious script connects to attacker.com; binding has expired; browser asks again and now gets the target’s address. • Defence: Do not trust server on time-to-live; keep time yourself and pin host name to original IP address. • J. Roskind: Attacks against the Netscape browser. in RSA Conference, April 2001.

46. DNS rebinding attack • Attacker takes its application server offline; connection attempt by the malware fails. • The client’s browser might then drop the pin for that server and go back to the attacker’s DNS server to get the ‘correct’ IP address for the application server ... • Lesson: Error handling is security critical.

47. DNS rebinding attack • Next round: Browser plug-ins that do their own pinning. • More sophisticated authorisation system: Client browser refers to policy obtained from DNS server when deciding on connection requests. • Dangerous constellation: • Communication path between plug-ins. • Each plug-in has its own pinning database. • Attacker may use the client’s browser as a proxy to attack the target.

48. Defences • Centralize security controls; one pinning database for all plug-ins; e.g., let all plug-ins use the browser’s pins. • Do not ask DNS server for the policy but the system with the IP address a DNS name is being resolved to. • Similar to reverse DNS lookup. • Similar to defences against bombing attacks.

49. Conclusions • You cannot enforce a security policy if you cannot authenticate the attributes it refers to. • What precisely is the end point being authenticated? • Terms like ‘Alice’ and ‘Bob’ or ‘server’ and ‘client’ are too imprecise. • Challenge: How to authenticate the location a data item came from? It might have travelled a long way. • Challenge: How to authenticate location without a suitable infrastructure? • Know thyself and double check?

50. What to look out for? • Mashups, web feeds, and syndications. • With same origin policies the fun is just starting. • HTTP access control headers for cross-domain policies. • AJAX cross-domain policies. • Who will set those policies? • Who will enforce those policies?