RE: Restrict loopback address to Secure Contexts?

I agree that an origin is not to be trusted if it comes via HTTP. However, I disagree that this means that HTTP origins should not talk to loopback services. A loopback service may well *choose* to talk to unauthenticated nobodies. I don’t see the case for blocking that.

From: Mike West [mailto:mkwst@google.com]
Sent: Tuesday, September 27, 2016 12:37 AM
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Crispin Cowan <crispin@microsoft.com>; wilander@apple.com; public-webappsec@w3.org
Subject: Re: Restrict loopback address to Secure Contexts?

On Tue, Sep 27, 2016 at 6:37 AM, Devdatta Akhawe <dev.akhawe@gmail.com<mailto: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/`<https://example.test/%60>. 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<mailto: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