Mixed Content and `localhost` (was Re: [blink-dev] Intent to Remove Some UI: mixed content shield.)

[Mike West]

-blink-dev to BCC, forking the thread to focus on the `localhost` issue in isolation.

Originally, the mixed content spec included public/private restrictions based on RFC1918. We removed those due to some disagreements in the group, but in my opinion, we ought to be making it more difficult to access internal resources from public hosts, not less.

While I agree with Chris that MIX's threat model doesn't explicitly include `localhost`, I like the behavior, and I'd be sad if we dropped it. We just talked about exactly this at the WebAppSec F2F meetings last week, and that seemed to be the general consensus in the WG.

That said, I totally recognize that it's important for developers, so let's come up with a workaround. I have two suggestions:

1. We already have an "allow mixed content" command-line flag that I forgot about: `--allow-running-insecure-content` (which I know that Chromecast sets, and that we expose via a WebView API, because I wasn't allowed to remove it :( ). Setting that is significantly less dangerous than `--disable-web-security` (though, still not a good idea for everyday browsing).

2. If #1 isn't enough, we could consider `http://localhost` as "secure" for the purposes of mixed content checks iff devtools is open.

Put another way, if we currently didn't have the shield icon, and we were presented with the problem of developers trying to run local code in public sites, I don't think we'd solve it by asking every user if they wanted to be insecure. Let's give developers a targeted, developery solution instead.

-Mike

On Fri, Jul 24, 2015 at 3:40 AM, Elliott Sprehn <esp...@chromium.org> wrote:

On Thu, Jul 23, 2015 at 6:30 PM, Chris Palmer <pal...@chromium.org> wrote:

On Thu, Jul 23, 2015 at 6:19 PM, 'Ryan Sleevi' via Security-dev
<securi...@chromium.org> wrote:

> Considering bugs like http://tomforb.es/dell-system-detect-rce-vulnerability
> are a dime a dozen, probably not. But no need to go round that discussion
> here, other than highlighting why it kinda intentionally (spec and reason)
> doesn't work like you described (yet?), so that someone doesn't think it's a
> good idea to just allow it without security review.

I'm certainly happy to not allow public origins to access private
origins, for that very reason. Of course.

(Someone should draw that graph with Public ... Private on 1 axis, and
Potentially Secure ... Not Possibly Secure on the other. I think we
all think we have it in our minds, but do we really?)

It might be that the best way to enable people to inject script is to
just use an extension. (It makes the most sense to me, in any case.)

But, no extensions on mobile. And, mobile already does not have any
recourse for running mixed scripting. So, we already partly live in
the world Elliott fears.

We could allow users to inject script purposefully, from the Developer
Tools console? Presumably we'd authenticate that the console wasn't
being spoofed, somehow, or gated on a human user gesture, or...

That might work for some cases, but I don't think it works for the major use cases.

Say you're Disqus and you're developing locally, you want to load the local copy into the NYT instead of from production. You support a magical url combo like ?disqus-server=localhost:8080 so you can experiment with loading pages with real production content but that load your third party widget, at the same timing during page load that your widget normally would, but from the local server.

This is an important use case, especially if we're talking about getting third parties to work on improving the impact they have on pages. :) Being able to modify my local copy and reload a real page with the new changes to iterate is important.

I don't think the extension solves this, maybe if extensions could load a service worker to MitM the page it could work.

- E