W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: [MIX] Require HTTPS scripts to be able to anything HTTP scripts can do.

From: Joel Weinberger <jww@chromium.org>
Date: Fri, 2 Jan 2015 15:12:04 -0800
Message-ID: <CAHQV2KniMimpgSd2AZZ3PXtm5TcB0ybnSfSkU=E7Kar0urfUmg@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
Cc: Tim Berners-Lee <timbl@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Fri, Jan 2, 2015 at 12:44 PM, Michal Zalewski <lcamtuf@coredump.cx>

> > No script which works when served as http: should fail when instead
> served
> > from https:
> To make sure that we're all on the same page, it may be useful to draw
> a line between two fairly distinct scenarios:
> 1) An HTTP origin attempting to load a script that is served over
> HTTPS. As far as I can tell, in this case, the location from which the
> script is served is essentially immaterial - and the JS code will be
> not subject to any unusual constraints compared to any HTTP-delivered
> counterparts.
> 2) An HTTPS origin attempting to load a script that is served over
> HTTP. This is the scenario that the spec deals with and where browsers
> pull off all the mixed content blocking tricks.
> My initial reading of the proposed one-line addition to the spec
> (specifically, the "served" part) made me assume that the concern at
> the heart of this thread deals with the first use case. But in my
> understanding, this is not something that browsers try to restrict
> today, or that anyone aspires to (?).
> On the flip side, some of the later discussion - in particular, the
> two paragraphs starting with "This means that there is large class..."
> - suggest that the concern may be with the second use case, and that
> it would be preferable to go back to the old behavior where a HTTP
> script loaded on a HTTPS page simply resulted in a warning icon or a
> crossed-out "https://" string in the address bar.
> If it's the latter, I think that the breakage of some subset of web
> applications when migrated to HTTPS is a very valid worry that the
> authors of the spec are acutely aware of.
> Nevertheless, the big security concern with after-the-fact "tainted
> origin" indicators is that by the time they are shown, an
> unsafely-loaded and possibly attacker-modified script is already
> running in the security context of the parent HTTPS page. Because the
> creation of such scripts can happen at any point within an
> already-running application, and their presence can't be determined on
> the initial page load, it's very difficult to retroactively isolate
> the "tainted" execution context and prevent it from accessing any
> previously-entered secrets provided by the user with the assumption
> that they will be safe against network-level attacks.
It's also worth noting that this is something that some user agents already
do today (at least Chrome does; I am not sure of the state of things in
other browsers). While I agree with Tim that this is a concern, and we want
to make sure HTTPS adoption is as painless as possible for users and
developers, on a purely pragmatic level, in Chrome's experience, there have
been extremely few problems with mixed-script blocking. Thus, in some
sense, changing the wording would actually be a regression for some user

And on a personal level, I'm always surprised when I see the mixed
scripting shield *and the page still works perfectly* :-)

> Of course, there are many other ways to compromise the security of
> user data; but mixed content problems are extremely easy to introduce,
> and have been a notorious problem across the web despite browsers
> showing address bar warnings for more than a decade.
> If passive indicators are dangerous, there is always the option of
> giving users the choice to run unsafe scripts. That said, I'd posit
> that it's extremely difficult to explain the implications and have the
> users consistently make the right call.
> /mz
Received on Friday, 2 January 2015 23:12:30 UTC

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