Re: Restrict loopback address to Secure Contexts?

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
>