RE: Restrict loopback address to Secure Contexts?

**ONLY** after a CORS Preflight. Any loopback service that responds to an HTTP request for a CORS Preflight and says "yes", clearly wants to talk to untrusted web pages. Let 'em.

I chose my made up example of an altimeter device carefully. Your altitude is not particularly sensitive, why would you hide it from web sites? Even less sensitive (and less redundant to GPS in general) would be a thermometer device and web interface.

-----Original Message-----
From: Devdatta Akhawe [mailto:dev.akhawe@gmail.com] 
Sent: Monday, September 26, 2016 9:37 PM
To: Crispin Cowan <crispin@microsoft.com>
Cc: wilander@apple.com; public-webappsec@w3.org
Subject: Re: Restrict loopback address to Secure Contexts?

Hi

My 2c: it is just plain weird to allow a seemingly powerful feature like connecting to localhost from http sites (insecure contexts) but block it from https sites (secure contexts). So, I am all for allowing that.

Re blocking it from http sites:
@crispin Am I understanding right that you are saying "we should not only allow https sites, but also http sites to connect to localhost"?
You do not have an objection to allowing https sites (secure context) to connect to localhost though (currently blocked by mixed content)?

Re the decision to block or not to block http->localhost: I believe the spec that would most closely cover this is the "requirements for powerful features" spec (https://www.w3.org/TR/2014/WD-powerful-features-20141204/). The question then: is connecting to localhost a powerful feature? One option is to argue that connecting directly is a powerful feature but connecting when explicitly whitelisted isn't a powerful feature. Thus, the end result would be: block access to localhost from insecure sites right now and then allow it only via the CORS preflight opt-in.


cheers
Dev



On 26 September 2016 at 14:03, Crispin Cowan <crispin@microsoft.com> wrote:
> On this, I would vote “no”. The purpose of the CORS preflight is to 
> block random web pages from talking to loopback services that never 
> expected to be talking to untrusted clients, we call these “naïve 
> servers”. So if a service does not opt in by responding to CORS 
> Preflight, then web pages don’t get to talk to it.
>
>
>
> If a service does opt in to talking to web pages, it is up to the 
> service who they want to talk to, and how to authenticate them. There 
> may well be a legitimate scenario to run a local web service that is 
> secure and wants to offer service to any web page that asks. Made up 
> example: suppose I invent a USB altimeter, and I want to offer 
> altitude data to any web page. Just have your web page connect to 
> http://loopback/:41717 (“altit” in l337 speak). So no, I don’t want to 
> block non-secure pages from connecting to compliant CORS Preflighting services.
>
>
>
> “Should native extensions also be allowed” Edge currently does not 
> support native messaging. My personal opinion on whether it should has 
> waffled all over the place, and I cannot comment on Microsoft’s future direction.
>
>
>
> From: wilander@apple.com [mailto:wilander@apple.com]
> Sent: Monday, September 26, 2016 1:39 PM
> To: Crispin Cowan <crispin@microsoft.com>
> Cc: public-webappsec@w3.org
> Subject: Re: Restrict loopback address to Secure Contexts?
>
>
>
>
>
> On Sep 26, 2016, at 12:59 PM, Crispin Cowan <crispin@microsoft.com> wrote:
>
>
>
> Could you clarify? What is your actual question?
>
>
>
> I guess you could boil it down to “Instead of allowing local non-TLS 
> connections in Secure Contexts let’s restrict them to Secure Contexts 
> OR same-origin."
>
>
>
>
>
> My views of an ideal world:
>
> ·         Browsers only allow loopback connection after a CORS Preflight
>
>
>
> Web Sockets instead do a handshake. I assume you mean both CORS 
> preflight and Web Socket handshake should be allowed.
>
>
>
> ·         Browsers vet that “loopback” and “localhost” actually are local
> and not an alias
>
>
>
> Yes.
>
>
>
> ·         Post vetting, browsers treat loopback as a secure connection,
> specifically for this reason that breaks Devdatta’s scenario among 
> many others
>
>
>
> This is what we want to refine. Instead of opening for these 
> connections too we want block local connections from non-secure 
> contexts and only allow local connections from secure contexts. I.e 
> non-secure documents no longer get to access localhost unless they themselves are loaded from localhost.
>
>
>
> Should native extensions or native messaging also be allowed?
>
>
>
> Here I’m not sure what you mean. Are you saying native extensions 
> should not be allowed to talk to local web servers?
>
>
>
> In the case of Safari’s native extensions they are wrapped in signed, 
> sandboxed native applications which they can share data with. The 
> containing app gets user land permissions according to the App Sandbox 
> rules and so it typically wouldn’t need a local web server.
>
>
>
>    Regards, John
>
>
>
> ·         I think “no”. Caveat: I have changed my mind, several times, just
> this year.
>
> ·         I don’t own our extensions model, so what I think is just an
> opinion.
>
>
>
> From: wilander@apple.com [mailto:wilander@apple.com]
> Sent: Monday, September 26, 2016 11:43 AM
> To: public-webappsec@w3.org
> Subject: Restrict loopback address to Secure Contexts?
>
>
>
> Hi WebAppSec!
>
>
>
> There’s an ongoing discussion on whether browsers should treat 
> localhost as a secure context. Devdatta brought up web sockets 
> specifically in March last year. We would like to discuss restriction 
> of the loopback address to same-origin or Secure Contexts. Maybe open 
> up so that a loopback address could connect to any loopback address 
> but that might open up for race conditions.
>
>
>
> Safari treats localhost connections as mixed content and blocks if the 
> content is active. There is a growing number of local companion apps 
> that web pages or browser extensions talk to. I believe the most 
> common setup are local web sockets. We tell developers that Safari’s 
> native extensions are the secure way to go but there are existing 
> companion apps and sometimes a desire for a one-size-fits-all solution for all browsers.
>
>
>
> The network attacker scenario doesn’t make sense for local connections 
> so mixed content blocking is not really appropriate. On the flip side, 
> allowing access to local web servers from non-secure contexts seems 
> really bad. Yes, the server is supposed to check the Origin header but 
> a network attacker can solve that unless the origin the server is checking for is under HSTS.
>
>
>
> What do you think? I know there’s been a lot of discussion on 
> restriction of localhost.
>
>
>
>    Regards, John
>
>

Received on Tuesday, 27 September 2016 05:19:44 UTC