Re: Restrict loopback address to Secure Contexts?

Sorry for the typos.. I clicked send too early :-(

On Tue, Sep 27, 2016, 10:42 Eduardo' Vela" <Nava> <evn@google.com> wrote:

> An attacker that can inject code to talk to 127.0.0.1 van also inject code
> that iframes an https site that talks to 127.0.0.1. Blocking access to
> 127.0.0.1 from HTTP sites doesn't help the user, does it?
>
> The only argument I can imagine is that a 127.0.0.1 web server mistakenly
> allows access from http://onesite.com to fo scare stuff, and such attack
> would be harder to achieve if we force secure origins to talk to local host.
>
> However, there are legitimate use cases for http sites to talk to
> localhost.. so I would rather it was left allowed.
>
> On Tue, Sep 27, 2016, 10:34 Mike West <mkwst@google.com> wrote:
>
> On Tue, Sep 27, 2016 at 9:44 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
>
> 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.
>
> That really depends on whether it is secure or not, no? If we want to
> establish trust in HTTPS and distrust in HTTP, copying insecure
> features from HTTP to HTTPS would be a bad move.
>
>
> I'd argue that talking to loopback is _not_ secure, and that's why we
> ought to (at least) restrict it to secure contexts. It's bad enough that `
> https://totally-authenticated-endpoint.com` can attack your antivirus
> software when you explicitly visit that site. It's significantly worse if
> your coffee shop can do the same when you visit any plaintext site.
>
> -mike
>
>