Re: [MIX] localhost should not be trusted

I agree, this was a mistake. The intent was to outline a set of origins
that should be considered 'secure' in general, with the thought in the back
of my head that web-facing access to these origins would be limited in
other ways. The text ended up muddled and confusing, however, and failed
completely to make the point I wanted.

I've responded to a similar point Brian Smith made in
http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0052.html, and
I expect to have an updated draft soonish that clarifies the intent around
non-public origins.

Thanks, Zach!

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


On Wed, Jun 4, 2014 at 11:36 PM, Zack Weinberg <zackw@cmu.edu> wrote:

> The current editor's draft of the Mixed Content spec (
> https://w3c.github.io/webappsec/specs/mixedcontent/#assumed-secure-origin
> ) defines "assumed secure origin" to include data fetched from
> 'localhost' and its various aliases (e.g. 127.0.0.1 and ::1) as well
> as the expected scheme-based determiners (https, wss, file).  I'm not
> sure what browsers actually do, but this is abstractly a mistake, for
> two reasons:
>
> 1) A server on localhost is often used as a development environment.
> Therefore, the set of things treated as mixed-content when the page
> origin is https://localhost/ should be the same as the set of things
> treated as mixed-content when the page origin is
> https://global.domain.example/ .  Any difference between the two
> introduces the potential for mixed-content bugs that go unnoticed in
> development but manifest when deployed.
>
> 2) Treating http://localhost/ (and file://) as secure relative to
> https:// enables (or rather, fails to prevent) attacks where a local
> malicious application infiltrates scripts into a secure website.
> (Suppose the Android or iOS security model, so there *is* a security
> boundary preventing it from just diddling the browser directly.)
>
> zw
>
>
>