- From: FABLET Youenn <Youenn.Fablet@crf.canon.fr>
- Date: Thu, 17 Oct 2013 07:35:10 +0000
- To: Rich Tibbett <richt@opera.com>, "Cathy.Chan@nokia.com" <Cathy.Chan@nokia.com>
- CC: "Igarashi, Tatsuya" <Tatsuya.Igarashi@jp.sony.com>, "Device APIs Working Group" <public-device-apis@w3.org>, Giuseppe Pascale <giuseppep@opera.com>
> 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). 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 07:36:06 UTC