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

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

Received on Wednesday, 13 May 2015 15:39:49 UTC