Re: Widget Security

Hi Thomas,
As with access-control, it would be great to start talking about the
security aspects of widgets in terms of requirements (which we can add
and resolve in the Widgets Req doc before formalizing them in the
Spec). From your previous emails, I derived some draft requirements:

Default security context (or sandbox): the widgets 1.0 spec must
clearly define the security context in which an instantiated widget
operates... for example:
  * no cross-domain request
  * no network access
  * no plugins
  * no local resources access
  * no extended API access (eg. camera, location)
  *  ...

Trusted (digitally signed) security context: the widgets 1.0 spec must
clearly define the security context in which a trusted widget
operates... for example:
  * no cross-domain request?
  * yes network access?
  * no plugins?
  * no local resources access?
  * yes extended API access (eg. camera, location)?
  *  ...

Runtime Security Exceptions: the widgets 1.0 spec must make it clear
when security exceptions must be raised at runtime (and what to do
with those exceptions):

* script loaded from outside the widget tries to change the dom (might
be outside scope, as it is a HTML issue)
* data from XHR from another domain is eval()'d or accessed?

That's just a rough list off the top of my head. Please feel free to
contribute.

Kind regards,
Marcos

On Dec 21, 2007 9:45 AM, Thomas Roessler <tlr@w3.org> wrote:
>
> On 2007-12-05 09:44:29 +0100, Thomas Roessler wrote:
>
> > - Widgets are susceptible to a client-side equivalent of
> >   cross-site-scripting attacks: If data retrieved from the network
> >   is written to the widget DOM in a way that can cause the
> >   uncrontolled creation of elements, then an attacker can once again
> >   take over the widget.
> >
> >   Techniques such as writing to the document using the
> >   Document.write() method or the (not-standard) innerHTML property
> >   are particularly risky.  These should not be used; instead, text
> >   nodes can be created more safely using, e.g., the
> >   Document.createTextNode() method.
> >
> >   Code insertion attacks are also possible when creating attributes;
> >   it is good practice to *not* use data retrieved from the user or
> >   (more importantly) the network when, e.g., constructing event
> >   handlers for an attribute that's dynamically written.
> >
> >   Note that, if widgets run with privileges beyond the traditional
> >   browser sandbox, the results of this attack vector be severe
> >   enough to be a convenient vector for causing a system compromise.
> >
> > The last point is incredibly important (and *very* easy to get wrong
> > when programming in a certain style); I'm currently waiting for a
> > major vendor to fix a bug like this in one of their widgets, and
> > will then have a juicy example to talk about.
>
> The juicy example that I had in mind back then was the Google Mail
> dashboard widget, which could be abused to cause execution of a
> shell script by just sending an appropriate e-mail
>
> Update announcement:
>   http://googlemac.blogspot.com/2007/12/mac-os-x-dashboard-widget-security.html
>
> Technical details:
>   http://log.does-not-exist.org/archives/2007/12/19/2159_more_on_widgets_when_one_email_is_enough_to_break_a_system.html
>
> Happy holidays,
>
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>



-- 
Marcos Caceres
http://datadriven.com.au

Received on Monday, 4 February 2008 05:52:52 UTC