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

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.

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

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.

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.

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, 24 October 2013 08:31:20 UTC