- From: Rich Tibbett <richt@opera.com>
- Date: Thu, 17 Oct 2013 10:53:35 +1100
- To: "Cathy.Chan@nokia.com" <Cathy.Chan@nokia.com>
- Cc: FABLET Youenn <Youenn.Fablet@crf.canon.fr>, "Igarashi, Tatsuya" <Tatsuya.Igarashi@jp.sony.com>, Device APIs Working Group <public-device-apis@w3.org>, Giuseppe Pascale <giuseppep@opera.com>
On Thu, Oct 17, 2013 at 6:37 AM, <Cathy.Chan@nokia.com> wrote: >> From: ext Youenn Fablet [mailto:Youenn.Fablet@crf.canon.fr] >> >> > (2) Access control should be per UPnP device. >> >> +1 >> Presenting devices is more meaningful from a user point of view than >> presenting individual services. >> Maybe that guideline could be stated in the spec. >> >> Also, disclosing one UPnP service to a web app means also disclosing all UPnP >> services of the UPnP device. >> The web app can learn the control URLs of all services on the same device >> from the config field. >> We could filter properly this field, but a smart attacker would probably be >> able to guess the URLs anyway. > Good point. This was not an issue when whitelisting was used for access control, as only the URL of the approved service will be whitelisted. The web app would only be able to access that URL, even if it knows the URLs of all other services on the same device. With CORS though, the web app would be free to try each of those URLs to see if it can gain access. This would not be a problem if access control is on the UPnP device level. (Alternatively, the config information should not be provided to the service objects at all.) I think this is a good reason why user agents should let users select actual devices to share in the user authorisation prompt (e.g. 'My TV', 'My media box'). Even though individual services on those devices would be returned to the web page, it could potentially access other well-known services on well-known URL paths to the same device if CORS is enabled there also. In this model, the user has shared a device with the page and so such usage may be acceptable. 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). - Rich
Received on Wednesday, 16 October 2013 23:54:03 UTC