W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2016

Re: Restrict loopback address to Secure Contexts?

From: Mike West <mkwst@google.com>
Date: Tue, 27 Sep 2016 09:37:11 +0200
Message-ID: <CAKXHy=c6hz4c7xN62tPnm=iS5Yu0-PdVgKuVJvF9MCJM-_Ej2w@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Crispin Cowan <crispin@microsoft.com>, "wilander@apple.com" <wilander@apple.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Sep 27, 2016 at 6:37 AM, Devdatta Akhawe <dev.akhawe@gmail.com>

> 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.

I'm confused about what you're advocating here. :)

My suggestion is that talking to loopback should be treated as a powerful
feature, and we should block non-secure contexts from doing so entirely,
preflight or not. It's simply the case that in the presence of a network
attacker, opt-in is meaningless, as the origin sent with the preflight
isn't authenticated. That is, your coffee shop can inject a request to `` that attacks locally-installed software. Even if that
software tries to constrain itself to a subset of plaintext sites, the
attack vector is both possible and exploitable so long as those origins
don't tunnel over authenticated TLS.

> 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)?

This is not blocked by Mixed Content any more. Based on conversations we
had earlier in the year, we've aligned the definitions such that `` should not be blocked from `https://example.test/`.
That's shipping in Chrome, I believe.

> 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/).

Nit: That's quite out of date.
https://w3c.github.io/webappsec-secure-contexts/ is a more recent reference.

> 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.

I've argued the opposite above. In the same way that we no longer allow
users to opt-in to sharing their geolocation data with plaintext websites,
we should not allow locally installed software to opt-in to talking to the
web in plaintext.

> 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.

I agree that this should be a requirement, but I'd suggest that it's

> > 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
> > Preflighting services.

1. Sharing accurate altitude information with everyone on the web is a
privacy risk (especially given the drift inherent in such measurements).
I'd suggest not doing it. :)

2. If your altimeter is written like anti-virus software, it probably
allows RCE via CSRF. Given the reality of IoT code quality, let's protect
you from your local coffee shop.

Received on Tuesday, 27 September 2016 07:38:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:57 UTC