W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: Proposal: Prefer secure origins for powerful new web platform features

From: Chris Palmer <palmer@google.com>
Date: Fri, 27 Jun 2014 16:50:25 -0700
Message-ID: <CAOuvq22HNT_gWBLQvqAktRt9NRrni8aRVh3Svf+FWbrk8rmTew@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>, Alex Russell <slightlyoff@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, blink-dev <blink-dev@chromium.org>, security-dev <security-dev@chromium.org>, dev-security@lists.mozilla.org
On Fri, Jun 27, 2014 at 4:29 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote:

> I think it's a reasonable proposal, provided that we apply the rules
> judiciously. This can be a tad tricky: credentials are listed as an
> example, but if we ever come up with an authentication API that offers
> better security properties than cookies, I do not think it would be
> wise to make it available only to HTTPS origins.

Agree. Let's imagine that I said "...handles credentials that are as
powerful as current ones like cookies, or moreso". If we get a *less*
powerful credential system, e.g. such that theft of it over non-secure
transport is not fatal, that'd be great and it might make perfect
sense to expose it to non-secure origins.

The whole idea is very case-by-case.

> Now, in some ways, it feels that the ship has sailed - microphone,
> camera, accelerometer, and geolocation APIs aren't HTTPS-only, and
> neither are password managers and cache manifests. This makes it a bit
> harder to draw the line: should we aim strictly not to make things
> worse, or to design a new breed of APIs that will hopefully one day
> make the legacy ones obsolete?

First, I dream of strictly not making things worse; and then perhaps
(over the course of eons) deprecating non-secure support for e.g.
cameras and mics. I have no illusions that rolling back existing
functionality will fly in the short term — nobody panic. :) And, yeah,
perhaps awesomer APIs will supercede existing ones. Time will tell.

> A somewhat tangential concern that I think we are neglecting with the
> ever-more-powerful privileged APIs is the near-certainty of XSS
> vulnerabilities; the platform offers a growing number of opportunities
> for origins to be persistently backdoored, and no clean way to recover
> from a transient XSS bug. I think that sooner or later, we will need a
> mechanism for servers to nuke or disavow any cached or currently
> running content associated with their origin, and start anew.

Indeed, there is a notion like that for Service Workers already, for
exactly this type of reason. Clients are to cache SW scripts, but are
required to re-check after a certain max-lifetime interval. Alex
(explicitly CC'd) can provide details.

> I think the inclusion of file:/// is somewhat problematic, since it is
> not implied that the content arrived over a secure channel,

Right. "But it's here now." Perhaps we should take file: off the list,
perhaps we should find some way to tag files as having come from
secure transport, or... People should feel free to comment on the
Chromium bug, too
(https://code.google.com/p/chromium/issues/detail?id=362214).

> and the
> mixed-content behavior is also not well specified.

Right. mkwst, others, and tangentially me are working on tightening it
up for reasons like this.
http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0214.html

> The localhost case
> may be also problematic because some quasi-popular software is known
> to set up webservers bound to 127.0.0.1 (I think I've seen some
> anti-virus software, RAID tools, and print daemons do that).

Yes; those are similar to the file: case, but such a thing is
definitely already in a user's TCB (whether good or bad). I sort of
think that clarifies the issue somewhat. But also we definitely would
like to help developers running a local test server out, just a bit.
Received on Friday, 27 June 2014 23:50:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC