Скачать презентацию Internet Web Security Case Study 3 Web
e9d7b1bb086f712590aadcef3d005c25.ppt
- Количество слайдов: 51
Скачать презентацию Internet Web Security Case Study 3 Web
Скачать презентацию Internet Web Security Case Study 3 Web
Internet & Web Security Case Study 3: Web application security Dieter Gollmann Hamburg University of Technology diego@tu-harburg. de 1 NISNet Winter School Finse 2008
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. 2 NISNet Winter School Finse 2008
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. 3 NISNet Winter School Finse 2008
Agenda § § § § Web processing model (simplified) Sessions Same Origin Policy Cross-site scripting Cross-site request forgery Java. Script hijacking DNS Rebinding attack 4 NISNet Winter School Finse 2008
Web processing model 5 NISNet Winter School Finse 2008
Web processing model browser client HTTP request HTML + CSS data web server backend systems server 6 NISNet Winter School Finse 2008
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. 7 NISNet Winter School Finse 2008
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. 8 NISNet Winter School Finse 2008
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. 9 NISNet Winter School Finse 2008
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. 10 NISNet Winter School Finse 2008
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. § 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! Attacker only sees messages addressed to him and data obtained from compromised end systems. 11 NISNet Winter School Finse 2008
Same Origin Policy 12 NISNet Winter School Finse 2008
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. 13 NISNet Winter School Finse 2008
SOP for http: //www. my. org/dir 1/hello. html URL Result http: //www. my. org/dir 1/other. html Reason success http: //www. my. org/dir 2/sub/other. html success https: //www. my. org/dir 2/some. html failure protocol http: //www. my. org: 81/dir 2/some. html failure port http: //host. my. org/dir 2/some. html failure host 14 NISNet Winter School Finse 2008
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. 15 NISNet Winter School Finse 2008
Cross Site Scripting 16 NISNet Winter School Finse 2008
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. 17 NISNet Winter School Finse 2008
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. 18 NISNet Winter School Finse 2008
![Reflected XSS applet with malicious instructions ‘Field: ’ ‘text’ instr. Field: text [instr. ]](https://present5.com/presentation/e9d7b1bb086f712590aadcef3d005c25/image-19.jpg "Reflected XSS applet with malicious instructions ‘Field: ’ ‘text’ instr. Field: text [instr. ]")
Reflected XSS applet with malicious instructions ‘Field: ’ ‘text’ instr. Field: text [instr. ] trusted zone Field: … [instr. ] firewall Malicious instructions encoded as data attacker. com untrusted zone 19 NISNet Winter School Finse 2008
Stored XSS § § Stored, persistent, or second-order XSS. § § E. g. , bulletin board type applications. Data provided to a web application is stored persistently on server (in database, file system, …) and later displayed to users in a web page. Every time the vulnerable web page is visited, the malicious code gets executed; attacker needs to inject script just once. 20 NISNet Winter School Finse 2008
Threats § § Execution of code on the victim’s machine. § § Execute code in another security zone. § Compromise a domain by using malicious code to refer to internal web pages. Cookie stealing & cookie poisoning: Read or modify victim’s cookies. Execute transactions on another web site (on behalf of a user). 21 NISNet Winter School Finse 2008
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. 22 NISNet Winter School Finse 2008
Escaping – a ‘counterexample’ § Addslashes (defence against SQL injection) and the GBK character set (Simplified Chinese). § 0 xbf 27 is not a valid multi-byte GBK character; as single-byte characters: 0 xbf followed by 0 x 27 ('). § § Add a slash in front of the single quote: 0 xbf 5 c 27. § Source: Chris Shiflett http: //shiflett. org/blog/2006/jan/addslashes-versusmysql-real-escape-string This is the valid multi-byte GBK character 0 xbf 5 c followed by a single quote … 23 NISNet Winter School Finse 2008
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. 24 NISNet Winter School Finse 2008
Dome-based XSS applet that refers to URL malicious code bypasses checks filter inputs malicious code in URL 25 Request for ‘innocent’ web page sanitize trusted zone outputs firewall attacker. com untrusted zone NISNet Winter School Finse 2008
Cookie Stealing § § Web cookies stored at client in document. 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. Should only be included in requests to the domain that had set the cookie. 26 NISNet Winter School Finse 2008
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. 27 NISNet Winter School Finse 2008
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 Java. Script object. ) Ø Source: Martin Johns: Session. Safe § End points of channel at client: Application. 28 NISNet Winter School Finse 2008
Cross site request forgery (XSRF) 29 NISNet Winter School Finse 2008
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. 30 NISNet Winter School Finse 2008
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. 31 NISNet Winter School Finse 2008
XSRF authenticated tunnel user target system Form … <instr. > Malicious instructions in web form firewall attacker. com untrusted zone 32 NISNet Winter School Finse 2008
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: Ø XSRFPrevention. Token, e. g. HMAC(Action_Name+Secret, Session. ID); Ø Random XSRFPrevention. Token or random session cookie. 33 NISNet Winter School Finse 2008
XSRF defences § § Client-side only defence for HTTP layer sessions: § Proxy checks all outgoing requests: Proxy between browser and network marks all URLs in incoming web pages with an unpredictable token; keeps a database associating tokens with domains. Ø 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, Request. Rodeo. 34 NISNet Winter School Finse 2008
Java. Script hijacking 35 NISNet Winter School Finse 2008
Web 1. 0 & Web 2. 0 browser Javascript HTML+CSS data Ajax engine HTTP request HTML + CSS data HTTP request XML data, JSON web server backend systems 36 NISNet Winter School Finse 2008
Java. Script 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 Java. Script (JSON) for data transport; the main issue is not the data format but the decoding of application payloads. 37 NISNet Winter School Finse 2008
Java. Script 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. 38 NISNet Winter School Finse 2008
Java. Script 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. 39 NISNet Winter School Finse 2008
Java. Script hijacking – defence § § Defences against phase one: Same as for XSRF. § Server modifies the JSON in its response so that it will not be directly executed by the browser: To defend against phase two, change execution flow at client. Ø 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. 40 NISNet Winter School Finse 2008
DNS Rebinding Attacks 41 NISNet Winter School Finse 2008
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. 42 NISNet Winter School Finse 2008
Trust is Bad for Security! 43 NISNet Winter School Finse 2008
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 Hot. Java to Netscape and beyond, 1996 IEEE Symposium on Security & Privacy. 44 NISNet Winter School Finse 2008
DNS rebinding attack § § Next round: Javascript, 2001. § § Attacker rebinds attacker. com to 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. Client visits attacker. com; attacker’s DNS server resolves this name to attacker’s IP address with short time-to-live. Malicious script connects to attacker. com; binding has expired; browser asks again and now gets the target’s address. 45 NISNet Winter School Finse 2008
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. 46 NISNet Winter School Finse 2008
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. 47 NISNet Winter School Finse 2008
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. 48 NISNet Winter School Finse 2008
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? 49 NISNet Winter School Finse 2008
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? 50 NISNet Winter School Finse 2008
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 § Java. Script hijacking Ø Brian Chess, Yekaterina Tsipenyuk O'Neil, Jacob West: Java. Script Hijacking, 2007 § DNS rebinding attacks Ø Collin Jackson, Adam Barth, Andrew Bortz, Weidong Shao, Dan Boneh: Protecting Browsers from DNS Rebinding Attacks, 2007 51 NISNet Winter School Finse 2008
Скачать презентацию Internet Web Security Case Study 3 Web
e9d7b1bb086f712590aadcef3d005c25.ppt