RE: NSD API security



> -----Original Message-----
> From: Rich Tibbett [mailto:richt@opera.com]
> Sent: vendredi 20 septembre 2013 09:29
> To: Giuseppe Pascale
> Cc: FABLET Youenn; public-device-apis@w3.org; public-web-and-tv
> Subject: Re: NSD API security
> 
> On Fri, Sep 20, 2013 at 1:18 AM, 
> 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.

+1, a CORS-only solution seems appropriate in the future but access to legacy devices enables already very interesting scenarios.

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

I do not particularly like option 3.
ContentDirectory and Router UPnP services are already embedded in the same device for instance, DSL boxes typically.
If you can corrupt one local service (ContentDirectory e.g.) so that it executes arbitrary code, this local service may be able to attack other local services, routers e.g.

One important security point is to enable control of XHR request generation.
This approach seems worth investigating for legacy devices.

Received on Friday, 20 September 2013 09:12:16 UTC