Re: NSD API security

Youenn,
thanks for starting this thread, I had similar plans but never got
around it. I'm including the webandtv list in CC, since the
requirements for this spec originated from that group (and we are
still discussing similar topics). I hope members of the IG can also
join this conversation

Let me share some of my thoughts:

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.

I'm wondering if we should try to bring all interested people on this
list so that we have this discussion in one place. Maybe I should drop
a link to this thread on those lists?

[...]

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

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.


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

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

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.

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

Received on Thursday, 19 September 2013 15:18:54 UTC