W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: The Emperor's New APIs: On the (In)Secure Usage of New Client-side Primitives

From: Charles McCathieNevile <chaals@opera.com>
Date: Thu, 20 Jan 2011 12:02:30 +0100
To: public-webapps <public-webapps@w3.org>, "Arthur Barstow" <art.barstow@nokia.com>
Message-ID: <op.vplsygjbwxe0ny@widsith.local>
On Mon, 17 Jan 2011 14:16:58 +0100, Arthur Barstow <art.barstow@nokia.com>  

> Hixie recently mentioned to me the following paper from UC Berkeley that
> includes some analysis of the Web Storage [webstorage] and HTML5 Web
> Messaging [webmessaging] specs.
> The Abstract:
> [[
> http://www.eecs.berkeley.edu/~sch/w2sp2010ena.pdf
> Several new browser primitives have been pro- posed to meet the demands
> of application interactivity while enabling security. To investigate
> whether applications consistently use these primitives safely in
> practice, we study the real-world usage of two client-side primitives,
> namely postMessage and HTML5's client-side database storage. We examine
> new purely client-side communication protocols layered on postMessage
> (Facebook Connect and Google Friend Connect) and several real-world web
> applications (including Gmail, Buzz, Maps and others) which use client-
> side storage abstractions. We find that, in practice, these abstractions
> are used insecurely, which leads to severe vulnerabilities and can
> increase the attack surface for web applications in unexpected ways. We
> conclude the paper by offering insights into why these abstractions can
> potentially be hard to use safely, and propose the economy of
> liabilities principle for designing future abstractions. The principle
> recommends that a good design for a primitive should minimize the
> liability that the user undertakes to ensure application security.
> ]]
> I mention this in case this article identifies issues the specs should
> or must address.

Seems to be pretty clear: The design hands some important responsibilities  
to the developer, and developers of extremely-high-profile services from  
extremely-high-profile companies have repeatedly got it wrong. A priori*,  
their suggestions regarding improvements to the way origin checking and  
control over recipients are handled for postMessage seem to make sense...

*I might change that opinion after discussion with security people



Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Thursday, 20 January 2011 11:03:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:16 UTC