Re: Restrict loopback address to Secure Contexts?

On Tue, Sep 27, 2016 at 6:37 AM, Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> 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 `
http://127.0.0.1` 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 `
http://127.0.0.1` 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
insufficient.


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

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.

-mike