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

Hi Rich,

> -----Original Message-----
> From: Rich Tibbett [mailto:richt@opera.com]
> Sent: Thursday, October 17, 2013 8:54 AM
> To: Cathy.Chan@nokia.com
> Cc: FABLET Youenn; Igarashi, Tatsuya; Device APIs Working Group; Giuseppe
> Pascale
> Subject: Re: [discovery] DAP-ISSUE-131 Support UPnP device discovery by
> Device Type? (was RE: [discovery] Adding CORS to NSD API - proposal and issues)
> 
> 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.
> 

I agree that user agents should let users select UPnP device(Logical device) for user agreement.  We have another good reason that users can recognize only UPnP device with Friendly Name for such access control management.

In spite of the above agreement, it is not clear why you do not agree that NSD should support searching UPnP device type. Would you explain the reason ?

> 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).
> 

Supporting UPnP device search does not tie in with the issue that local IP address is leaked to web pages. To address the issue, NSD could support aliasing host name for local network address. For example, if the url value of service record is 'http;//192.168.1.2/MediaRenderer/', it would return 'http://networkdevice1/MediaRenderer' to a web application. The web application invokes XMLHTTPRequest with the URL which contains the alias host name and the web application resolve it to actual local network address of service.

If the discovered service is UPnP device as our proposal, the URLs of individual UPnP services are leaked to the web pages but the URLs must be any sub-resources of the url value of discovered service, e.g.  http;//192.168.1.2/MediaRenderer/RenderingControl, http://192.168.1.1/MediaRenderer/AVTransport. The URLs can be accessed by the web pages, but it is  user intent if the user agree on accessing UPnP device. 

If there is another UPnP device on the same physical device, the URL value of discovered service is different, e.g. 'http;//192.168.1.2/MediaServer/'. Another user agreement is required to access another UPnP device for the access control management.

Please note that UPnP device is a logical device and is not a physical device.

Thank you.

-***---***---***---***---***---***---***---***---***--***---***---***-
Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com)
Information Technology Development Div, R&D Platform
Sony Corporation





> - Rich

Received on Thursday, 17 October 2013 06:19:51 UTC