Re: [credential-management] Risk in same origin and SSL/TLS requirements

Thanks Keiji! This is an interesting discussion.

On Wed, May 13, 2015 at 5:39 PM, Keiji Takeda <tkeiji@w3.org> wrote:

> 1 Attack from Same Host
> There have been cases that different web services share a same server
> (host name) and cases that different site owners share a same server.
> In such case user's passwords have possibility to be stolen from pages
> or services run by other users of service using same host name.  Example
> of such cases include services run on web hosting service or web sites
> hosted on shared resource such as a server in universities.
> This attack feasibility depends on how a user agent defines "same
> origin."  If a browser recognize different pages (with exact directory
> and file name) on a same host as not same origin this issue would not
> happen.
>

0. As Brad noted, shared servers (and, in general, places where the
same-origin policy is too lax) are dangerous in general. It's not clear
that we'd be able to come up with a reasonable suggestion for changing this
policy in the context of this particular API, and further unclear that
doing so would in fact be helpful.

1. As Brad noted, Joel is on the hook to address at least some of this
issue with a proposal for per-page suborigins. (CCing Joel. Hi Joel.)

2 Cross Site Scripting (Script Injection?)
> Restricting "send(url)" method to send only same-origin endpoint seems
> work well as a countermeasure for stealing password by exploiting cross
> site scripting vulnerability.  In the scenario where an attacker has
> access to the same host to run own code, cross-site scripting
> vulnerability would allow password leakage through the cross-site
> scripting.


XSS is a separate threat from what this document attempts to address on its
own, and is better dealt with via Content Security Policy and other
hardening measures. We note this obliquely at the end of section 6.1, but
I'll be more explicit about the risk of XSS:
https://github.com/w3c/webappsec/commit/76d883363d462e2bdaaaeb793de62e656ea71b26
.

Again, if a browser recognize different pages (with exact directory
> and file name) on a same host not as same origin this issue would not
> happen.
>

As Brad noted, Joel is on the hook to address at least some of this issue
with a proposal for per-page suborigins. (CCing Joel. Hi Joel.)

3 Password in Plain Text
>

The intent here is that the API defined in the document will not be
available over unauthenticated/unencrypted connections, and that
credentials like passwords will not be sent out over
unauthenticated/unencrypted connections.

The cross-origin leakage discussion is a nod to the status quo, where
password managers embedded into a number of user agents do indeed store and
autofill passwords into insecure contexts. From a usability perspective,
this behavior is probably a usability win (as, ideally, users will still be
quasi-protected from phishing, as passwords won't be autofilled into `
http://totally-your-bank.com/`). It's not something I think this API should
support, however, and it ought to be clear that even if a user agent
decides to support insecure origins, that passwords MUST NOT be filled into
those origins from secure origins. That would break a number of guarantees
that the system ought to uphold.

I'll clarify this in the text, as you're correct to note that it currently
doesn't make much sense. Does
https://github.com/w3c/webappsec/commit/f1de80a46c63ab41a7a072686488db3a14f36229
help?

--
Mike West <mkwst@google.com>, @mikewest

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.)