Re: Restrict loopback address to Secure Contexts?

Oh, I see.. good point.

Wouldn't prerender or a shared or service worker help the attacker here in
any way? Also note that an attacker just needs to navigate the user to his
site for a second and then send the user back, so I don't see it's really a
boundary, unless I'm missing something else.

About legitimate use cases, the one I've encountered is development logging
to localhost from a staging server (but I realize development can be a
setting), another recent example was the original implementation of
"security key" and in my case "tamper chrome" also needs to talk to HTTP
pages from a local web server.

On Tue, Sep 27, 2016, 10:48 Mike West <mkwst@google.com> wrote:

> On Tue, Sep 27, 2016 at 10:42 AM, 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?
>
> An HTTPS site framed in an HTTP top-level site is not considered a "secure
> context" (see
> https://w3c.github.io/webappsec-secure-contexts/#examples-framed for some
> examples).
>
> 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.
>
> I think this is harder to exploit than you're suggesting, given the above.
> The attacker would need to navigate the user to a top-level secure context
> that they control. Totally not impossible, but not as easy or as invisible
> as injecting elements into an existing page.
>
> However, there are legitimate use cases for http sites to talk to
> localhost.. so I would rather it was left allowed.
>
> What kinds of use cases are you thinking of?
>
> -mike
>