W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2013

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

From: Rich Tibbett <richt@opera.com>
Date: Thu, 17 Oct 2013 10:53:35 +1100
Message-ID: <CAAsrAZCZRKN_xPpys+hBb5e2f6p5KFFMuDcnaYWC2v7jNhGskA@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:01 UTC