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:31:32 +0000
Message-ID: <CAFswPa-z2Qv+yq+TJasDMjQu4sJFV5qsyDJqFqbju1fCDxG3fA@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>
I think I gave extensions examples because I like working with chrome
extensions and apps :) but that's selection bias from my side.

On Tue, Sep 27, 2016 at 11:23 AM Mike West <mkwst@google.com> wrote:

> On Tue, Sep 27, 2016 at 11:01 AM, Eduardo' Vela" <Nava> <evn@google.com>
> wrote:
>
> 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
> embarrassing.
>
> -mike
>
Received on Tuesday, 27 September 2016 09:32:12 UTC

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