Re: NSD API security

On Fri, Sep 20, 2013 at 1:18 AM, Giuseppe Pascale <giuseppep@opera.com> wrote:
> On Thu, Sep 19, 2013 at 11:00 AM, FABLET Youenn
> <Youenn.Fablet@crf.canon.fr> wrote:
>>In case the WG is not aware, implementation of the NSD API was discussed on various browser engine mailing lists ([1], [2], [3]).
>>Interesting feedback related to security issues was brought up.

>> Second, a granted local service is exposed to receiving and processing any
>> kind of data from a given web page.
>>
>> Local services are often weak in terms of security (not regularly patched
>> for instance, [4]).
>>
>> This may enable new hacking possibilities through tweaked HTTP requests
>> (XML/SOAP payloads or arbitrary data e.g.).
>>
>> Solving both kinds of issues through a single user permission UI was
>> perceived as too complex and error-prone.
>
> This issue was raised already 2 years ago when this spec was presented
> to the DAP group for the first time, and I actually tend to agree with
> those concerns. I suspect we need to consider "dropping" the "support
> for legacy devices" requirement, at list when this API is used in a
> normal web browser, i.e. in absence of a security model that can
> guarantee that the API is not abused.

I tend to agree with the concerns and your conclusion here, Giuseppe.

>
> What we could consider is to provide a way for services to "opt-in"
> for being exposed to web apps.
> Opting-in would mean that only devices/services designed and
> implemented with this use case in mind will be exposed.

That seems like the most reasonable proposal.

>
>
>>I do not know much about the possibilities on hacking through tweaked HTTP requests.
>>This potential threat, especially for legacy devices, weakens the idea of whitelisting granted local services.
>>Also, getting access to a discovered local service can already be done using existing approaches:
>>
>> -          packaged web applications/extensions may get permissions to do
>> cross-origin requests
>>
>> -          CORS may be implemented in future local network services
>>
>>
>
> The whitelisting was defined in order to support legacy devices. If
> people believe that supporting legacy devices (in normal conditions)
> is too risky anyway, we can probably drop the whitelisting feature and
> go for CORS. In other words, if you need to change your service in
> order to opt-in for being exposed, you can also change it to support
> CORS.

FWIW, I've raised the idea of a CORS-only solution a couple of times
here previously [5] [6] (and we've discussed informally as a group on
other occasions also) but we had not yet formulated a full practical
solution.

So there are a number of directions we could take this in:

1. Focus the specification around a CORS-only solution. CORS is an
accepted mechanism to allow cross-origin communication on the web and
could work well in the local network environment also. The problem
with adopting a CORS-only approach is we have zero devices currently
ready to step in to this brave new world with us. A specification that
allows you to connect with precisely zero network services will not be
useful.

2. Support whitelisting of specific local network services in the user
agent, at the user's request to enable communication with those
services. Even if we went with a CORS-only approach (see (1.) above),
this could be a practical fallback to support existing/legacy network
services. This would provide non-CORS-enabled services with the same
privileges as CORS-enabled services from the user agent without the
service itself needing to support CORS implicitly (as also proposed in
the current NSD API specification).

3. We could support blacklisting of local network services in the user
agent ([7]). The current specification currently 'keys' local network
service API access on its respective network service type identifier
(e.g. 'zeroconf:_boxee-jsonrpc._tcp',
'upnp:urn:schemas-upnp-org:service:ContentDirectory:1', etc). We could
deliberately disable certain service identifiers from being exposed to
web pages. So if the user agent discovers a service whose type
identifier lives in the network services blacklist, it would never be
offered to a web page, even if that web page was attempting to access
that specific service by its given id.

I would prefer a solution that incorporates both (1.)+(2.) above -
where we support CORS as the primary mode for communicating with
local-networked services but still provide a fallback mechanism that
allows users to override that requirement in the user agent - to
interact with non-CORS enabled network services.

Option (3.) has the least impact on the current specification and does
not require any changes to the respective discovery mechanisms of
UPnP, Zeroconf or DIAL (to indicate CORS support). If we are unable or
unwilling to go with a (1.)+(2.) approach then (3.) seems like a
viable shorter-term alternative. We could start creating an initial
blacklist of _bad_ local network services today and incorporate that
list in to the NSD API spec very quickly.

Other proposals would of course be welcome that address the concerns
raised in the original threads ([1] [2] [3]).

>>
>> The discovery part of the NSD API specification seems already in a pretty
>> good shape.
>>
>> The access granting part of the NSD API specification may take more time to
>> mature.
>>
>> Given all of that, would it make sense to split the NSD API specification in
>> two documents?
>>
>
> What I personally think it could make sense is to try and define a
> "secure" version of the full spec, that "loose" the requirement for
> supporting legacy devices and instead assume that discovery protocols
> and services need to be (slightly) changed to opt-in for this feature.
> >From there it should be easy to imagine an extension that people can
> use in other scenarios where they want to support also legacy
> protocols and they are able to secure the user home network via some
> other means).

I think option (1.) + (2.) above could achieve this. If we went with a
CORS-only approach we would possibly also be able to drop the
requirement for user opt-in interfaces on a request-by-request basis
(since it would be the local network services themselves that opt-in
to the communication in the first place _potentially_ negating the
need for users to opt-in also).

So, a more secure spec with less user opt-in UI requirements? Yes, please.

>
> BTW assuming we still want to have an api that works across multiple
> discovery protocols, this group would have to liaise with the groups
> in charge of standardizing such discovery protocols in order to agree
> on a way for services to opt-in for this API.

For HTTP-based discovery mechanisms, it may be sufficient to provide
'Access-Control-Allow-Origin: *' HTTP headers in the network discovery
messages - those can be interpreted by the user agent to mean that
this device/service supports CORS. For DNS-based discovery mechanisms
we would need to figure out another way to do this.

Regardless of the actual solution it would be good if we could get
some discussion going in the respective groups around this
requirement.

---

Thanks for taking the time to start thread, Youenn. Let's discuss
further on practical steps forward here.

br/ Rich

>
> /g
>
>
>>
>> [1]
>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HT0KZKuTLxM
>>
>> [2] http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg23727.html
>>
>> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=914579
>>
>> [4] http://www.upnp-hacks.org/
>>

[5] http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/att-0023/minutes-2013-02-06.html#item04

[6] http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/att-0002/minutes-2013-07-24.html#item05

[7] http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0004.html

Received on Friday, 20 September 2013 07:29:24 UTC