Re: NSD API security

Thanks for the references to other discussions.
Some people are saying that messaging should be implemented as a way to 
reduce the security risk inherent to allowing discovery, so that 
allowing a web app to communicate with a service does not give the web 
app a blank check to send "anything" at the service. "Anything" is not 
limited to HTTP requests, tweaked or not.
That makes a lot of sense to me, even if it makes the required spec bigger.
Best regards
JC

Le 19/9/13 11:00 , FABLET Youenn a écrit :
>
> In case the WG is not aware, implementation of the NSD API was 
> discussed on various browser engine mailing lists ([1], [2], [3]).
>
> Interesting feedback related to security issues was brought up.
>
> First, fingerprint issues were raised.
>
> These issues may probably be solved by user permission requests and/or 
> data exposure minimization.
>
> Second, a granted local service is exposed to receiving and processing 
> any kind of data from a given web page.
>
> Local services are often weak in terms of security (not regularly 
> patched for instance, [4]).
>
> This may enable new hacking possibilities through tweaked HTTP 
> requests (XML/SOAP payloads or arbitrary data e.g.).
>
> Solving both kinds of issues through a single user permission UI was 
> perceived as too complex and error-prone.
>
> From what I know, research has been done on identifying issues related 
> to protocols and implementations like SSDP.
>
> Since the browser engine is handling the discovery part, the NSD API 
> spec is probably safe there.
>
> I do not know much about the possibilities on hacking through tweaked 
> HTTP requests.
>
> This potential threat, especially for legacy devices, weakens the idea 
> of whitelisting granted local services.
>
> Also, getting access to a discovered local service can already be done 
> using existing approaches:
>
> -packaged web applications/extensions may get permissions to do 
> cross-origin requests
>
> -CORS may be implemented in future local network services
>
> The discovery part of the NSD API specification seems already in a 
> pretty good shape.
>
> The access granting part of the NSD API specification may take more 
> time to mature.
>
> Given all of that, would it make sense to split the NSD API 
> specification in two documents?
>
> Regards,
>
>                 Youenn
>
> [1] 
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HT0KZKuTLxM 
> <https://groups.google.com/a/chromium.org/forum/#%21topic/blink-dev/HT0KZKuTLxM> 
>
>
> [2] http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg23727.html
>
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=914579 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=914579>
>
> [4] http://www.upnp-hacks.org/
>


-- 
Télécom ParisTech <http://www.telecom-paristech.fr> 	*Jean-Claude 
DUFOURD <http://jcdufourd.wp.mines-telecom.fr>*
Directeur d'études
Tél. : +33 1 45 81 77 33 	37-39 rue Dareau
75014 Paris, France

Site web <http://www.telecom-paristech.fr>Twitter 
<https://twitter.com/TelecomPTech>Facebook 
<https://www.facebook.com/TelecomParisTech>Google+ 
<https://plus.google.com/111525064771175271294>Blog 
<http://jcdufourd.wp.mines-telecom.fr>