RE: [discovery] DAP-ISSUE-131 Support UPnP device discovery by Device Type? (was RE: [discovery] Adding CORS to NSD API - proposal and issues)

> From: ext FABLET Youenn [mailto:Youenn.Fablet@crf.canon.fr]
> 
> > If this remains an issue we are concerned about then perhaps this
> > actually ties in with another security concern that has been raised
> > recently: leaking network topology information in service endpoint
> > URLs (e.g. providing http://10.0.2.34:4552/... allows a web page to
> > infer the local subnet and can scan that subnet for
> > vulnerabilities/other exposed services). I think we should start
> > looking in to obfuscating these URLs per service when they are
> > returned to web pages (something like
> > 'http://127.0.0.1:5000/<serviceA_GUID>' or 'app://<serviceA_GUID>/' -
> > TBD). One of the requirements of such a system would be that web pages
> > should then not be able to infer or access other services being
> > provided on the same device that have not been requested and
> > authorized by the user (+ this solves the network topology leak/privacy
> security issue raised elsewhere).
> 
> This approach has some disadvantages though.
> URL sharing is made more difficult (think about image browsing on media box
> and then display on TV).

I would assume that such URL obfuscation will only be done (by the UA) on the service URL (controlURL of a UPnP service), and not on the content URLs exchanged between the service itself and the web app. The latter would require the UA to snoop on every single message exchange between the web app and the service and switch out the URLs. I don't think it is in the scope of this work to prevent URL leakage after the discovery phase. With that in mind, and seeing that there's a certain likelihood of URL leakage during the communication phase anyway (at least with services like ContentDirectory), I'm a bit skeptical on the usefulness of obfuscating the URL in the discovery phase. 
- Cathy.

> It also increases UPnP support complexity, which is already bigger than for
> Zeroconf services.
> 
> We may need to follow that path for legacy devices.
> For future devices, it would be best if devices can allocate a name
> themselves, using similar means as zeroconf services.

Received on Thursday, 17 October 2013 22:26:20 UTC