Re: [discovery-api] Mitigating real-world device compromise

I am going to set up a joint call with WebAppSec once we have stabilized the specification a bit more (e.g. on the recent device discussion thread from Cathy/Jean-Claude for which I'm awaiting a response from Rich seems fairly major).

(they will not be at TPAC either so it will be a call)

regards, Frederick

Frederick Hirsch
Nokia



On Oct 30, 2013, at 10:50 PM, ext Rich Tibbett wrote:

> On Thu, Oct 24, 2013 at 7:31 PM, Dominique Hazael-Massieux <dom@w3.org> wrote:
>> Le jeudi 24 octobre 2013 à 09:33 +0200, Dominique Hazael-Massieux a
>> écrit :
>>> But it may be that we need to approach that problem at another level: it
>>> certainly feels like the attack we want to protect against is already
>>> readily available without NSD (include an image from well-known local
>>> addresses); NSD may just make it more precise.
>>> 
>>> Maybe this is something we should bring to the WebAppSec WG to get their
>>> input?
>> 
>> As a potential source of inspiration, the Firefox extension NoScript
>> provides module called "Application Boundaries Enforcer" that aims at
>> protecting local network resources:
>> http://en.wikipedia.org/wiki/Noscript#Application_Boundaries_Enforcer_.28ABE.29
>> 
>> Another related piece of work if the (currently abandoned) From-Origin
>> header:
>> https://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html
>> 
>> I'm wondering if browsers should not operate in their own local VPN that
>> would isolate them from the local network setup; they would then be in a
>> position to mediate any access to the "real" local network (e.g. via
>> NSD), and impose by default much stronger access policies.
> 
> While I think some of these have the potential of fixing the problem
> perhaps they also go too far in restricting access completely. I'm not
> sure how that plays with existing local network web content (e.g.
> Intranet systems).
> 
>> 
>> It may be also that this would be informed by more discussions on
>> application-based SOP instead of server-based:
>> http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0954.html
> 
> I liked where this discussion was heading. Right now there's no way to
> isolate [origin + path] combinations but there should be. Solving this
> problem has the potential to also solve our own services isolation
> issue.
> 
> Do you know where this conversation ended up (other threads, forums or specs)?
> 
>> 
>> Another idea:
>> * when obtaining the end point of a given "application" (or service)
>> from the device, the browser receives (via a HTTP header, say
>> Application-Origin) a token that is not exposed to the Web app
>> * the device would then only handle requests for the said app that come
>> with the said token in a request HTTP header (say
>> Sec-Application-Origin)
>> * NSD mediated requests to a service on which the user granted access
>> would be transparently completed with the said token
>> * and on the other hand, the device would refuse to handle any requests
>> made out of band (either from non-NSD mediated requests, or to NSD
>> mediated requested to services for which no consent was granted)
>> 
>> This requires more work from the device-side; but this would provide a
>> lot more protection against existing attacks.
> 
> It may be difficult to convince all device makers to implement this
> although I like the concept.
> 
> Perhaps something similar could be enforced at the user agent level
> and defined in the NSD spec.
> 
>> 
>> But I'm probably way out of my league on this, so again, this is a place
>> where enlisting help from WebAppSec seems like useful.
> 
> Yes, we should get WebAppSec involved here. My main question would be:
> If CORS opens up access to a local network endpoint how could we
> enforce fine-level controls at the individual endpoint service level
> (e.g. per UPnP service)?
> 
> br/ Rich
> 
>> 
>> Dom
>> 
>>>> [1] http://shadow-file.blogspot.com.au/2013/10/complete-persistent-compromise-of.html
>>>> 
>>>> [2] http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0129.html
>>>> 
>

Received on Thursday, 31 October 2013 13:38:45 UTC