New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
tjwudi opened this Issue Mar 11, 2017 · 5 comments

Comments

Projects
None yet
2 participants
@tjwudi

tjwudi commented Mar 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Mar 11, 2017

Member

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.

Member

mikewest commented Mar 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tjwudi

tjwudi Mar 11, 2017

tjwudi commented Mar 11, 2017

@mikewest

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Mar 13, 2017

Member

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?

Member

mikewest commented Mar 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tjwudi

tjwudi Mar 14, 2017

tjwudi commented Mar 14, 2017

@mikewest

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Mar 14, 2017

Member

Great!

Member

mikewest commented Mar 14, 2017

Great!

@mikewest mikewest closed this Mar 14, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment