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

On Tue, May 26, 2015 at 7:32 PM, Keiji Takeda <tkeiji@w3.org> wrote:
> 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).

As noted below, I hope the current design already mitigates this risk
by removing direct JavaScript access to the password. We can further
harden this by skipping the ServiceWorker as well, though I'm not sure
that's necessary.

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

Neither of these should be a risk; the password information is stored
in an internal "slot" in the JavaScript object. There isn't any getter
that's web-accessible, and serialization of the object won't reveal
its internal implementation details.

In an idealized future, this should allow multi-process browsers like
Chrome to avoid sending the password down to a renderer process at
all, which I'm excited about. :)

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

What baseline CSP would you suggest? The spec currently suggests
`connect-src` in order to further lock down the acceptable endpoints
for `send()`. What else do you see as relevant?

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

Received on Thursday, 28 May 2015 07:57:39 UTC