W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2016

Re: Restrict loopback address to Secure Contexts?

From: Eduardo' Vela\ <evn@google.com>
Date: Tue, 27 Sep 2016 09:01:46 +0000
Message-ID: <CAFswPa98ghyU36p1N9UeuN1=OxKLNN1WAb5-bJB3ijhdRv0pNQ@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Devdatta Akhawe <dev.akhawe@gmail.com>, Crispin Cowan <crispin@microsoft.com>, "wilander@apple.com" <wilander@apple.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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
>
Received on Tuesday, 27 September 2016 09:02:30 UTC

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