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: <Cathy.Chan@nokia.com>
Date: Wed, 16 Oct 2013 19:37:05 +0000
To: <Youenn.Fablet@crf.canon.fr>, <Tatsuya.Igarashi@jp.sony.com>
CC: <public-device-apis@w3.org>, <giuseppep@opera.com>, <richt@opera.com>
Message-ID: <A46437648ECB3D4F852B077AFF9099F5293354BB@008-AM1MPN2-082.mgdnok.nokia.com>
> 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.)

- Cathy.
Received on Wednesday, 16 October 2013 19:48:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:01 UTC