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: Tue, 27 Sep 2016 11:23:10 +0200
Message-ID: <CAKXHy=fKZiba65Pmx5Oj7RS+vf+-Yy5r+z3YVbPS+S-fQDEqiw@mail.gmail.com>
To: "Eduardo' Vela <Nava>" <evn@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>
On Tue, Sep 27, 2016 at 11:01 AM, Eduardo' Vela" <Nava> <evn@google.com>

> Wouldn't prerender or a shared or service worker help the attacker here in
> any way?
Prerender might, depending on how it's implemented. I think we trigger
requests from the new context, so it might be a workaround. Service Worker
might, once Foreign Fetch is a thing. We should probably think about what
it means to service a request from a non-secure context.

Note, though, that authenticated endpoints are easier to blacklist via safe
browsing. If we force the attacker to use a real server with a real cert,
it's significantly more likely that other kinds of mitigation can be
effective. That's not likely to be the case for strict injections.

> 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.
I'm not claiming it's a hard prevention mechanism. It's a mitigation
against the kind of attack. One of many we ought to be exploring.

> 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.
1. Those are both extensions, which are pretty much magical anyway from the
perspective of the platform.

2. Security key should never have shipped as an extension. It's somewhat

Received on Tuesday, 27 September 2016 09:24:01 UTC

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