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

Mike and all,

I apologize that it took long time to respond to this reply.

I almost agree with update d versions.

Regarding XSS, I would like to think implication of introducing more 
risks handling password around XSS on web site.

In practice, XSS is ubiquitous today (e.g. it is reported that about 50% 
of web sites have XSS vulnerabilities and I feel same from my experience.)

Even though such large number of XSS exist the reason of not being 
exploited is that in most cases it is not so useful from attacker's 
point of view with its limited access to credentials (cookie or 
sessionIDs those are basically temporal use).

However, if once this becomes to provide password which is more valuable 
for attackers, the game may change.

  I wrote

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

now I noticed that if "object.toSource()" or "JSON.stringfy() " can 
apply for PasswordCredential objects attackers would have access to the 
password data.  (I am not sure if there is any way to prohibit such 
access or if it is already taken into account.)

I understand that XSS is a separate threat but this API seems increase 
the risk of XSS.

To me it seems better to have some safty mechanism to introduce this 
API.  (e.g. require CSP as preriquisite etc.)

Keiji Takeda

On 5/17/15 5:32 AM, Mike West wrote:
> Thanks Keiji! This is an interesting discussion.
>
> On Wed, May 13, 2015 at 5:39 PM, Keiji Takeda <tkeiji@w3.org
> <mailto: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 <mailto: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.)

Received on Tuesday, 26 May 2015 17:32:32 UTC