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

Mike,

Thank you for your comment.

Please understand that I am just trying to examine possible risks around 
the API before bad things happen.

 > As noted below, I hope the current design already mitigates this risk
 > by removing direct JavaScript access to the password.

As you wrote "The spec currently *suggests*" the mitigation (using CSP) 
but does not require it that means current design suggests to mitigate 
the risk but it allows not to mitigate as well.

 >> "object.toSource()" or "JSON.stringfy() "
 > 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.

Thank you for the clarification that the risk is already taken in to 
account.  I am sorry for that I did not catch the nuance.

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

connect-src and child-src are O.K. as suggested in the spec.
What I meant here is that it may be worth considering to change "SHOULD" 
to "MUST" to require those CSPs as prerequisite rather than suggest.

Keiji

On 5/28/15 3:56 AM, Mike West wrote:
> 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 13:51:05 UTC