Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP OWASP – Browser Security Roberto Suggi Liverani Security Consultant Security-Assessment.com 3 September 2008

OWASP Who am I?  Roberto Suggi Liverani  Security Consultant, CISSP - Security- Assessment.com  4+ years in information security, focusing on web application and network security  OWASP New Zealand founder/leader 2

OWASP Agenda  Introduction  A look to the present  The potential risks  Some challenges  HTML 5.0  WebApps (XHR)  Browser Plugins  OWASP approach to the problem  OWASP Intrinsic Group 3

OWASP Introduction  Present: web security focus is mainly on web apps rather than browsers  But: browser bugs affect much more users than web application bugs 4

OWASP Introduction  Browsers statistics from w3schools.com  JavaScript statistics 5

OWASP Introduction  The risks are not just in the numbers…  Do you remember “On the job browser exploitation” talk of Mark Piper?  Technologies evolve:  HTML5  XHR  Browser Plugin  Current browser security progress mainly focused on:  Reflected XSS filtering and CSRF protection  Phishing web sites detection 6

OWASP Next Challenges  HTML5 (W3C working draft)  New features with a security impact:  Origin-Policy  Browsing contexts and navigation  Custom protocol and content handlers  Structured client-side storage  Offline Web applications  Cross-document messaging  Server-sent events  Web sockets 7

OWASP HMTL5  Relaxing Origin-Policy:  Window objects origin-policy exceptions:  Location object  postMessage()  frames attribute  XXX4 method 8 y.hello.comx.hello.com XSS Injection document.domain = hello.com Communication between 2 subdomains through XSS

OWASP HTML5  Browsing Contexts and Navigations  Opener browsing context – 1.COM  Auxiliary Browser Context - 3.COM  Nested browser context - 2.COM 9 Malicious Third party 3.COM (b) Iframe injection src=2.COM 1.COM (vulnerable) Cross Context Scripting between 2.COM and 3.COM (a) Injection in 1.COM of document.open pointing to 3.COM

OWASP HTML5  Custom Protocol and content handlers  registerProtocolHandler() – ftp:, fax:, foo:  registerContentHandler() – MIME type, text/foo 10 A.COM B.COM navigator.registerCont entHandler(‘text/foo', ‘foo?url=%s', ‘foo') Download Test.foo served as text/foo redirection to: b.com/test.foo

OWASP HTML5  Hijacking content or protocol handlers  navigator.registerProtocolHandler(‘HTTPS', ‘foo?url=%s', ‘foo')  Register Spamming  Site tries to register multiple protocol/content handlers  Multiple sites try registering video/mpeg content  Leaking Intranet URLs  User registers a certain content handler (text/foo)  User clicks  User redirected to external site which handles text/foo  Leaking HTTPS  User redirected to site with HTTPS URL  Leaking credentials in GET Request 11

OWASP HTML5  Structured Client Storage  sessionStorage (adds data to the session for all pages under same domain)  localStorage (adds complex data to client’s cache)  Methods: getItem(), setItem()  Only protection: origin policy  SQL, yes SQL!!! – to store more structured data  Methods: openDatabase(), executeSQL()  Objects: SQLResultSet, SQLResultSetRowList, SQLError  More to come on “browser SQL injection”… 12

OWASP HTML5  Client Storage Attack Example (A. Trivero)  Browser SQL Injection Example (A. Trivero)  Cross-Directory Attack  XSS in can read/write data from/to  User Tracking - UI put in client-storage in multiple sites (marketing, botnet, etc.)  Cookie Resurrection 13

OWASP HTML5  Offline Web Applications  Extensive Application Cache API   HTTP response with text/cache-manifest MIME type for manifest  Manifest specifies how specific site content should be cached = application cache policy  New items can be added to specific cached content with method add()  Different versions of cached content for the same site  Application Cache status can be queried:  Uncached, Idle, Checking, Download, Updateready 14

OWASP HTML5  Application Cache Poisoning  A.COM’s manifest allows caching of vulnerable HTML page containing DOM XSS  DOM XSS manipulates data when viewed in off-line mode  Attacking offline browser  Off-line application cache content with stored XSS that sets navigator.onLine=TRUE 15

OWASP HTML5  Cross Document Messaging  “While this (origin policy) is an important security feature, it prevents pages from different domains from communicating even when those pages are not hostile” – 7.4 W3C HTML5 current draft  postMessage(message, messagePort, targetOrigin) 16 window.addEventListener('message', receiver, false); function receiver(e) { if (e.origin == ' { if (e.data == 'Hello world') { e.source.postMessage('Hello', e.origin); } else { alert(e.data); } } } A.COM B.COM var o = document.getElementsByTagName('iframe')[0]; o.contentWindow.postMessage('Hello world', ' NOTE: this condition can be omitted or = *

OWASP HTML5  Server-Sent Events  Dispatching DOM events into document that expect it  RemoteEventTarget used to fetch data sent as EventStream (text/event-stream) from:  Same site  Allowed sites (XHR access control)  17 data: data: data: EventStream PULLS

OWASP HTML5  Next generation web botnet – C&M interface 18 BOTNET badsite.com/ evil.php Stored XSS in botnet websites: Data Stream (MIME: text/event-stream) Data: wait();\n Data: document.write(<img src=‘ Botnet operates following XHR access control for data exchange

OWASP HTML5  Web Sockets – websocket(url);  Botnet scenario applies as well 19 Client at 123.comServer at aa.com GET ws://aa.com/ HTTP/1.1 Upgrade: WebSocket Connection: Upgrade Host: 123.com Origin: Authorization: Basic d2FsbGU6ZXZl HTTP/ Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: WebSocket-Location: ws://aa.com:80/ Data Framing Read/send data byte per byte Data Framing Send/read raw UTF8 data byte per byte Close TCP/IP connection – no handshake

OWASP WebApps (XHR)  XHR Access Control (GET and POST) 20 Resource: aaa.com/test.txt Client: bbb.com JavaScript + XHR: new client = new XMLHttpRequest(); client.open("GET or POST", " client.onreadystatechange = function() { /* do something */ } client.send() HTTP Response: Access-Control-Allow- Origin: Hello World! GET NOTE: the entire access control system relies on HTTP headers So what happens with an HTTP Splitting Attack? JavaScript + XHR: new client = new XMLHttpRequest(); client.open("GET or POST", " ss-Control-Allow-Origin: client.onreadystatechange = function() { /* do something */ } client.send()

OWASP WebApps (XHR)  XHR Access Control (Other HTTP methods) 21 Resource: aaa.com/test.txt Client: bbb.com JavaScript + XHR: new client = new XMLHttpRequest(); client.open(“OPTIONS", " client.onreadystatechange = function() { /* do something */ } client.send() HTTP Response: Access-Control-Allow- Origin: Access-Control-Max- Age: Preflight Request: OPTIONS JavaScript + XHR: new client = new XMLHttpRequest(); client.open(“DELETE", " client.onreadystatechange = function() { /* do something */ } client.send() DELETE NOTE: the entire access control system relies on HTTP headers

OWASP XHR Alternative – XDR (Xdomain Request)  Cross-domain request developed by Microsoft 22 Resource: aaa.com/xdr.txt Client: bbb.com JavaScript + XDR: xdr = new XDomainRequest(); xdr.open(“GET", “ HTTP Response: XDomainRequestAllo wed=1 Hello! GET HTTP Request: GET /xdr.txt XDomainRequest: 1 Host: bbb.com NOTE: the entire XDR relies on HTTP headers

OWASP Browser Plugins  Adobe Flash  LSO (Local Shared Objects)  Cookie system completely managed by Adobe  100KB cache data allowed by default  Third Party LSO are allowed by default (100kb cache)  LSO data stored and accessed “stealthily”  Typically stored in:  C:\Documents and Settings\[username]\Application Data\Macromedia\Flash Player  Files in the format.sol  This “feature” has already been exploited:  United Virtualies -> PIE (Persistent Identification Element)  Creates a unique ID for each browser and then stores in LSO 23

OWASP Browser Plugins  ActionScript FileReference.Download bypasses browser security settings  IKAT’s Paul Craig 0day technique to bypass kiosk software protection (IE’s security model)  Something like: 24 test.addEventListener(MouseEvent.CLICK, downloadFile); var fileRef:FileReference = new FileReference(); function downloadFile(event:MouseEvent):void { fileRef.download(new URLRequest(" “file.html"); }

OWASP OWASP Intrinsic Group  Aid browser vendors, framework vendors in addressing current security issues  Focus on:  HTML5 Working Group  XMLHTTPRequest  Webapp Working Group  Mozilla Firefox  Adobe (AIR/Flash)  Microsoft IE7  Microsoft.NET  Struts  Spring  Apache Commons  Soon: OWASP Top Ten Browser Security 25

OWASP Questions?   

OWASP References  HTML5   XHR and XHR Level 2    Access Controls XHR   XDR    LSO    s_manager07.html   27

OWASP References  HTML5 - Presentation   Abusing HTML 5 Structured Client-side Storage   Web Stats   Browser Stats  28