Re: Widget update mechanisms

On 2008-05-06 13:46:25 +0200, Thomas Roessler wrote:

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

You'll also want to include some versioning semantics: If signed
widgets were acceptable, then that could still open up the way to a
downgrade attack (i.e., replacing an installed widget with a known
vulnerable version).  So you'll want to include a widget version
number in config.xml, and force the updateCheck method to verify
that the version number of whatever is downloaded is larger than the
current one.

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

Received on Tuesday, 6 May 2008 11:54:44 UTC