Re: [widgets] The access element (was: RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec)

Hi Mark,

2009/2/19 Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com>:
> Hi All,
>
> In the email [1] containing my comments against the LCWD of Widgets 1.0:
> Packaging & Configuration spec, I wrote:
>
>>> 7.10 The access Element
>>> The access element defines a network attribute as "A boolean
> attribute
>>> that indicates that the widget might need to access network resources
>
>>> as specified in [Widgets-Security]. "
>>>
>>> Based on this description we would like to make the following
>>> observations and suggestion:
>>>
>>> The access element contains security permissions that will be used as
>
>>> hooks in the yet to be written [Widgets-Security] specification. The
>>> problem is that the permissions haven't yet been discussed in detail
>>> and so we may find that we want to represent additional context other
>
>>> than a black and white "is network access required?". For example, it
>
>>> may be the case that it is important from a security point of view to
>
>>> know which bearer or protocol will be used, or to nest a set of
>>> domains/URLs with which the widget wants to communicate. I do not
> have
>>> a strong view on what might be relevant here, and I am not suggesting
>
>>> that it needs to be considered as part of the last call of the
>>> Packaging and Configuration spec, only that it is likely that the
>>> permission will need to be more complex when we look at it from a
> security perspective.
>
> Marcos replied:
>
>> I think we better start this soon, then. My feeling is that we will
> need some kind of <domain> access declarations, and I would like to see
> them in the > configuration document.
>
> My follow up:
>
> Marcos makes the suggestion that he would like to see the access element
> replaced/extended with domains. Vodafone have come to a similar
> conclusion. We feel that a widget author should be able to declare the
> hosts with which they want to communicate. The widget should then only
> be allowed to communicate with those hosts.
>
> This is beneficial for two reasons:
>
> 1.) It allows the widget author to practice the principle of least
> privilege, limiting the potential attack space

Agreed.

> 2.) It allows other parties (users, widget distributors, consuming
> widget user agents) to inspect the widget to get some idea of who the
> widget will communicate with, thereby enabling more sensible security
> decisions to be made.

Agreed.

> There is however one exception that we would like to enable, the ability
> for a widget author to indicate that their widget might be expected to
> communicate with any host. This is to allow for use cases such as widget
> RSS readers. We would therefore like to propose that the access element
> is extended along the following lines:
>
> <access>
>    <network any-host="true/false">
>        <target host="somehost.com" />
>        <target host="en.anotherurl.com" />
>    </network>
> </access>

Firstly, this assumes communication over HTTP. I think we need to make
this protocol agnostic. How do I indicate I want to use HTTPs? You
would need a special purpose URI parse that can parse malformed URIs.

I propose the simpler:

<access network="true">
     <domain href="URI" />
</access>

The semantics of the URI can be derived from whatever URI type is used
(most likely case will be HTTP, in which case you parse the URI
semantics using RFC2616). User agents can support whatever URIs they
like, or exclude others (e.g., file://).

> Declaring <network any-host="true"/> would mean that regardless of
> whether the network element contained any child domain elements, the
> author was declaring that they wanted access to any host (note that by
> default this value would be "false" so only authors who wanted access to
> any host would be inclined to use it).

I suggest a special case of <domain>:

<domain href="*"/>


> There is IMO an open question as to whether it would better to specify:
>
> 1. full URLs in place of hostnames, eg:
>
> <target url="http://somehost.com" />

>From my point of view, yes... as per the rationale above.

> 2. hostnames (to allow for use of http and https and other protocols
> without requiring multiple declarations), maybe by using an additional
> attribute, eg:
>
> <target host="somehost.com" protocol="http"/>

URIs already define all this, so we don't need to break up the URIs
into their parts. The semantics of HTTP URIs are well understood and
already easily parsed by implementations.

> 3. hostnames + paths (to allow authors to restrict access to specific
> resources)
> <target host="somehost.com" protocol="http" path="/images"/>
>

Would be supported by using URIs:

<domain href="http://somehost.com/images/"/>

OR

<domain href="http://example.com/resource" />

The resource could then be exploited (in a good way) at runtime
through query strings:

<script src="http://example.com/resource?callback=helloThere" >

FWIW, I think we need to look at what CORS is doing with respect to
this and mirror as much as we can:
http://dev.w3.org/2006/waf/access-control/

> Related to the above options is whether or not the omission of protocols
> and paths could/should be specified to mean "any value". This would
> allow a certain degree of flexibility while still allowing the author to
> lock things down if they wanted.

There is also port. Again CORS has dealt with a lot of this, so we
might look there for guidance.

> I would like to also bring it to the group's attention that BONDI have
> also identified this as an issue and have specified something similar to
> the proposal above - see [2] section 3.3.4 - as an extension to the W3C
> configuration document.
>
> Ignoring where the element is located and the additional attributes, the
> main difference between the BONDI approach and the approach that I have
> outlined here is that BONDI does not restrict the widget to only access
> those hosts declared but instead uses the declarations as values to
> evaluate within the security policy. This is an advantage in one respect
> as it allows a lot of flexibility - the policy can restrict the widget
> to only the declared hosts, or the declared hosts plus a whitelist of
> safe hosts etc, and can also control whether or not wildcarding is
> allowed.

Agreed. This seems like a good idea, but it should together with the
solution we define in the spec.

> However, I would argue that the BONDI approach also presents a
> significant disadvantage, namely that in relying on the security policy
> of the consuming device to interpret the declared targets, the behaviour
> is unpredictable for the widget author, distributor and potentially the
> user.

Agreed.

> This is the main reason that I am not suggesting that the BONDI
> approach is adopted as is. I will also cross post this email to the
> BONDI list to get feedback. Speaking from a Vodafone perspective and as
> someone who participates in both W3C WebApps and BONDI, ideally we would
> like to see the solution specified in W3C and then simply referenced in
> BONDI. With BONDIs current specifications being at Candidate Release
> status until the 9th March there is still a good opportunity to achieve
> this kind of alignment.

BONDI's approach sounds implementation specific, which might be ok.
Like you outlined, it does have significant disadvantages.

> I realise that it's late in the day to be specifying new elements but I
> think there are real advantages to extending the access element in the
> way proposed and it addresses a real use case.

No it's cool. We've known about this issue from the beginning (As the
P&C spec originated from Opera, there was something similar to what
you are proposing in the very first draft of this specification. See
the <access> element in the following link:
http://dev.opera.com/articles/view/opera-widgets-specification-1-0/#xmlsecurityaccess

It was originally in our spec, but we took it out because it was
problematic.... and we (the WG) are still trying to solve the problem!
:) )

Kind regards,
Marcos

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

Received on Sunday, 22 February 2009 16:02:15 UTC