Re: Restrict loopback address to Secure Contexts?

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
>