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: Mon, 26 Sep 2016 21:04:17 +0200
Message-ID: <CAKXHy=deBt3PXpF8RpxSo_ohH+5HppG=zn=OOo8Vp3Jhua6VjA@mail.gmail.com>
To: John Wilander <wilander@apple.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Hey John!

I think this is a pretty reasonable idea. Talking to loopback is pretty
powerful, and I think we've seen a good amount of evidence that it's
dangerous (see Tavis' recent exploits with anti-virus vendors, for example).

I don't have any metrics for accessing private address space or loopback
from a secure context specifically, but based on
https://www.chromestatus.com/metrics/feature/timeline/popularity/530, we
know that the general size of "internal stuff" embedded in public pages is
substantial (~1% of page views). I'd suggest we add some metrics to our
respective user agents before deprecating, but it does seem like the right
thing to do.

As a side note, the CORS-RFC1918 proposal
<https://mikewest.github.io/cors-rfc1918/> actually goes further,
restricting external access to both RFC1918 and loopback to secure
contexts, along with the preflight bits. Given infinite resources, that's
the direction I'd like to see us moving. Microsoft folks seem enthusiastic
about pieces of that proposal. Do y'all at Apple have opinions as well? :)

-mike

On Mon, Sep 26, 2016 at 8:43 PM, John Wilander <wilander@apple.com> wrote:

> Hi WebAppSec!
>
> There’s an ongoing discussion on whether browsers should treat localhost as
> a secure context
> <https://github.com/w3c/webappsec-secure-contexts/issues/43>. Devdatta
> brought up web sockets specifically
> <https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0135.html> 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
> <https://developer.apple.com/safari/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 Monday, 26 September 2016 19:05:11 UTC

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