1. NISNet Winter School Finse 2008 1 Internet & Web Security Case Study 3: Web application security Dieter Gollmann Hamburg University of Technology diego@tu-harburg.de

2. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 4 Agenda  Web processing model (simplified)  Sessions  Same Origin Policy  Cross-site scripting  Cross-site request forgery  JavaScript hijacking  DNS Rebinding attack

5. NISNet Winter School Finse 2008 5 Web processing model

6. NISNet Winter School Finse 2008 6 Web processing model web server backend systems browser HTTP request HTML + CSS data client server

7. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 12 Same Origin Policy

13. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 14 SOP for http://www.my.org/dir1/hello.html URLResultReason http://www.my.org/dir1/other.htmlsuccess http://www.my.org/dir2/sub/other.htmlsuccess https://www.my.org/dir2/some.htmlfailureprotocol http://www.my.org:81/dir2/some.htmlfailureport http://host.my.org/dir2/some.htmlfailurehost

15. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 16 Cross Site Scripting

17. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 19 Reflected XSS firewall attacker.com untrusted zone trusted zone Field: … [instr.] Malicious instructions encoded as data Field: text [instr.] ‘Field:’ ‘text’ instr. applet with malicious instructions

20. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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.URL in 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. NISNet Winter School Finse 2008 25 Dome-based XSS firewall attacker.com untrusted zone trusted zone applet that refers to URL malicious code in URL sanitize outputs filter inputs Request for ‘innocent’ web page malicious code bypasses checks

26. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 29 Cross site request forgery (XSRF)

30. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 32 XSRF firewall attacker.com untrusted zone target system Form … Malicious instructions in web form user authenticated tunnel

33. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 35 JavaScript hijacking

36. NISNet Winter School Finse 2008 36 Web 1.0 & Web 2.0 web server backend systems browser HTTP request HTML + CSS data web server backend systems browser HTTP request XML data, JSON Ajax engine JavascriptHTML+CSS data

37. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 41 DNS Rebinding Attacks

42. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 43 Trust is Bad for Security!

44. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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. NISNet Winter School Finse 2008 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?

51. NISNet Winter School Finse 2008 51 Resources  XSS: Cross site scripting  CERT Advisory CA-2000-02: Malicious HTML Tags Embedded in Client Web Requests  Writing Secure Code, chapter 13  XSRF: Cross site request forgery  Jesse Burns: Cross Site Reference Forgery, 2005  JavaScript hijacking  Brian Chess, Yekaterina Tsipenyuk O'Neil, Jacob West: JavaScript Hijacking, 2007  DNS rebinding attacks  Collin Jackson, Adam Barth, Andrew Bortz, Weidong Shao, Dan Boneh: Protecting Browsers from DNS Rebinding Attacks, 2007