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

Thank you for the comments, Keiji.

On the first two topics, it is out of scope for credential management to
attempt to define security boundaries that are more granular than the Same
Origin Policy.  The Origin is the only enforceable barrier today, many
things depend on it, and there are many ways for an adversary to accomplish
their goals by being same-origin.  Changing just one API would not be
effective.  We are working on ways to provide better isolation for
logically distinct applications hosted on the same domain in the Suborigin
Namespaces deliverable.

On Wed, May 13, 2015 at 8:41 AM Keiji Takeda <tkeiji@w3.org> wrote:

> As personal comments,
>
> The Credential Management API is expected to improve user experience
> over web applications by mitigating burden of users to manage their
> password.  It is also expected to mitigate risk around handling of
> password in such ways that user can easily set stronger passwords and
> send those passwords only to the appropriate sites (same origin) while
> avoiding phishing sites.
> Since the API control user's password, which is quite critical
> information for system security the API may include potential security
> risk.  So it is good to examine with wide variety of risk scenario.
> Here I would like to share some of my thought on the proposed
> specification and possible suggestion for improvement.
>
> 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.
>
> 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.  The attacker can put JavaScript code via cross site
> scripting then let the password to send their own code on server side.
> Possible example of such cases include service run on web hosting
> service or web sites hosted by shared resources such as university web
> sites.
> 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.
> These two are matters of design decision if we accept this kind of risk
> as residual risk or if we want to avoid the risk by having more strict
> same origin policy (including directory and file names.)  It would be
> better to clearly address the risk if the risk is accepted.
>
> 3 Password in Plain Text
> In 6.1. Cross-origin Credential Leakage it says "1. MUST NOT share
> credentials between origins whose scheme components are not the same.
> That is: credentials saved on https://example.com/ will never be
> available to http://example.com/ via get()."  I have read this as
> allowing (there is some possibility ) to send password over insecure
> (non-SSL/TLS) channel.  However, in "6.3. Insecure Sites" it says "User
> agents MUST NOT expose credential information via the APIs defined here
> to environments which are not privileged contexts."  This is read as
> denying to send password over insecure channel.  These are confusing and
> may lead misunderstanding.  It is considered that sending password in
> plaintext is not a good practice and W3C has been addressing "Clear text
> passwords" as "a serious security risk."  Thus if the latter sentence is
> correct the first sentence should clearly state credentials can not be
> sent over non SSL "http."
>
> Keiji Takeda
>
>