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

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 02:51:13 UTC