Re: Widget update mechanisms

On 2008-05-06 13:50:16 +0300, Guido Grassel (Nokia-NRC/Helsinki) wrote:

> For the records, this is my proposal for Widget update (as discussed on the 
> f2f Tuesday morning):

Sorry for not having followed that discussion...

> config.xml includes the domain from where updates are permissible, e.g.
> 	<update domain="nokia.com" />
>
> widget.update (URI) allows a Widget to request the engine to update itself. 
> The domain used in URI must match the one defined in the config.xml.


> 	Note: This is the solution how prevent hijacking the update process of a
> compromised Widget.
> 	e.g. widget.update 
> (http://www.forum.nokia.com/update.php?widget=myWidget,version=201)

So, if there is a cross-site scripting vulnerability on a site that
matches the domain given in the update element, and a vulnerability
in the widget itself, I can now use that combination of attacks to
replace the widget with a malicious version?

So, basically, I'd like to understand better why the information in
config.xml needs to be decoupled from the actual update URI.

Absent good reasons to the contrary, my preferred model would be to
have something like

	<update
  	  uri="http://nokia.com/update.php?widget=myWidget,version=201"/>

in the config file, and a widget.updateCheck() method without any
parameters.

(And yes, I think that having a super-simple update mechanism in the
widget is critical.  Too many of the security problems I see in the
wild occur precisely around update time.)

Also, we'll want to talk about the need for updates to be signed --
either by fetching them through HTTPS, or by verifying a widget
signature.  I'm wary of unattended, insecure updates, as these
constitute another path for leveraging a network attack into a local
one.

> widget.deinstall () allows a Widget to request permanent deinstallation from 
> the system.

Good.

-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Tuesday, 6 May 2008 11:47:00 UTC