Re: NSD API security

Dear all,

Looking again at the security-related criticism in the browser lists, I 
just read from the first link (email from Torne, Richard Coles)

" The only way I can think of to close off this kind of attack is to 
have the browser implement the actual protocol to communicate with the 
device as well as the discovery protocol, and only expose task-specific 
interfaces (e.g. information about what specific media is available to 
be streamed, or the actual stream of audio/video data)."

I believe this is exactly what I suggested: do not expose the URL to the 
webpage and implement the messaging in NSD.

Another quote:

" Treating the user's acceptance of a discovery prompt as blanket 
permission for the webpage to send arbitrary data to the device (even if 
it's restricted to "HTTP on a specific port" or similar) is exposing a 
large number of devices that are not really designed with security in 
mind to new sources of attack."

This responds to the proposal to "simply" obfuscate the URLs. I do not 
think it will assuage the fears of these people.

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>