Re: Restrict loopback address to Secure Contexts?

On Tue, Sep 27, 2016 at 9:43 AM, Crispin Cowan <crispin@microsoft.com>
wrote:

> I agree that an origin is not to be trusted if it comes via HTTP.
>

With that premise, I'd suggest that allowing HTTP arbitrary access to
programs running on your local computer is a dangerous thing to do.


> However, I disagree that this means that HTTP origins should not talk to
> loopback services.
>

I made some arguments against this conclusion in my last email. What do you
think about them?


> A loopback service may well *choose* to talk to unauthenticated nobodies.
> I don’t see the case for blocking that.
>

Do you agree with the case for deprecating various "powerful" features over
plaintext, and/or locking interesting new features to secure contexts? If
so, how is this different?

-mike


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