User agent should/may not allow overriding "store" and "get"

[tjwudi]

If a malicious party is able to inject script into an origin, they could (among many other things you wouldn’t like) overwrite the behavior of store() to steal a user’s credentials as they’re written into the credential store.

I propose the following changes.

User agents *MAY*/*MUST* prevent overriding following methods.

- navigator.credentials.store
- navigator.credentials.get

This is doable, just like the non overridable location.origin. Ignoring this feature imposes users to the leak of personal credentials due to poor security implementations.

I also want to point out strongly that we at least say user agents MAY implement this feature.

[mikewest]

I understand the concern, however, consider is the behavior of password-managing extensions. I think it's important that programs like LastPass, 1Password, etc, be able to interject themselves between the site and the browser. That's their whole point.

If we make store and get unforgeable, then we're locking those out of the process, which seems bad.

[mikewest]

I understand the concern, however, consider is the behavior of password-managing extensions. I think it's important that programs like LastPass, 1Password, etc, be able to interject themselves between the site and the browser. That's their whole point.

If we make store and get unforgeable, then we're locking those out of the process, which seems bad.

[tjwudi]

I agree. There are two ways user agents can provide that kind of flexibility, either allowing injections to web pages like you mentioned or they can provide API in their own extension/plugin ecosystem. I would say the second is better because comparing to tools you mentioned, protecting users personal data from compromised is way more important. Most sites are not implementing anti-XSS correctly, and many users use simple and consistent password on every service they use. So I think we should still make those APIs unforgeable.

…

On Fri, Mar 10, 2017 at 10:37 PM Mike West ***@***.***> wrote: I understand the concern, however, consider is the behavior of password-managing extensions. I think it's important that programs like LastPass, 1Password, etc, be able to interject themselves between the site and the browser. That's their whole point. If we make store and get unforgeable, then we're locking those out of the process, which seems bad. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#63 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFA6WH7QDvTz1cJODduuREqjPlK96nbHks5rkkEbgaJpZM4MaBkA> .

[tjwudi]

I agree. There are two ways user agents can provide that kind of flexibility, either allowing injections to web pages like you mentioned or they can provide API in their own extension/plugin ecosystem. I would say the second is better because comparing to tools you mentioned, protecting users personal data from compromised is way more important. Most sites are not implementing anti-XSS correctly, and many users use simple and consistent password on every service they use. So I think we should still make those APIs unforgeable.

…

On Fri, Mar 10, 2017 at 10:37 PM Mike West ***@***.***> wrote: I understand the concern, however, consider is the behavior of password-managing extensions. I think it's important that programs like LastPass, 1Password, etc, be able to interject themselves between the site and the browser. That's their whole point. If we make store and get unforgeable, then we're locking those out of the process, which seems bad. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#63 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFA6WH7QDvTz1cJODduuREqjPlK96nbHks5rkkEbgaJpZM4MaBkA> .

[mikewest]

Looking at this again, it's not at all clear to me what an attacker would actually gain by overriding store or get. get's arguments don't reveal any interesting credential information (e.g. { password: true }), and store gets a PasswordCredential object, but that object doesn't expose the password field to JavaScript. Really, the attacker would need to override the PasswordCredential constructor entirely. If they can do that, they can just read the data out of the DOM at the time it's used to construct the credential.

Can you help me understand an attack scenario that store and get specifically enable?

[mikewest]

Looking at this again, it's not at all clear to me what an attacker would actually gain by overriding store or get. get's arguments don't reveal any interesting credential information (e.g. { password: true }), and store gets a PasswordCredential object, but that object doesn't expose the password field to JavaScript. Really, the attacker would need to override the PasswordCredential constructor entirely. If they can do that, they can just read the data out of the DOM at the time it's used to construct the credential.

Can you help me understand an attack scenario that store and get specifically enable?

[tjwudi]

Yeah makes sense. I missed the point that password is a private property in native code. Let's close this. (Close #63) On Mon, Mar 13, 2017 at 1:08 AM Mike West <notifications@github.com> wrote: Looking at this again, it's not at all clear to me what an attacker would actually gain by overriding store or get. get's arguments don't reveal any interesting credential information (e.g. { password: true }), and store gets a PasswordCredential object, but that object doesn't expose the password field to JavaScript. Really, the attacker would need to override the PasswordCredential constructor entirely. If they can do that, they can just read the data out of the DOM at the time it's used to construct the credential. Can you help me understand an attack scenario that store and get specifically enable? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#63 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFA6WLwDn8JPQkbm_vR0YKwL6xK3hSNQks5rlPlmgaJpZM4MaBkA> .

[tjwudi]

Yeah makes sense. I missed the point that password is a private property in native code. Let's close this. (Close #63) On Mon, Mar 13, 2017 at 1:08 AM Mike West <notifications@github.com> wrote: Looking at this again, it's not at all clear to me what an attacker would actually gain by overriding store or get. get's arguments don't reveal any interesting credential information (e.g. { password: true }), and store gets a PasswordCredential object, but that object doesn't expose the password field to JavaScript. Really, the attacker would need to override the PasswordCredential constructor entirely. If they can do that, they can just read the data out of the DOM at the time it's used to construct the credential. Can you help me understand an attack scenario that store and get specifically enable? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#63 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFA6WLwDn8JPQkbm_vR0YKwL6xK3hSNQks5rlPlmgaJpZM4MaBkA> .

[mikewest]

Great!

[mikewest]

Great!